Cannot Debug LPCXpresso54S018: Debug port inaccessible after access at location 0xBF30B670

[andrewsglenn]

I'm using SDK version 2.15 and open the freertos_hello SDK demo application

I can build normally, but downloading to flash prints an error message saying:

15: Target error from Read Memory
Debug port inaccessible after access at location 0xBF30B670
Debugging context: lpcxpresso54s018_freertos_cabezon LinkServer Debug

The full debug messages are given in the attached text file.

This doesn't happen every time, but often enough to really slowdown productivity (2 times in 3, or more)

I've erased the on-board flash, and this still occurs.

Any ideas?

[robertogatti]

It is a stack overflow error.

Increase your stack size.

[andrewsglenn]

Thank you, Roberto,

We've completed the project now, so I don't have a board to test with. Do you mean the FreeRTOS main stack, or something else?

[robertogatti]

I had the same message just today on a baremetal project, but I think it's the same problem just check the various stacks sizes. The debugger tries to access some protected memory outside the allowed zone. There is no stack overflow fault in these cores I guess.

The only thing I added was more depth in the nested function calls so it was a lucky fix.

[andrewsglenn]

I think I found the answer.

The code was being built to run out of RAM, not out of Flash.

If I go into:

Properties->C/C++ Build->Settings->MCU Linker->Managed Linker Script

And then uncheck "Link Application to RAM" and "Plain Load Image" it appears to work.

@Alice_Yang do you know if there's something to do with the reset strategy when the software is in RAM that could affect it?

[Alice_Yang]

Hello @andrewsglenn 

"Plain Load Image" means an application that runs in SRAM. If it is checked, when reset MCU,  the boot ROM relocates application into a bank of the onboard SRAM for execution. So if the SRAM size is not enough, recommend executed directly from the flash. 

BR

Alice

[andrewsglenn]

My application is 107K and SRAMX is 192K. It should fit

Not that I wanted it in RAM, I wanted it in Flash so I prefer this, but I don't understand why it crashes when placed in RAM.

Can you try switching on "Plain Load Image" in your linker script and running freertos_hello to see if it fails to debug reliably?

[Alice_Yang]

Hello @andrewsglenn 

By default the "Plain Load Image" is checked. I have tested, it works well. 

BR

Alice

[andrewsglenn]

To reproduce in MCUXpresso IDE v11.9.1_2170:

1. Import SDK Examples.
   1. Select lpcxpreso54s018
   2. Select SDK SDK_2.x_LPCXpresso54S018
   3. Click "Next >"
2. Select the freertos_hello example, leaving all other options unchanged. Click "Finish"
3. Click "Debug" in the Quickstart panel
   1. Ensure the LPC-LINK2 debugger is selected and click "OK"
4. Enjoy the crash.

I thought the issue was fixed in 11.10, but it's still present. Drat.

[Alice_Yang]

Hello @andrewsglenn

I tested on my side refer to your steps, and took a video. Please see my attachment. Thanks.

BR

Alice

[andrewsglenn]

@Alice_Yang 

Any idea what's causing this?

I've tried two different LPCXpresso54S018 boards, a Windows 11 desktop and Windows 11 laptop and two different Micro USB cables.

I've connected the USB directly to the PC and laptop, and from the laptop via an externally-powered USB hub and get the same results.

I tried running the software on Fedora 39, but it does not easily install so I've given up for now.

On one board I've tried LinkServer and J-Link firmware on the built-in debugger, and an external J-Link Plus Compact.

I plugged in a USB power meter while debugging with the J-Link Plus, and the power looks good. 5.0V and 0.1A idling, and 0.2A on the rare occasion it downloads and debugs freertos_hello correctly.

What else can I try?

[andrewsglenn]

Addition: Just sent a third board (direct from Digi-Key) to another team-member, unopened. They plug it in and run `freertos_hello` and get the same error.

It's not just me.

[Alice_Yang]

Hello @andrewsglenn 

Refer to your description, I tested as below.

IDE: MCUXpresso IDE v11.9.0

SDK demo：freertos_hello

Board:LPCxpresso54018 

Debugger: On board debugger with cmsis-dap

I debugged some time, haven't find issue.

I take a video about the debug steps on my side, please see my attachment. 

About the jumpers on board please see below.

Debug configuration as below。

If still can't work on your side. Please switch to a new MCUXpresso IDE workspace. Then import project again to test.

BR

Alice

[andrewsglenn]

What are the correct reset settings?

I seem to have better luck with "default" rather than "soft" in that it reliably fails every other debug, rather than randomly failing 70% of the time.

I also set SWCLK, SWDIO and SWO to SWD in the pin config, but that should be default to SWD, shouldn't it?

Glenn

[Alice_Yang]

Hello @andrewsglenn 

I use the on board debugger, debug three time. All works well. 

Before debug again, please confirm "Clean Up Debug".

Updating Media

I took a video for the steps on my side, please see my attachment. 

If still can't work on your side, test with another board. And how about change to another IDE?

BR

Alice

[andrewsglenn]

One difference: I'm using the freertos_hello application, you're using a standalone application.

I've noticed simple standalone applications have a better chance of working with the debugger than FreeRTOS applications do.

[andrewsglenn]

I get the same result with the 'clean up debug' button.

I get the same result using JLinkGDBServerCL.exe directly using the command line at the top of the log. and setting MCUXpresso to attach using the GDB server.

I've tried two LCPxpreso54S018 boards. Both fail to program reliably.

What other IDE do you recommend I try? Segger Ozone would not connect saying "TDO high".

[andrewsglenn]

If I don't get the previous message, I get this one:

[Alice_Yang]

Hello @andrewsglenn 

It is possible to download an image into the flash on the target that will then prevent any further debug access or connections. The classic cases of this are:

• The image contains code that sets the MCU clocks up "incorrectly".
• Not successfully disconnect before re-connect.

If do this, maybe connect failed. Recommend create a new workspace of IDE, import your project again to debug.

BR

Alice

[andrewsglenn]

I used the Erase Flash option in the debug configuration to confirm the flash was erased, then blank-checked it, then power cycled the board. I get the same response.

I have the same issue with several projects in different workspaces.

Is there a way to connect a Segger J-Link to the LPCXpresso54S018 to program and debug the LPC54S018 separately from the LPC-Link? I'd assume you connect to P1, but that seems to connect to the LPC-Link processor.

[Alice_Yang]

Hello @andrewsglenn 

Yes, can use Segger J-link debug the board. Detail refer to Board User Manual:

https://www.nxp.com/webapp/sps/download/preDownload.jsp?render=true 

"

3.3 Starting a debug session using an external Debug Probe
Code running on the LPC546x8/540xx/54S0xx target can be debugged using an external
Debug Probe that conforms to the standard ARM debug connector. To use an external
Debug Probe connect the probe to the SWD connector (P1) and connect power via the
micro USB connector J1.
Note: The Debug link connector J8 must be left unconnected so that the Link2 Debug
Probe is left unpowered and does not contend with the SWD interface signals from the
external Debug Probe.

"

BR

Alice