LPC55S69 bricked after trying to enable SWO debug console

[scottm]

I was trying to reconfigure a project to use SWO for the debug console on account of needing to reassign the FlexComm previously used for the debug UART (the manual could really use a more prominent warning about FlexComm3 not supporting I2S signal sharing) and after flashing my new firmware I lost all ability to debug and program the MCU.

I tried my P&E Cyclone ACP with MCUX and in standalone mode, and I tried an MCU-Link and an LPC-Link2. None of them could establish a connection. I tested it out on my LPCxpresso55S69 board with its built-in LPC-Link and it did the same thing - bricked it with no ability to erase and try again.

The solution for now is to pull the clock crystal, which halts execution before the code can get as far as the debug console init.

How is this possible? Why are the debug interfaces not able to force the CPU into debug mode without letting them run first? Is there some workaround?

I saved the 'poison' firmware image and I'm happy to share if you'd like to recreate the issue.

Thanks,

Scott

[Harry_Zhang]

Hi @scottm 

According to your description, 

When you enabled SWO output  and reconfigured the debug console, you most likely modified the clock source or pin muxing in a way that unintentionally affected the SWD/SWO pins  or the  debug clock domain.

When you reset and power up:

If your firmware reconfigures clocks, pins, or secure settings very early (e.g. before SystemInit() finishes),

the debugger never gets a chance to run before the MCU becomes unreachable.

So i think you can disable swo in early boot.

BR

Harry

[scottm]

Hi Harry,

It's not enabling it early in the boot process. It happens in main(), after BOARD_InitBootPins() and BOARD_InitBootClocks(). That's the only way I was able to recover it - because it was after the switch to the external crystal, I could desolder the crystal and make sure it hung there forever.

Shouldn't the debugger be able to at least perform a mass erase regardless of what the target is doing? How do I recover an MCU like this if I'm not able to stop it by pulling the crystal?

Thanks,

Scott

[Harry_Zhang]

Hi @scottm 

The SWD debugging interface of LPC55S69 depends on the clock.
Your code may have changed the debugging clock or PIN MUX when switching to an external crystal oscillator and enabling SWO in the later stage of main(),
Causing the debugging port to lose clock, making it impossible for the debugger to reconnect or erase.

So i think you can try to 

Use your debug probe’s Connect under Reset on connection option. 

In MCUXpresso IDE,

BR

Harry

[scottm]

Hi Harry,

That didn't seem to change anything. I tried with one of the boards I haven't pulled the crystal from yet, that I bricked with the bad firmware load, and it's still unable to connect. I've tried similar settings for the P&E interface.

The only change from the firmware versions that have worked for years is this:

SystemCoreClockUpdate();
DbgConsole_Init(DEBUG_CONSOLE_SWO_PORT, DEBUG_CONSOLE_SWO_BAUDRATE, kSerialPort_Swo, SystemCoreClock);

Just to make sure we're on the same page, can you confirm that there should still be a way to erase and reload a device as long as flash protection isn't enabled?

Thanks,

Scott

[Harry_Zhang]

Hi @scottm 

I think you  can put the chip into ISP mode and then use ISP commands to erase the first 1KB or 10KB of the flash to corrupt the firmware header, preventing the chip from jumping to the firmware, and then connect using a debugger.

The isp pin is PIO0_5.

And then use blhost command.

By the way, what is your application?

BR

Harry

[scottm]

Hi Harry,

That might work for the LPCxpresso55S69 board, but it doesn't help with any of my own boards. With MON08 and BDM debuggers on older MCUs there was always a way to mass erase the flash no matter what was loaded - it'd go into debug mode right out of reset. Is SWD just not capable of that?

In the course of troubleshooting this I've run into some other issues I'm following up on. When I wrote this bootloader back in 2023, I noticed that the LPC55S69 documentation was ambiguous about the top of usable flash memory - in one place it says 16 pages / 10 kB are reserved and in another it says 17 pages / 10 kB. 16 pages would be 8 kB and 17 pages is 8.5 kB, so obviously something's wrong there.

As far as anyone can tell, the correct top of memory is 0x9d800. When I checked the debugger memory configuration files, the top was given as 0x98000, which is definitely wrong. I reported this in a thread back in 2023.

Apparently those memory configurations were fixed at some point (though there's still no updated errata for the LPC55S69) but I discovered that my project file kept the old (incorrect) settings. While trying to sort it out, I ended up uninstalling all versions of MCUXpresso and Linkserver and deleted all of my launch configurations and then after reinstalling discovered that the project also seemed to be referencing an out-of-date Linkserver. P&E's drivers are harder to sort out because the Cyclone ACP isn't even listed on their site.

Recreating the entire project with the latest IDE would take hours of work to manually document and recreate all of the settings and then do regression testing. Do you know of any other places that out of date debugger references could be hiding? Something's definitely still wrong. At one point the only way I could get it to program was by using the P&E standalone PROGACMP utility - which proved that the MCU was responding just fine with the same debugger and the same connections, but through gdb it simply wasn't working. At the moment the only interface I can get to work reliably with the project is an old LPC-Link2 I found in a drawer.

To answer your question, this particular project is a multi-channel RoIP interface.

Thanks,

Scott

[Harry_Zhang]

Hi @scottm 

That might work for the LPCxpresso55S69 board, but it doesn't help with any of my own boards. With MON08 and BDM debuggers on older MCUs there was always a way to mass erase the flash no matter what was loaded - it'd go into debug mode right out of reset. Is SWD just not capable of that?

This occurs because during the process of connecting the debugger to the chip, the chip is reset and then executes code from its flash memory. Since the customer's code modifies the SWD-related I/O functions during this process, it ultimately causes the debugger connection to fail. This is why erasing part of the flash at starting position resolves the issue.

Regarding the size of the flash, it should be 631.5 KB, the last 17 pages(8.5 KB) are reserved, I am currently confirming this internally.

BR

Harry

[scottm]

There's definitely something more going on than pins getting reassigned. Debugging in MCUXpresso has always been very unreliable for me and I'd love to get to the bottom of it. It was working fine for the first half of the day. I made a minor change (enabling the FreeRTOS vApplicationMallocFailed() hook and defining a function with __BKPT(0)) and haven't been able to load and debug anything since, with either the Cyclone or LPC-Link2.

The connection is fine. And in fact I'm able to connect with PROGACMP and erase the device, and verify that it's erased. It's coming back all 00 when on most devices I expect FF, so I don't know if that's right, but it's at least passing the blank check.

Even with an erased device, I can't do anything with it. Here's what I get with the GUI flash tool. There are a few things going on here - first, the dialog indicates it completed when the log shows that it failed. And from the log you can see that it's got the wrong range, or at least not the complete range.

I can also use the Cyclone to program a known-good image and the device runs, but I still can't do anything from MCUX.

I'm going to reboot now and see if that makes any difference.

[scottm]

OK, I'm making some progress. I eliminated several things - tried a new board, another debug interface, a brand new cable, and tried using the LPCxpresso board as well. None of them would get past the "Range could not be erased" error.

Now, when I said the erase range wasn't correct, or wasn't complete, that's because this project has a bootloader image included at 0x9b000 with some reserved space at 0x9a000 for bootloader commands. It wasn't showing the high range.

So to check if it had something to do with that high range, I loaded the hello_world sample project and it erased and programmed just fine. It's not a hardware problem at all.

Next, I switched over to the bootloader's own standalone project. This project has been untouched for a year or two. It links as a standalone application so that it can optionally be loaded on a blank device and will pick up its firmware update from external SPI flash, so it has a vector table of its own.

I tried debugging it with the P&E debug configuration that hasn't been touched in ages. It failed with the same error:

Erasing ranges ...

Range 00000000-00001FFF 




Range could not be erased. 

Note that the 0000-1FFFF range only reflects the vector table and not the code. To test if this was a problem with non-contiguous memory areas, I created a new memory section called UNUSED_FLASH that occupies the rest of flash and used FILL(0x55) to give it some data. When it's linked, it shows it 100% full:

Memory region Used Size Region Size %age Used

VECTOR_FLASH: 304 B 1 KB 29.69%

COMMAND_FLASH: 60 B 512 B 11.72%

SVECT: 4 B 4 B 100.00%

UNUSED_FLASH: 633344 B 633344 B 100.00%

PROGRAM_FLASH: 9880 B 10236 B 96.52%

SRAM: 9528 B 16 KB 58.15%

USB_RAM: 0 B 16 KB 0.00%

Finished building target: LPC55S69_Bootloader.axf

I launched it again, with the same problem. It shows that it's erasing only the 0000-1FFF range, and it fails. So whatever's going on seems to be related to how it determines which ranges to erase and how it verifies the upload.

This seems to be a recent thing (I'm running MCUX v25.6 build 136) and my hunch is that it feels like all of the other unreliable, quirky debug behavior I've encountered with MCUX because the IDE just has bad integration with gdb. Here's how the session ends:

PEmicro GDB Launch Failure : Error during flash programming. Terminating debug session.




PE-ERROR: Error downloading to the device. Terminating debug session.

Disconnected from "127.0.0.1" via 127.0.0.1. Disconnection by port "52065" from 6225

Disconnected from "127.0.0.1" via 127.0.0.1. Disconnection by port "52070" from 7225

INFO: DAP IDCODE = 0x6BA02477 

Target Disconnected.

Except it doesn't actually end - I can hear the CPU fan kick on and arm-none-eabi-gdb.exe consumes 100% CPU time on one core. Here's gdb's output:

611,647 (gdb)

611,648 &"load B:\\\\home\\\\eb6\\\\bootloader\\\\Debug\\\\LPC55S69_Bootloader.axf\n"

611,648 ~"Loading section .text, size 0x130 lma 0x0\n"

611,648 26+download,{section=".text",section-size="304",total-size="1801748"}

611,648 26+download,{section=".text",section-sent="304",section-size="304",total-sent="304",total-si\

ze="1801748"}

611,648 ~"Loading section .commands, size 0x3c lma 0x9ae00\n"

611,648 26+download,{section=".commands",section-size="60",total-size="1801748"}

611,648 ~"Loading section .startvector, size 0x4 lma 0x9b000\n"

611,648 26+download,{section=".startvector",section-size="4",total-size="1801748"}

611,648 ~"Loading section .text, size 0x2690 lma 0x9b004\n"

611,648 26+download,{section=".text",section-size="9872",total-size="1801748"}

611,650 ~"Loading section .data, size 0x8 lma 0x9d694\n"

611,650 26+download,{section=".data",section-size="8",total-size="1801748"}

611,663 27interpreter-exec mi2 "-break-insert -t -f main"

611,788 28-list-thread-groups

615,695 &"Error finishing flash operation\n"

615,695 26^error,msg="Error finishing flash operation"

615,695 (gdb)

615,695 &"monitor selectcore 0\n"

615,695 @"Command Executed successfully: selectcore 0\r\n"

615,695 ^done

615,695 (gdb)

615,695 &"interpreter-exec mi2 \"-break-insert -t -f main\"\n"

615,702 &"warning: could not convert 'main' from the host encoding (CP1252) to UTF-32.\nThis normall\

y should not happen, please file a bug report."

615,702 &"\n"

615,705 ~"Note: automatically using hardware breakpoints for read-only addresses.\n"

615,705 ^done,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0009b138",func="main\

",file="../source/LPC55S69_Bootloader.c",fullname="B:\\home\\eb6\\bootloader\\source\\LPC55S6\

9_Bootloader.c",line="150",thread-groups=["i1"],times="0",original-location="main"}

615,705 27^done

615,705 (gdb)

615,705 29flushreg

continue

monitor refreshviews

continue

615,705 28^done,groups=[{id="i1",type="process",pid="42000",executable="B:\\home\\eb6\\bootlo\

ader\\Debug\\LPC55S69_Bootloader.axf"}]

615,705 (gdb)

615,705 &"flushreg\n"

615,705 ~"Register cache flushed.\n"

615,707 30-list-thread-groups i1

615,721 29^done

615,721 (gdb)

615,721 &"continue\n"

615,721 ~"Continuing.\n"

615,721 ^running

615,721 *running,thread-id="all"

615,721 (gdb)

615,766 &"warning: Exception condition detected on fd 528\n"

And if you'll recall from my last message, the GUI flash tool similarly doesn't properly register fault conditions.

For now I'm up and running by excluding my bootloader from the .ld file.

Let me know what you think about the non-contiguous memory erase/verify problem. And I would be happy to help your developers with testing fixes to the gdb integration because that's been a constant headache for years.

Regards,

Scott

[scottm]

One more update before I give this a rest for the evening. I'm able to reproduce the problem, at least for P&E, by modifying the led_blinky demo. This not only fails the "Erasing ranges" operation, it also frequently crashes gdb.

To reproduce, load up the led_blinky demo for the LPCxpresso55S69 board. Disable the managed linker script. Add some dummy data:

__attribute__((used, section(".dummy")))
const char dummy_data[] = {1,2,3,4,5,6,7,8,10};

Edit the .ld files to add a high section:

MEMORY
{
/* Define each memory region */
PROGRAM_FLASH (rx) : ORIGIN = 0x0, LENGTH = 0x90000 /* 630K bytes (alias Flash) */
UPPER_FLASH (rx) : ORIGIN = 0x9d600, LENGTH = 0x20 
SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x40000 /* 256K bytes (alias RAM) */ 
SRAMX (rwx) : ORIGIN = 0x4000000, LENGTH = 0x8000 /* 32K bytes (alias RAM2) */ 
USB_RAM (rwx) : ORIGIN = 0x40100000, LENGTH = 0x4000 /* 16K bytes (alias RAM3) */ 
SRAM4 (rwx) : ORIGIN = 0x20040000, LENGTH = 0x4000 /* 16K bytes (alias RAM4) */ 
}

 .dummy : ALIGN(4)
{
KEEP(*(.dummy))
. = ALIGN(4);
} > UPPER_FLASH

Build and upload. Twiddle dummy_data and one of the timer constants to make sure the code changes. Recompile and upload again and it fails.

Scott

[Harry_Zhang]

Hi @scottm 

Sorry, Can you share  your project so that i can reproduce this issue?

BR

Harry

[scottm]

Here you go.

[Harry_Zhang]

Hi @scottm 

Thanks for your project.

I have conducted multiple tests on my lpc55s69 EVK board.

I can debug it successfully every time.

I can mass erase  successfully every time.

I am sorry i can not reproduce the issue you reported.

How can i reproduce this issue?

BR

Harry

[scottm]

Hi Harry,

There are at least two different issues here. The blinky demo I shared illustrates the problem with the P&E driver. I've talked to P&E and they believe it's a problem with the erase function in their driver, which they're working on. The workaround for now is to set it to erase the whole chip rather than having it erased only the used areas.

The other problem doesn't appear with a new project. I've found that the underlying problem is that the memory definition MCUX had for the LPC55S69 was wrong:

It should be 0x9d800, not 0x98000. This is from a project created two years ago. The problem has been fixed in MCUX at some point since then, but the project was created with the incorrect setting and carried that over. If there was any mention of this in the MCUX release notes, I didn't see it.

Now, what I see as an additional problem is the lack of any meaningful error message. This should generate some kind of warning that it's trying to program outside of the defined memory range. Instead we just get a generic failure:

The original cause of all of this mess seems to have been bad documentation:

The LPC55S69 uses 512-byte pages so 16 pages is 8 kB and the above cannot be correct. What's worse is that someone has looked at this and corrected the figure from 17 pages to 16 but didn't correct the size:

If the memory map had simply stated the upper bound of the non-reserved flash area all of this could have been avoided. As it is, the datasheet still does not make the upper bound clear. If we subtract 16 pages from 0x9ffff we get 0x9dfff for the top of flash. If we subtract 10k we get 0x9d7ff for the top. The PFR documentation shows that the PFR starts at 0x9de00:

Nothing in the datasheet would seem to account for the space between 0x9d800 and 0x9de00.

The usable program memory range is one of the most basic parameters needed to program any MCU and the datasheet manages to obfuscate it so thoroughly that both NXP and P&E got the implementation wrong.

To recap: P&E is fixing their driver. The workaround is to erase the whole device. Projects created with the wrong memory definition must be manually updated to reflect the correct range before the RedLink driver will work. As of rev 2.8, the UM11126 manual still contains incorrect information about the flash size. And there's a lot of room for improvement in how the IDE presents failures during the programming process.

Scott

[Harry_Zhang]

Hi @scottm 

Thank you for identifying this issue and sharing your observations. We will review the documentation and IDE behavior to ensure better clarity and user experience going forward.

BR

Harry