Is it possible to establish communications with the JTAG controller of
a LPC2364 while the LPC2364 RESET line (not TRST) is asserted ? This
would appear to be necessary in order to debug the processor as it
comes out of RESET. My (high-end) external JTAG device seems unable
to accomplish this feat ... Thanks, Scott.
LPC2364 JTAG debug from Reset
Started by ●February 12, 2007
Reply by ●February 12, 20072007-02-12
Hi,
I haven't worked with a LPC23xx (or LPC24xx) yet, but on the LPC21xx and
LPC22xx debugging out of reset was impossible, as it would allow to
cricumvent the CRP (code read protection) feature implementation found on
these devices.
They internally assert nTRST once nSRST is asserted, and disable JTAG
alltogether within the first few instructions of the on-chip boot ROM. Only
if the CRP pattern isn't detected in flash the JTAG port gets reenabled
later. If the device didn't assert nTRST on a nSRST, a debugger could set up
a breakpoint at 0x0, preventing the on-chip boot ROM from evaluating the CRP
setting.
You could add a loop at the reset vector of your code in debug releases and
manually advance past that loop once your debugger has gained control over
the target. I believe this is implemented in some of the commercial IDEs.
Regards,
Dominic
On Monday 12 February 2007 14:58, jsm09a wrote:
> Is it possible to establish communications with the JTAG controller of
> a LPC2364 while the LPC2364 RESET line (not TRST) is asserted ? This
> would appear to be necessary in order to debug the processor as it
> comes out of RESET. My (high-end) external JTAG device seems unable
> to accomplish this feat ... Thanks, Scott.
I haven't worked with a LPC23xx (or LPC24xx) yet, but on the LPC21xx and
LPC22xx debugging out of reset was impossible, as it would allow to
cricumvent the CRP (code read protection) feature implementation found on
these devices.
They internally assert nTRST once nSRST is asserted, and disable JTAG
alltogether within the first few instructions of the on-chip boot ROM. Only
if the CRP pattern isn't detected in flash the JTAG port gets reenabled
later. If the device didn't assert nTRST on a nSRST, a debugger could set up
a breakpoint at 0x0, preventing the on-chip boot ROM from evaluating the CRP
setting.
You could add a loop at the reset vector of your code in debug releases and
manually advance past that loop once your debugger has gained control over
the target. I believe this is implemented in some of the commercial IDEs.
Regards,
Dominic
On Monday 12 February 2007 14:58, jsm09a wrote:
> Is it possible to establish communications with the JTAG controller of
> a LPC2364 while the LPC2364 RESET line (not TRST) is asserted ? This
> would appear to be necessary in order to debug the processor as it
> comes out of RESET. My (high-end) external JTAG device seems unable
> to accomplish this feat ... Thanks, Scott.
Reply by ●February 12, 20072007-02-12
You can't communicate with the JTAG controller while reset is held
low. But you can debug thru reset. Here is what I do for
LPC213x/LPC214x and LPC23xx. The following method does not work on CRP
enabled devices.
1) Program code in flash.
2) Reset the chip.
3) Stop the processor via debugger.
4) Set breakpoint at address 0.
5) Resume execution in debugger.
6) Do a reset. Board reset button should not be wired to jtag reset.
Most eval boards have correct reset circuit.
7) The processor stops at address zero. (in bootloader)
8) Resume execution. The processor stops again. This time in
the application you want to debug.
9) Load debug symbols in debugger. Start debug activity.
Tom
--- In l..., "jsm09a"
wrote:
>
> Is it possible to establish communications with the JTAG controller of
> a LPC2364 while the LPC2364 RESET line (not TRST) is asserted ? This
> would appear to be necessary in order to debug the processor as it
> comes out of RESET. My (high-end) external JTAG device seems unable
> to accomplish this feat ... Thanks, Scott.
>
low. But you can debug thru reset. Here is what I do for
LPC213x/LPC214x and LPC23xx. The following method does not work on CRP
enabled devices.
1) Program code in flash.
2) Reset the chip.
3) Stop the processor via debugger.
4) Set breakpoint at address 0.
5) Resume execution in debugger.
6) Do a reset. Board reset button should not be wired to jtag reset.
Most eval boards have correct reset circuit.
7) The processor stops at address zero. (in bootloader)
8) Resume execution. The processor stops again. This time in
the application you want to debug.
9) Load debug symbols in debugger. Start debug activity.
Tom
--- In l..., "jsm09a"
wrote:
>
> Is it possible to establish communications with the JTAG controller of
> a LPC2364 while the LPC2364 RESET line (not TRST) is asserted ? This
> would appear to be necessary in order to debug the processor as it
> comes out of RESET. My (high-end) external JTAG device seems unable
> to accomplish this feat ... Thanks, Scott.
>
Reply by ●February 12, 20072007-02-12
--- In l..., Dominic Rath wrote:
> I haven't worked with a LPC23xx (or LPC24xx) yet, but on the LPC21xx
and
> LPC22xx debugging out of reset was impossible, as it would allow to
> cricumvent the CRP (code read protection) feature implementation
found on
> these devices.
Dominic,
I appreciate your point, that if it were possible, then this would
defeat CRP. However, my information is that it is possible to "debug"
out of reset.
CRP functionality depends on this method being kept a secret, but its
existence should not be in doubt given it is possible to recover MCUs
with corrupt flash such that ISP cannot be used to erase all sectors.
Jaya
> I haven't worked with a LPC23xx (or LPC24xx) yet, but on the LPC21xx
and
> LPC22xx debugging out of reset was impossible, as it would allow to
> cricumvent the CRP (code read protection) feature implementation
found on
> these devices.
Dominic,
I appreciate your point, that if it were possible, then this would
defeat CRP. However, my information is that it is possible to "debug"
out of reset.
CRP functionality depends on this method being kept a secret, but its
existence should not be in doubt given it is possible to recover MCUs
with corrupt flash such that ISP cannot be used to erase all sectors.
Jaya
