Yahoo Groups archive
Thread
2005-07-21 by Owen Mooney
Has anyone experience with lower A/D reference voltages on the LPC2138? I usually use a 2.5V reference on 3.3v systems but the doc suggests that this should the same as the main supply and the data sheet says that this should be 3 to 3.6 volts. Owen Mooney
2005-07-22 by tom_laffey
Hi Owen, I was just looking into this myself. There is a FAQ on the Philips site (http://www-us16.semiconductors.com/cgi-bin/faq/faq.pl? query=q&id=307&gid=36&fid=3) that says: Q: On the LPC2xxx, the analog power pin (V3A) states that it should be nominally the same as the V3 pin, but can I connect a precision reference to this V3A pin that is at less voltage than the V3 pin or am I forced to use the same 3.3V power supply that I use on V3? A: The ADC voltage can go below 3V. According to test, the ADC operates according to spec even below 2V. Regards, Tom --- In lpc2000@yahoogroups.com, Owen Mooney <ojm@s...> wrote: > Has anyone experience with lower A/D reference voltages on the LPC2138? > > I usually use a 2.5V reference on 3.3v systems but the doc suggests that
> this should the same as the main supply and > the data sheet says that this should be 3 to 3.6 volts. > > Owen Mooney
2005-07-24 by Owen Mooney
Thanks Tom. BTW I have found a nice reference from National (LM4120) low power - shutdown -low drop out voltage Owen Hi Owen, I was just looking into this myself. There is a FAQ on the Philips site (http://www-us16.semiconductors.com/cgi-bin/faq/faq.pl? query=q&id=307&gid=36&fid=3) that says: Q: On the LPC2xxx, the analog power pin (V3A) states that it should be nominally the same as the V3 pin, but can I connect a precision reference to this V3A pin that is at less voltage than the V3 pin or am I forced to use the same 3.3V power supply that I use on V3? A: The ADC voltage can go below 3V. According to test, the ADC operates according to spec even below 2V. Regards,
2005-07-25 by James Dabbs
I am using a Nohau JTAG ICE connected to the second port on a LPC2106. The emulator does not make a reliable connection to the JTAG unit on the chip. On my design, I have DBGSEL pulled to ground. Right after reset, I execute the following code segment: ldr r0,=0x55400000 ldr r1,=0xE002C004 str r0,[r1] On my board, I connect the 20-pin JTAG header to the LPC2106 like this: NTRST (3) -> P0.27/TRC0/TRST (8) TDI (5) -> P0.30/TRC3/TDI (15) TMS (7) -> P0.28/TRC1/TMS (9) TCK (9) -> P0.29/TRC2/TCK (10) RTCK (11) -> RTCK (26) TDO (13) -> P0.31/EXTIN0/TDO (16) NRST (15) -> RST (5) Right after enabling the secondary JTAG port, I have a code loop that toggles an I/O pin. I can see this happening, and then when I run the emulator, the toggling stops. It doesn't reset; it just pauses execution. I know this because the I/O pin doesn't go back to being an input. However, the JTAG emulator is unable to "enter a debug state" which means it can't talk to the JTAG interface on the chip. Every once in a while (twice, so far) it connects and I can debug my S/W, but 99.9% of the time it does not. This is essentially the same design as a different project I used last year, but I am having trouble with it now. Am I breaking some rule here? Is there anything obvious in what I am doing that could cause this? Thanks.
2005-07-25 by Leon Heller
----- Original Message -----
From: "James Dabbs" <jdabbs@...> To: <lpc2000@yahoogroups.com> Sent: Monday, July 25, 2005 8:52 AM Subject: [lpc2000] Unreliable Secondary JTAG Connection >I am using a Nohau JTAG ICE connected to the second port on a LPC2106. > The emulator does not make a reliable connection to the JTAG unit on the > chip. > > On my design, I have DBGSEL pulled to ground. Right after reset, I > execute the following code segment: > > ldr r0,=0x55400000 > ldr r1,=0xE002C004 > str r0,[r1] > > On my board, I connect the 20-pin JTAG header to the LPC2106 like this: > > NTRST (3) -> P0.27/TRC0/TRST (8) > TDI (5) -> P0.30/TRC3/TDI (15) > TMS (7) -> P0.28/TRC1/TMS (9) > TCK (9) -> P0.29/TRC2/TCK (10) > RTCK (11) -> RTCK (26) > TDO (13) -> P0.31/EXTIN0/TDO (16) > NRST (15) -> RST (5) > > Right after enabling the secondary JTAG port, I have a code loop that > toggles an I/O pin. I can see this happening, and then when I run the > emulator, the toggling stops. It doesn't reset; it just pauses > execution. I know this because the I/O pin doesn't go back to being an > input. However, the JTAG emulator is unable to "enter a debug state" > which means it can't talk to the JTAG interface on the chip. Every once > in a while (twice, so far) it connects and I can debug my S/W, but 99.9% > of the time it does not. > > This is essentially the same design as a different project I used last > year, but I am having trouble with it now. > > Am I breaking some rule here? Is there anything obvious in what I am > doing that could cause this? IIRC, the secondary JTAG is not intended for debugging. It's OK for programming the flash, of course. Leon -- Leon Heller, G1HSM leon.heller@... http://www.geocities.com/leon_heller -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.9.4/57 - Release Date: 22/07/2005 --- [This E-mail has been scanned for viruses but it is your responsibility to maintain up to date anti virus software on the device that you are currently using to read this email. ]
2005-07-25 by James Dabbs
> IIRC, the secondary JTAG is not intended for debugging. It's OK for > programming the flash, of course. Leon, Thanks for the response. I guess I don't understand Phillips' goals. Why put an entire second JTAG unit on the part when the UART can be used to program the flash? I did a project a while back with the LPC2106 where I was able to debug it with the secondary JTAG port. The JTAG interface on this new board was lifted directly from the first project's schematic. Can anyone from Phillips explain this, what the second port is for, and why I might be having such intermittent results? Thanks.
2005-07-25 by philips_apps
James, it all started with the assumption that trace emulation would be the standard for the ARM devices. Enabling debug on the LPC2104, will enable the primary JTAG and the Embedded Trace Macrocell (ETM). This is still a very importnat feature which can not be found on most other low cost ARM devices. Unfortunately there has been no option implemented on the LPC210x to disable ETM while still having the primary JTAG. As a result, enabling the debug channels took away too many pins. The second JTAG was implemented for test and can actually be used for debugging as well. I do not knwo why you are having problems but what I heared from emulator companies like Ashling, Nohau, Hitex, they seem to have this interface in use and under control. Even if would only be for programming, through JTAG it is possible to program the device below 10 sec while this is not possible with e.g. 115,200 baud. Speed of programming is important to many companies. btw. all other devices, introduced after the LPC210x have the option to enable just JTAG or JTAG and ETM, so no need any more for a secondary JTAG. Hth, Robert --- In lpc2000@yahoogroups.com, "James Dabbs" <jdabbs@t...> wrote: > > IIRC, the secondary JTAG is not intended for debugging. It's OK for > > programming the flash, of course. > > Leon, > > Thanks for the response. I guess I don't understand Phillips' goals. > Why put an entire second JTAG unit on the part when the UART can be used > to program the flash? I did a project a while back with the LPC2106 > where I was able to debug it with the secondary JTAG port. The JTAG > interface on this new board was lifted directly from the first project's > schematic. > > Can anyone from Phillips explain this, what the second port is for, and
> why I might be having such intermittent results? > > Thanks.
2005-07-25 by Owen Mooney
I've used the secondary JTAG on the PLC2106 for debugging - I needed the extra port lines that enabling the primary JTAG also cripples. It worked well. I used the UART to download a simple program to enable it then away I went. I agree its use is clumsy - the arrangement is much better on the LPC213x series. Subject: >> IIRC, the secondary JTAG is not intended for debugging. It's OK for >> programming the flash, of course. > > Leon, Thanks for the response. I guess I don't understand Phillips' goals. Why put an entire second JTAG unit on the part when the UART can be used to program the flash? I did a project a while back with the LPC2106 where I was able to debug it with the secondary JTAG port. The JTAG interface on this new board was lifted directly from the first project's schematic. Can anyone from Phillips explain this, what the second port is for, and why I might be having such intermittent results? Thanks.
2005-07-26 by James Dabbs
> I've used the secondary JTAG on the PLC2106 for debugging - I > needed the extra port lines that enabling the primary JTAG > also cripples. > > It worked well. Owen, Exactly which lines did you connect, and who's debugger did you use? I used this hook-up (successfully, then unsuccessfully) -- NTRST (3) -> P0.27/TRC0/TRST (8) TDI (5) -> P0.30/TRC3/TDI (15) TMS (7) -> P0.28/TRC1/TMS (9) TCK (9) -> P0.29/TRC2/TCK (10) RTCK (11) -> RTCK (26) TDO (13) -> P0.31/EXTIN0/TDO (16) NRST (15) -> RST (5) Thanks.
2005-11-09 by bruce_p1
I was searching through this group to see if anyone else was having an unreliable secondary JTAG connection issue with the LPC210x chips; guess I'm not alone. I too am using a Nohau JTAG debugger; the EMUL-ARM, but that doesn't seem to be the issue. According to the LPC210x datasheet, to enable secondary JTAG you have to bring DBGSEL or RTCK low to disable primary JTAG pins and ETM, then setup the secondary pins in software. My original setup was RTCK high and DBGSEL low. It worked perfectly on some boards, but not on my current board. Then I tried both pins low with the same results. After much searching through groups and sites, I found a note from an LPC user that said he had pulled DBGSEL high and RTCK low to fix random LPC210x chips that wouldn't go into secondary JTAG. This worked perfectly and I could recreate the scenario every time! I have a question into Philips as to what the real deal is and why this works. I was wondering if it was a reset or power sequencing issue since I have other boards that don't do this. Since all the signals are internal to the chip, it sure seems like an issue on random LPC210x chips. Regardless, I thought I'd pass this along since it seemed to be a hot topic a while back. Comments or similar experiences? Regards, Bruce --- In lpc2000@yahoogroups.com, "James Dabbs" <jdabbs@t...> wrote: > > I am using a Nohau JTAG ICE connected to the second port on a LPC2106. > The emulator does not make a reliable connection to the JTAG unit on the > chip. > > On my design, I have DBGSEL pulled to ground. Right after reset, I > execute the following code segment: > > ldr r0,=0x55400000 > ldr r1,=0xE002C004 > str r0,[r1] > > On my board, I connect the 20-pin JTAG header to the LPC2106 like this: > > NTRST (3) -> P0.27/TRC0/TRST (8) > TDI (5) -> P0.30/TRC3/TDI (15) > TMS (7) -> P0.28/TRC1/TMS (9) > TCK (9) -> P0.29/TRC2/TCK (10) > RTCK (11) -> RTCK (26) > TDO (13) -> P0.31/EXTIN0/TDO (16) > NRST (15) -> RST (5) > > Right after enabling the secondary JTAG port, I have a code loop that > toggles an I/O pin. I can see this happening, and then when I run the > emulator, the toggling stops. It doesn't reset; it just pauses > execution. I know this because the I/O pin doesn't go back to being an > input. However, the JTAG emulator is unable to "enter a debug state" > which means it can't talk to the JTAG interface on the chip. Every once > in a while (twice, so far) it connects and I can debug my S/W, but 99.9% > of the time it does not. > > This is essentially the same design as a different project I used last > year, but I am having trouble with it now. > > Am I breaking some rule here? Is there anything obvious in what I am
> doing that could cause this? > > Thanks. >
2005-11-09 by Tom Walsh
bruce_p1 wrote:
>I was searching through this group to see if anyone else was having
>an unreliable secondary JTAG connection issue with the LPC210x
>chips; guess I'm not alone.
>
>I too am using a Nohau JTAG debugger; the EMUL-ARM, but that doesn't
>seem to be the issue.
>
>According to the LPC210x datasheet, to enable secondary JTAG you
>have to bring DBGSEL or RTCK low to disable primary JTAG pins and
>ETM, then setup the secondary pins in software. My original setup
>was RTCK high and DBGSEL low. It worked perfectly on some boards,
>but not on my current board. Then I tried both pins low with the
>same results.
>
>After much searching through groups and sites, I found a note from
>an LPC user that said he had pulled DBGSEL high and RTCK low to fix
>random LPC210x chips that wouldn't go into secondary JTAG.
>
>This worked perfectly and I could recreate the scenario every time!
>
>I have a question into Philips as to what the real deal is and why
>this works. I was wondering if it was a reset or power sequencing
>issue since I have other boards that don't do this. Since all the
>signals are internal to the chip, it sure seems like an issue on
>random LPC210x chips.
>
>Regardless, I thought I'd pass this along since it seemed to be a
>hot topic a while back.
>
>
>
This is a Rev 0 board that I'm building, so far one-of-a-kind (until
production). I tie both DEBUG + RTCK low through 10K resistors. Then,
I put this in crt0.S:
======= begin ============
start:
_start:
_mainCRTStartup:
ldr r0, JTAG2
ldr r1, PINSELREG
str r0, [r1]
;
========= snip ==========
Variables are defined as:
========= begin =========
JTAG2:
.word 0x55400000
PINSELREG:
.word 0xe002c004
========== snip =========
So far, no problems with JTAG. I'm daisy chaining with an LPC2138 that
is first in the chain.
TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------2005-11-09 by bruce_p1
Tom, What you describe is the norm for secondary JTAG debugging and is well understood. But, some people, including myself, have seen this not work on some LPC chips on certain circuit boards. The only way I saw it fixed was to keep DBGSEL high and RTCK low. I have designed quite a few other boards that work perfectly, but have now seen random chips not allowing a secondary JTAG connection. This makes me wonder if there is a certain combination of things that cause this issue (e.g., on-board capacitance, certain batches of chips from a certain fab, reset timing, crystal frequency, power supply sequencing, timing issue with DBGSEL, etc.). These things can probably only be answered by the Philips designers is my guess. Regards, Bruce --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote: > > bruce_p1 wrote: > > >I was searching through this group to see if anyone else was having > >an unreliable secondary JTAG connection issue with the LPC210x > >chips; guess I'm not alone. > > > >I too am using a Nohau JTAG debugger; the EMUL-ARM, but that doesn't > >seem to be the issue. > > > >According to the LPC210x datasheet, to enable secondary JTAG you > >have to bring DBGSEL or RTCK low to disable primary JTAG pins and > >ETM, then setup the secondary pins in software. My original setup > >was RTCK high and DBGSEL low. It worked perfectly on some boards, > >but not on my current board. Then I tried both pins low with the > >same results. > > > >After much searching through groups and sites, I found a note from > >an LPC user that said he had pulled DBGSEL high and RTCK low to fix > >random LPC210x chips that wouldn't go into secondary JTAG. > > > >This worked perfectly and I could recreate the scenario every time! > > > >I have a question into Philips as to what the real deal is and why > >this works. I was wondering if it was a reset or power sequencing > >issue since I have other boards that don't do this. Since all the > >signals are internal to the chip, it sure seems like an issue on > >random LPC210x chips. > > > >Regardless, I thought I'd pass this along since it seemed to be a > >hot topic a while back. > > > > > > > > This is a Rev 0 board that I'm building, so far one-of-a-kind (until > production). I tie both DEBUG + RTCK low through 10K resistors. Then, > I put this in crt0.S: > > ======= begin ============ > start: > _start: > _mainCRTStartup: > ldr r0, JTAG2 > ldr r1, PINSELREG > str r0, [r1] > ; > ========= snip ========== > > Variables are defined as: > > ========= begin ========= > JTAG2: > .word 0x55400000 > PINSELREG: > .word 0xe002c004 > ========== snip ========= > > So far, no problems with JTAG. I'm daisy chaining with an LPC2138 that
> is first in the chain. > > TomW > > -- > Tom Walsh - WN3L - Embedded Systems Consultant > http://openhardware.net, http://cyberiansoftware.com > "Windows? No thanks, I have work to do..." > ---------------------------------------------------- >
2005-11-10 by Tom Walsh
bruce_p1 wrote: >Tom, > >What you describe is the norm for secondary JTAG debugging and is >well understood. But, some people, including myself, have seen this >not work on some LPC chips on certain circuit boards. The only way >I saw it fixed was to keep DBGSEL high and RTCK low. > >I have designed quite a few other boards that work perfectly, but >have now seen random chips not allowing a secondary JTAG >connection. This makes me wonder if there is a certain combination >of things that cause this issue (e.g., on-board capacitance, certain >batches of chips from a certain fab, reset timing, crystal >frequency, power supply sequencing, timing issue with DBGSEL, >etc.). These things can probably only be answered by the Philips >designers is my guess. > > > Perhaps telephone the local Philips Field Rep and get on their case about the issue? Regards, TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-11-10 by bruce_p1
Yup, that' what I did. I'll let everyone know what I find out. I heard all the LPC chips are getting rev'd to fix errata soon, so this could be good timing if it truely is a random issue that can be fixed in silicon and it's not something that can be prevented on the board itself. -Bruce --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote: > > bruce_p1 wrote: > > >Tom, > > > >What you describe is the norm for secondary JTAG debugging and is > >well understood. But, some people, including myself, have seen this > >not work on some LPC chips on certain circuit boards. The only way > >I saw it fixed was to keep DBGSEL high and RTCK low. > > > >I have designed quite a few other boards that work perfectly, but > >have now seen random chips not allowing a secondary JTAG > >connection. This makes me wonder if there is a certain combination > >of things that cause this issue (e.g., on-board capacitance, certain > >batches of chips from a certain fab, reset timing, crystal > >frequency, power supply sequencing, timing issue with DBGSEL, > >etc.). These things can probably only be answered by the Philips > >designers is my guess. > > > > > > > Perhaps telephone the local Philips Field Rep and get on their case
> about the issue? > > Regards, > > TomW > > > -- > Tom Walsh - WN3L - Embedded Systems Consultant > http://openhardware.net, http://cyberiansoftware.com > "Windows? No thanks, I have work to do..." > ---------------------------------------------------- >
2005-11-20 by Tom Walsh
bruce_p1 wrote: >I was searching through this group to see if anyone else was having >an unreliable secondary JTAG connection issue with the LPC210x >chips; guess I'm not alone. > >I too am using a Nohau JTAG debugger; the EMUL-ARM, but that doesn't >seem to be the issue. > >According to the LPC210x datasheet, to enable secondary JTAG you >have to bring DBGSEL or RTCK low to disable primary JTAG pins and >ETM, then setup the secondary pins in software. My original setup >was RTCK high and DBGSEL low. It worked perfectly on some boards, >but not on my current board. Then I tried both pins low with the >same results. > >After much searching through groups and sites, I found a note from >an LPC user that said he had pulled DBGSEL high and RTCK low to fix >random LPC210x chips that wouldn't go into secondary JTAG. > >This worked perfectly and I could recreate the scenario every time! > >I have a question into Philips as to what the real deal is and why >this works. I was wondering if it was a reset or power sequencing >issue since I have other boards that don't do this. Since all the >signals are internal to the chip, it sure seems like an issue on >random LPC210x chips. > >Regardless, I thought I'd pass this along since it seemed to be a >hot topic a while back. > >Comments or similar experiences? > > > > Yup, I got bit! Cost me about 4..6 hours of buzzing out the first prototype against the second PCB run prototypes. That was before I recalled this posting you made. Pull DBGSEL high, JTAG now works. Funny the manual says nothing about this, actually it is very misleading and they really really really need to work on that... Once you've been bitten by this vague wording (Page 7 of the Rev. 05 \ufffd 22 December 2004 LPC2106 manual): "Debug Select: When LOW, the part operates normally. When HIGH, debug mode is entered. Input pin with internal pull-down." THEN(!) the poorly written phrase becomes crystal clear! Lousy Tech Writers anyhow... Regards, TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------