<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic JTAG/SWD cannot stop the LPC1788 CM3 core in LPC Microcontrollers</title>
    <link>https://community.nxp.com/t5/LPC-Microcontrollers/JTAG-SWD-cannot-stop-the-LPC1788-CM3-core/m-p/518347#M2620</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by acv on Tue Nov 20 14:32:41 MST 2012&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;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.&amp;nbsp; Specifically, I was testing the UART polling example since it is very straight forward and does not have any interrupts.&amp;nbsp; 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.&amp;nbsp; So this morning, I started digging into it.&amp;nbsp; At Rowley, there was a post by Paul Curtis (go Lotus!) who wrote the following:&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;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:&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;1) Unreliable JTAG/SWD Connection — Try reducing the JTAG/SWD clock frequency or reducing the target interface's cable lengths as much as possible.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;2) Incorrect support package — Make sure you are using a CPU/board support package intended for your part.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;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.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;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. &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;In my case, I can rule out items #1 &amp;amp; 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.&amp;nbsp; Note: At work, I use Keil MDK almost exclusively.&amp;nbsp; 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.&amp;nbsp; As I recall, it was an issue with the code, not the hardware.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;In looking at cases two and four, it's interesting to me that "invalid code" can somehow kill the JTAG port.&amp;nbsp; There are the obvious cases of disabling JTAG/SWD debug or halting the CM3-core clock that can cause the debugger to stop working.&amp;nbsp; In my case, again, I am confident that the code is not modifying the clock or disabling the debugger.&amp;nbsp; The code seems to run fine under the debugger.&amp;nbsp; However, when done, the code goes into a &amp;lt;code&amp;gt; while (1); &amp;lt;/code&amp;gt; loop.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;To me this seems harmless: it's just a loop, one instruction repeating over and over.&amp;nbsp; But no, this does not appear to be the case.&amp;nbsp; 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.&amp;nbsp; 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.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;So now that I've described my corner case, here are my questions:&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;1. How can this be?&amp;nbsp; These are ordinary instructions.&amp;nbsp; It should be possible for the JTAG/SWD to halt the CPU while executing a loop like this.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;2. If this delay after reset is so good, then why doesn't everyone have it in their start-up files?&amp;nbsp; One note here: Rowley has something called STARTUP_FROM_RESET.&amp;nbsp; It is documented in the assembly file, rather well in fact, but it doesn't indicate the root cause of this failure.&amp;nbsp; And worse, should handle the this very situation. I'm at a loss as to why this doesn't work.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;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.&amp;nbsp; However, I haven't seen a complete, satisfactory explanation as to why this happens. My hope is that someone out there can explain why....&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Thanks,&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;ACV&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 15 Jun 2016 17:33:54 GMT</pubDate>
    <dc:creator>lpcware</dc:creator>
    <dc:date>2016-06-15T17:33:54Z</dc:date>
    <item>
      <title>JTAG/SWD cannot stop the LPC1788 CM3 core</title>
      <link>https://community.nxp.com/t5/LPC-Microcontrollers/JTAG-SWD-cannot-stop-the-LPC1788-CM3-core/m-p/518347#M2620</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by acv on Tue Nov 20 14:32:41 MST 2012&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;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.&amp;nbsp; Specifically, I was testing the UART polling example since it is very straight forward and does not have any interrupts.&amp;nbsp; 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.&amp;nbsp; So this morning, I started digging into it.&amp;nbsp; At Rowley, there was a post by Paul Curtis (go Lotus!) who wrote the following:&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;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:&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;1) Unreliable JTAG/SWD Connection — Try reducing the JTAG/SWD clock frequency or reducing the target interface's cable lengths as much as possible.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;2) Incorrect support package — Make sure you are using a CPU/board support package intended for your part.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;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.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;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. &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;In my case, I can rule out items #1 &amp;amp; 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.&amp;nbsp; Note: At work, I use Keil MDK almost exclusively.&amp;nbsp; 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.&amp;nbsp; As I recall, it was an issue with the code, not the hardware.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;In looking at cases two and four, it's interesting to me that "invalid code" can somehow kill the JTAG port.&amp;nbsp; There are the obvious cases of disabling JTAG/SWD debug or halting the CM3-core clock that can cause the debugger to stop working.&amp;nbsp; In my case, again, I am confident that the code is not modifying the clock or disabling the debugger.&amp;nbsp; The code seems to run fine under the debugger.&amp;nbsp; However, when done, the code goes into a &amp;lt;code&amp;gt; while (1); &amp;lt;/code&amp;gt; loop.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;To me this seems harmless: it's just a loop, one instruction repeating over and over.&amp;nbsp; But no, this does not appear to be the case.&amp;nbsp; 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.&amp;nbsp; 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.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;So now that I've described my corner case, here are my questions:&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;1. How can this be?&amp;nbsp; These are ordinary instructions.&amp;nbsp; It should be possible for the JTAG/SWD to halt the CPU while executing a loop like this.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;2. If this delay after reset is so good, then why doesn't everyone have it in their start-up files?&amp;nbsp; One note here: Rowley has something called STARTUP_FROM_RESET.&amp;nbsp; It is documented in the assembly file, rather well in fact, but it doesn't indicate the root cause of this failure.&amp;nbsp; And worse, should handle the this very situation. I'm at a loss as to why this doesn't work.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;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.&amp;nbsp; However, I haven't seen a complete, satisfactory explanation as to why this happens. My hope is that someone out there can explain why....&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Thanks,&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;ACV&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 15 Jun 2016 17:33:54 GMT</pubDate>
      <guid>https://community.nxp.com/t5/LPC-Microcontrollers/JTAG-SWD-cannot-stop-the-LPC1788-CM3-core/m-p/518347#M2620</guid>
      <dc:creator>lpcware</dc:creator>
      <dc:date>2016-06-15T17:33:54Z</dc:date>
    </item>
    <item>
      <title>Re: JTAG/SWD cannot stop the LPC1788 CM3 core</title>
      <link>https://community.nxp.com/t5/LPC-Microcontrollers/JTAG-SWD-cannot-stop-the-LPC1788-CM3-core/m-p/518348#M2621</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by Dave on Wed Nov 21 00:32:19 MST 2012&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;I also have had this happen, and there was no way to revive the JTAG interface from within Keil MDK...&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;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&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;What I discovered was the code that locked up the JTAG port had invalid values for setting up PLL0...&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;I'll be curious to see what NXP has to say here...&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Thanks for posting this question!&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 15 Jun 2016 17:33:55 GMT</pubDate>
      <guid>https://community.nxp.com/t5/LPC-Microcontrollers/JTAG-SWD-cannot-stop-the-LPC1788-CM3-core/m-p/518348#M2621</guid>
      <dc:creator>lpcware</dc:creator>
      <dc:date>2016-06-15T17:33:55Z</dc:date>
    </item>
    <item>
      <title>Re: JTAG/SWD cannot stop the LPC1788 CM3 core</title>
      <link>https://community.nxp.com/t5/LPC-Microcontrollers/JTAG-SWD-cannot-stop-the-LPC1788-CM3-core/m-p/518349#M2622</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by Herrbert on Thu Jun 12 08:12:14 MST 2014&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;I know this topic is really old. But I had the same problem and traced it down to this command:&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;LPC_SC-&amp;gt;PCON |=(1 &amp;lt;&amp;lt; 3)&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;The command should deactivate BOD...&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;I have no idea why it is not possible to access the device by JTAG afterwards...&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;CPU is a LPC1788&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Regards&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 15 Jun 2016 17:33:56 GMT</pubDate>
      <guid>https://community.nxp.com/t5/LPC-Microcontrollers/JTAG-SWD-cannot-stop-the-LPC1788-CM3-core/m-p/518349#M2622</guid>
      <dc:creator>lpcware</dc:creator>
      <dc:date>2016-06-15T17:33:56Z</dc:date>
    </item>
  </channel>
</rss>

