JTAG/SWD cannot stop the LPC1788 CM3 core

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by lpcware
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....