Recovering bricked LPC55Sxx EVK Boards

While developing applications, it can happen that things go wrong. And in my case I ended up with two LPC55Sxx EVK boards on my desk, which seemed not to be usable any more. The issue: the boards were not accessible with the debug probe, because right after main they muxed the pins in a wrong way :-(.

bricked board with set of debut probes

The standard GDB debug connections (both on-board and off-board) were not able to regain access of the board, because the MCU was running into the fault condition pretty much right out of reset.

Luckily, after a lot of trial-and-error, I have found a way to recover them.

The problem occurred while developing a custom LCD/OLED driver for the LPC55S16-EVK board. Suddenly the board did not respond any more because I had the pin muxing wrong. So I ended up to continue developing with the LPC55S69-EVK, only having that board ‘bricked’ soon again.

Connection Error Message

Each debug probe had different ways to report the error, and for the J-Link it is especially this one:

ERROR: Could not connect to target.
SEGGER J-Link GDB Server V7.62b Command Line Version
JLinkARM.dll V7.62b (DLL compiled Mar 8 2022 15:15:34)
Command line: -nosilent -swoport 2332 -select USB=609100567 -telnetport 2333 -singlerun -endian little -noir -speed auto -port 2331 -vd -device LPC55S16 -if SWD -halt -reportuseraction
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: on
Init regs on start: off
Silent mode: off
Single run mode: on
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: LPC55S16
Target interface: SWD
Target interface speed: auto
Target endian: little
Connecting to J-Link…
J-Link is connected.
Device "LPC55S16" selected.
Firmware: J-Link V9 compiled May 7 2021 16:26:12
Hardware: V9.10
S/N: 609100567
Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB
Checking target voltage…
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target…
ConfigTargetSettings() start
Disabling flash programming optimizations: Compare, SkipBlankDataOnProg
ConfigTargetSettings() end
InitTarget() start
ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF
InitTarget() end
ConfigTargetSettings() start
Disabling flash programming optimizations: Compare, SkipBlankDataOnProg
ConfigTargetSettings() end
InitTarget() start
ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF
InitTarget() end
ConfigTargetSettings() start
Disabling flash programming optimizations: Compare, SkipBlankDataOnProg
ConfigTargetSettings() end
InitTarget() start
ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF
InitTarget() end
ConfigTargetSettings() start
Disabling flash programming optimizations: Compare, SkipBlankDataOnProg
ConfigTargetSettings() end
InitTarget() start
ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF
InitTarget() end
ERROR: Could not connect to target.

My usual recommendation is to try with different debug probes: that’s why I always have a set of SEGGER J-Link, NXP McuLink, NXP LPC-Link2, P&E Multilink or even BlackMagic debug probes available. But in this case: none of them were able to directly regain access to the board using the GDB debug connection.

What ultimately solved the problem was a combination of the SEGGER J-Link Lite Flash programming tool plus the Reset button. For this I used an external debug connection using a J-Link:

Locate and start the SEGGER JFlashLite:

SEGGER J-Flash Lite
Reset Button on LPC55S16-EVK

Start it, then select the correct device used (LPC55S16 in the case below).

Press the ‘Erase Chip’ button: this probably won’t work, so try again and again, while pressing the Reset button on the board: With this, after some trials, it should succeed:

success!

After that, I was able to debug the board(s) again :-).

Bottom line is: a reset button on a board can be worth gold. Plus having as many different debug probes and tools helps for sure too.

So if you end up in the same situation, I hope you find this article and it helps you out. If you own a P&E Multilink, you can use the same approach or using the more advanced power glitching method (see Recovering Cortex-M Microcontroller with a Power Glitch).

Happy recovering 🙂

Links

12 thoughts on “Recovering bricked LPC55Sxx EVK Boards

        • Hi jobe,
          thanks for confirming! Although I believe the debug/SWD connection shall be able to recover from such a situation as well. At least this is how it does on on other families. Not sure why it does not work that way for the LPC (at least 55xx one)?
          Erich

          Like

    • Yes, it is connected, and my thinking would have been that this should do it to, if the debug probe pulls the reset line. But all the debug probes I had were not able to recover it that way somehow. Not sure why.

      Like

  1. If they switch to using an external clock before setting up the pins, you can short the external clock. That will allow the debugger to take control of the chip to reflash it.

    Liked by 1 person

  2. Hi Erich and Eclipsers,

    The LPC5500 ROM security makes situations like this a bit tricky, because the debug port isnt enabled until the ROM decides its safe/appropriate to do so, and that can mean the debug system cant communicate with the MCU fast enough after resetting it in order to get control. ISP mode is one way as the ROM will tidy everything up then go to the ISP routine to allow debug control to happen; however you may need to assert ISP while powering up to ensure all possible I/O conditions are really at the default state.

    A handy way to recover from a bad application is to use the debug mailbox erase. This allows MCUXpresso IDE to instruct a mass erase of flash directly. Its supported for any of the probe types, and there is a shortcut for each (Linkserver (LPC-Link2/MCU-Link), J-Link and PE) next to the “Debug your project” section in the Quickstart section. Select “Erase flash action” from the menu that pops up when you click on one of these icons.

    Finally, if you really want to understand how the debugger does a handshake with the secure ROM on these devices, check out the debug chapter (from memory, I think its Chapter 56 for LPC55S6x). We put quite a bit of effort into explaining this – most users (except our tool partners) don’t need to know or care, but for some it might be helpful 🙂

    Thanks
    Brendon

    Liked by 1 person

    • Hi Brendon,
      many thanks for all the details, appreciated! I was not aware that the ‘flash erase’ action could be used for this. I certainly will try that next time. I know that for Kinetis there is a dedicated recovery action in the programming section, so adding this to other devices certainly would help users to try that thing.

      Like

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.