• State Not Answered
  • Replies 1 reply
  • Subscribers 93 subscribers
  • Views 33 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 361153
Options

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?

Parents
  • 0

    I would add,

    Most likely it is a Nordic integration/support issue at the boundary with SEGGER, not a simple “SEGGER is broken” issue.

    Why:

    • SEGGER/J-Link can see and debug the LM20A core through the nRF54L15 DK: SWD-DP, Cortex-M33, secure debug, halt, registers, and memory access all work.
    • Nordic’s own nrfutil can program the same target through the same probe and wiring.
    • Nordic’s nRF Connect Programmer also sees the LM20A but cannot read/write it in this external-target setup.

    That last point matters most. If it were only a SEGGER defect, you would expect Nordic Programmer—using Nordic’s intended tooling—to have a clearer working path. Since both the raw J-Link path and Nordic Programmer fail while nrfutil device program works, the likely split is:

    Layer Status
    Physical SWD wiring / target power Good
    nRF54L15 DK onboard probe Good
    LM20A debug access Good
    Nordic device-programming protocol Good via nrfutil
    Generic J-Link RAMCode flash path Fails
    nRF Connect Programmer external-LM20A workflow Fails

    So the practical diagnosis is:

    Nordic has a working programming implementation in nrfutil, but the same required LM20A flash initialization/algorithm is not successfully available through the J-Link Commander and nRF Connect Programmer external-target workflows you tested.

    Who fixes what depends on the root cause:

    • If the LM20A needs a special flash-init sequence or Nordic-owned flash algorithm, Nordic needs to expose/support that path in Programmer or document it.
    • If SEGGER has the proper LM20A flash loader but it fails through the nRF54L15 DK OB probe, SEGGER needs to fix the J-Link RAMCode/flash-loader behavior.
    • If the DK’s onboard J-Link has a limitation for external LM20A targets, it is a Nordic DK firmware/integration issue.

    Your Nordic contact is the right first escalation because:

    1. they own the silicon and official workflow,
    2. nrfutil already proves Nordic has a working route,
    3. they can tell you whether an nRF54LM20 DK is required or whether the L15 DK external probe is officially supported for this target.

    Then send the same evidence to SEGGER if Nordic says: “This external J-Link configuration should program LM20A.”

    Please advise,
    PJ Glasso

Reply
  • 0

    I would add,

    Most likely it is a Nordic integration/support issue at the boundary with SEGGER, not a simple “SEGGER is broken” issue.

    Why:

    • SEGGER/J-Link can see and debug the LM20A core through the nRF54L15 DK: SWD-DP, Cortex-M33, secure debug, halt, registers, and memory access all work.
    • Nordic’s own nrfutil can program the same target through the same probe and wiring.
    • Nordic’s nRF Connect Programmer also sees the LM20A but cannot read/write it in this external-target setup.

    That last point matters most. If it were only a SEGGER defect, you would expect Nordic Programmer—using Nordic’s intended tooling—to have a clearer working path. Since both the raw J-Link path and Nordic Programmer fail while nrfutil device program works, the likely split is:

    Layer Status
    Physical SWD wiring / target power Good
    nRF54L15 DK onboard probe Good
    LM20A debug access Good
    Nordic device-programming protocol Good via nrfutil
    Generic J-Link RAMCode flash path Fails
    nRF Connect Programmer external-LM20A workflow Fails

    So the practical diagnosis is:

    Nordic has a working programming implementation in nrfutil, but the same required LM20A flash initialization/algorithm is not successfully available through the J-Link Commander and nRF Connect Programmer external-target workflows you tested.

    Who fixes what depends on the root cause:

    • If the LM20A needs a special flash-init sequence or Nordic-owned flash algorithm, Nordic needs to expose/support that path in Programmer or document it.
    • If SEGGER has the proper LM20A flash loader but it fails through the nRF54L15 DK OB probe, SEGGER needs to fix the J-Link RAMCode/flash-loader behavior.
    • If the DK’s onboard J-Link has a limitation for external LM20A targets, it is a Nordic DK firmware/integration issue.

    Your Nordic contact is the right first escalation because:

    1. they own the silicon and official workflow,
    2. nrfutil already proves Nordic has a working route,
    3. they can tell you whether an nRF54LM20 DK is required or whether the L15 DK external probe is officially supported for this target.

    Then send the same evidence to SEGGER if Nordic says: “This external J-Link configuration should program LM20A.”

    Please advise,
    PJ Glasso

Children
No Data
Related
Terms of service