LPC4357: cannot connect with JTAG anymore

[johanborkhuis]

Hello,

I have a number of boards with the LPC43S57 with SPIFI flash. I can program this using my Segger J-Link debugger. For a test I needed to program the internal flash, but when I tried that I got an error, and from that moment on I could not access the processor anymore using SWD (or JTAG). I tried programming the image in a second board, but there the same happened. So both boards are effectively dead now, as I cannot access them anymore and no valid application is running.

When I try to connect using J-Flash it says that it cannot connect to the target.

What could cause the processor to stop communicating over JTAG? How would it be possible to break the JTAG by just uploading an image into the internal flash? Is it possible to bring these targets back to life?

Regards,

Johan Borkhuis

[kerryzhou]

Hi Johan,

    Do you operate the CPR area, it is in flash address 0x2fc.

  

I don't know whether use CRP3, if yes, your chip will be secured to the highest level, you can't disable it.

Now, I think you can enter UART ISP mode, then use FlashMagic to connect the board.

If you can connect the board, then erase all the flash area at first, then connect the JTAG again.

But, if you even can't connect the chip with UART ISP, I am afraid you secure the chip to highest level, that situation, you can unsecure it again.

Wish it helps you!

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[johanborkhuis]

Kerry,

I have been looking at that, but I checked the SREC file and could not find this value in there. But I might have overlooked something there, looking at wrong address.

It is a strange mechanism though, a special value place in your code. Out code starts directly after the vector table, so it could be that a random value was placed at this location, causing the chip to become unusable.

Regards,

Johan

[nxp65755]

It's extremely unlikely a random value at the CRP offset matches a CRP code. I'd check to see if it's inadvertently turned on in your project settings. One possibility is your application code has muxed one of the debug pins. But, if this is the case, recovery should be a simple matter of booting the part into the ISP then erasing flash.

Thanks and regards,

MCUXpresso Support

[bernhardfink]

There is also the possibility that your software is doing something wrong in the chip setup, for example doing a wrong PLL programming, access bus systems which are disabled etc. This could end up in a system crash which prevents the JTAG/SWD access.

If you go into ISP mode you don't run into the faulty code, you stay in the ROM bootloader. Then you can try this access on the UART ISP port with Flash Magic. You can try it with JTAG as well, but then you need to configure the debugger in such a way that it doesn't issue a reset to the target. Otherwise the LPC43xx starts over and executes the faulty firmware before the debugger starts with JTAG communication.

For this reason I always had a 2 seconds loop at the beginning of my proto software, in order to give the debugger a chance to connect before some potentially dreadful code starts running.

Regards,

Bernhard.

[johanborkhuis]

Bernhard,

I would expect that this would not be the problem. The code I was using was moved from external SPIFI flash to internal flash for some testing, so the chip setup should be correct. I also looked at the ISP mode, but as far as I understand it this processor will always execute the internal flash, independent of the setting of the selection bits for SPIFI, UART or USB.

Regards,

    Johan

[bernhardfink · Accepted solution]

Hi Johan,

the ISP mode comes first if you activate it with the right boot mode pin (P2_7 on LOW) during reset.

• fix ISP boot pin P2_7 to low, the other boot pins P1_1, P1_2, P2_8, P2_9 also on low
• perform a power-on reset (not just a reset). There are values in the battery domain, which survive a reset
• connect to UART0 and use FlashMagic tool to erase the internal flash

If you moved a program from SPIFI to the internal flash, did you generate the checksum required for the flash image (or more precisely, let the compiler tool generate it) ? This flash checksum is at a reserved location in the area of the vector table (0x1C) and is checked by the Boot ROM if the flash content is (most likely) a valid executable code.

Besides wrong PLL settings, the wrong number of wait states for the internal flash is also a popular reason for code crashing.

Regards,

Bernhard.

[johanborkhuis]

I did pull pin P2_7 low and now I am indeed able to connect to the processor again using my J-Link. I can read the complete flash, and saved it for later analysis. The CPR was not written (still had 0xFFFFFFFF), so it must have been some kind of init.

I erased the internal flash and programmed the SPIFI again and the unit is working again. Thanks for your help!