nRF54LM20A external SWD programming issue and LM20 DK request

[PjGlasso]

Hi Folks & experts 

I hope you ALL are well.

I wanted to share a bring-up result from my XIAO nRF54LM20A workbench and ask for your guidance.

I have the XIAO nRF54LM20A mounted on the Seeed expansion board and connected by external SWD to the P19 external-debug port of an nRF54L15 DK. The nRF54L15 DK onboard J-Link connects to the LM20A reliably:

• Target selected: nRF54LM20A_M33

• SWD-DP detected: 0x6BA02477

• Cortex-M33 identified

• Secure debug enabled

• Halt, register reads, and memory reads all work

• RTT/UART output works after programming

I built a Zephyr/NCS v3.2.1 hello-world/demo application using the Seeed XIAO nRF54LM20A board files. Nordic nrfutil programs the resulting merged.hex successfully through the same nRF54L15 DK probe:

nrfutil device program --firmware C:\ncs\v3.2.1\build\merged.hex --serial-number 1057729516

After reset, the application runs and produces serial output, including LED and IMU data.

The issue is with direct J-Link Commander flash operations. I tested current J-Link software, including V9.30a, with the nRF54L15 DK onboard J-Link firmware dated July 8, 2025. J-Link Commander can connect and debug the LM20A, but both erase and loadfile fail with:

“Timeout while preparing target, RAMCode did not respond in time!”
“Failed to perform RAMCode-sided Prepare()”

This happens at 500 kHz SWD as well as 1 MHz. Because nrfutil programs the same target successfully through the same physical setup, the wiring, target power, SWD access, build artifact, and basic debugger path appear sound.

SEGGER’s supported-device information indicates nRF54L-family support, so I am trying to determine whether this is:

1. a limitation or defect in the J-Link flash-loader/RAMCode path for nRF54LM20A,

2. a requirement for Nordic-specific initialization that nrfutil performs, or

3. a limitation of using the nRF54L15 DK onboard J-Link as an external probe for the LM20A.

I can provide full J-Link logs, the merged.hex, board files, and screenshots if helpful.

same result with J-Link commander Ver. 8.94

Thank you,
PJ Glasso

PS. same tech has always worked, nRF52840, nRF54L15. it does flash, but only with nRFutil, not J-Link, Debug works?

[Kenneth]

Hello,

As a first step, can you just confirm that the supply voltage on the DK is equal the voltage on your board. If not, you can open the nRF Connect for Desktop -> Board Configurator app and modify the voltage to fit your board.

Reason for asking is that it seems to work here:

Kenneth

[PjGlasso]

Hi there,

And thanks Kenneth, for the reply and check, both are 3.3v devices and the DK is set to that as well. The Flash will erase but , I believe its a Bank method being used for that, vs. the RRAM dac and using a READ or Writing command fails with the OB J-Link firmware. I think that it is probably not current enough to be aware of how the new largest RRam Flash on the planet is used is all I can figure , because the same hardware connections and settings Flash fine with NrfUtil commands 100% success. so the disconnect is the OB Jlink and Nordic code that reads/writes.

hope they get it sorted or can say either way if it works or NOT ?

GL :-) PJ :v: