JTAG/SWD cannot stop the LPC1788 CM3 core

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

JTAG/SWD cannot stop the LPC1788 CM3 core

958 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by acv on Tue Nov 20 14:32:41 MST 2012
While porting the LPC177x and LPC178x CMSIS-Compliant Standard Peripheral Firmware Driver Library to Rowley CrossWorks 2.3, I ran into the dreaded "Cannot stop CPU" error.  Specifically, I was testing the UART polling example since it is very straight forward and does not have any interrupts.  Over the course of working with NXP parts for the last five years, I have run into this problem several times, but never fully understood why this was happening.  So this morning, I started digging into it.  At Rowley, there was a post by Paul Curtis (go Lotus!) who wrote the following:

This error message is displayed when the debugger is unable to make the ARM stop running and enter debug mode typically after carrying out a reset. This error message could be caused by the following:

1) Unreliable JTAG/SWD Connection — Try reducing the JTAG/SWD clock frequency or reducing the target interface's cable lengths as much as possible.
2) Incorrect support package — Make sure you are using a CPU/board support package intended for your part.
3) Incorrectly connected reset signals — Typically the nSRST signal should be connected to the target's core reset signal, it should not be connected to the JTAG TAP reset (TRST) signal.
4) Invalid code has been executed — This may be caused by your program not being loaded correctly, a problem with the target's memory or a bug in your program. You can check the download and memory by verifying the download.

In my case, I can rule out items #1 & 3: There are no known hardware issues with this board / debugger: I have tested other applications under CrossWorks 2.2 and I have used this board with Keil MDK 4.6.0, both without issue.  Note: At work, I use Keil MDK almost exclusively.  I've seen this problem using Keil MDK too, but it's been a while and my recollection of the details is a bit hazy.  As I recall, it was an issue with the code, not the hardware.

In looking at cases two and four, it's interesting to me that "invalid code" can somehow kill the JTAG port.  There are the obvious cases of disabling JTAG/SWD debug or halting the CM3-core clock that can cause the debugger to stop working.  In my case, again, I am confident that the code is not modifying the clock or disabling the debugger.  The code seems to run fine under the debugger.  However, when done, the code goes into a <code> while (1); </code> loop.

To me this seems harmless: it's just a loop, one instruction repeating over and over.  But no, this does not appear to be the case.  This kind of loop is the equivalent of a death spiral for the CM3-core: apparently, because the loop is so tight, the processor cannot acknowledge the JTAG/SWD request to halt.  I have found several posts (Keil / LPCware / Rowley) that indicate if the CM3 core waits after reset (whatever that means) before executing the main application, then somehow, the JTAG/SWD will not lose control.

So now that I've described my corner case, here are my questions:
1. How can this be?  These are ordinary instructions.  It should be possible for the JTAG/SWD to halt the CPU while executing a loop like this.
2. If this delay after reset is so good, then why doesn't everyone have it in their start-up files?  One note here: Rowley has something called STARTUP_FROM_RESET.  It is documented in the assembly file, rather well in fact, but it doesn't indicate the root cause of this failure.  And worse, should handle the this very situation. I'm at a loss as to why this doesn't work.

To reiterate, over the course of working with NXP parts (LPC2458, LPC1313, and now the LPC1788) for the last five years, I have run into this problem several times.  However, I haven't seen a complete, satisfactory explanation as to why this happens. My hope is that someone out there can explain why....

Thanks,

ACV
Labels (1)
0 Kudos
2 Replies

639 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Herrbert on Thu Jun 12 08:12:14 MST 2014
I know this topic is really old. But I had the same problem and traced it down to this command:
LPC_SC->PCON |=(1 << 3)

The command should deactivate BOD...

I have no idea why it is not possible to access the device by JTAG afterwards...

CPU is a LPC1788

Regards
0 Kudos

639 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Dave on Wed Nov 21 00:32:19 MST 2012
I also have had this happen, and there was no way to revive the JTAG interface from within Keil MDK...

I ended up using the bootloader over UART0 with FlashMagic, and once a running code was loaded, I had access once again to the JTAG interface

What I discovered was the code that locked up the JTAG port had invalid values for setting up PLL0...

I'll be curious to see what NXP has to say here...

Thanks for posting this question!

0 Kudos