pyocd / pyocd/pyOCD

nrf54lm20a: flash algorithm faults (IPSR=3) and 'pyocd reset' is a no-op

Open
#2,016 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
1.5k
Forks
560
Avg merge
1h 41m
Merged PRs (30d)
3

Description

Summary

With target nrf54lm20a (Seeed XIAO nRF54LM20A, on-board CMSIS-DAP), pyOCD cannot
program the device and pyocd reset has no effect. Reading and mass-erase work fine,
so the probe connection itself is healthy.

Tested with pyOCD 0.44.1 and 0.45, on 5 boards, Windows 11.

Command Result
pyocd list ✅ works
pyocd rtt ✅ works (RTT streaming is reliable)
pyocd erase --mass ✅ works (needed once on fresh boards — they ship with APPROTECT set)
pyocd flash / load ❌ fails inside the flash algorithm with a fault (IPSR = 3 / HardFault); the old image stays on the device
pyocd reset ❌ no effect — the target keeps running, accompanied by NRF54LM20A is not in a secure state

For contrast, the nRF54L15 (target nrf54l) programs flawlessly with pyOCD on the
same host and the same kind of on-board probe, so this appears specific to the
nRF54LM20A target support (RRAM instead of the usual flash controller).

Steps to reproduce

pyocd erase --mass -t nrf54lm20a -u <SERIAL>     # fresh boards: clears APPROTECT
pyocd flash -t nrf54lm20a -u <SERIAL> zephyr.hex # faults in the flash algo
pyocd reset -t nrf54lm20a -u <SERIAL>            # returns, target unaffected

Expected

flash programs the image; reset restarts the target.

Workaround we use

OpenOCD with Seeed's support/openocd.cfg, using the vendor nrf54lm20a-load command
plus verify_image, each command passed as its own -c (chaining them with semicolons
swallows the load/verify output):

openocd -f boards/seeed/xiao_nrf54lm20a/support/openocd.cfg \
  -c "adapter serial <SERIAL>" -c init -c "reset halt" \
  -c "nrf54lm20a-load app.hex" -c "verify_image app.hex" \
  -c "reset run" -c shutdown

We still use pyOCD for list, rtt and erase --mass — those are solid.

Environment

  • pyOCD 0.44.1 and 0.45 (both affected)
  • Windows 11, Python 3.12
  • Seeed XIAO nRF54LM20A (non-Sense), on-board CMSIS-DAP, 5 units — all behave identically

Note

Possibly related to #1985 (pyocd load fails for nRF54L15), but the signature differs
(there: skipped bytes on nRF54L15; here: a fault inside the algorithm on nRF54LM20A) and
nRF54L15 works fine for us — so I am filing this separately rather than piling on.

Happy to run any diagnostic command that would help narrow this down; the hardware is
on my desk.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce with the listed pyocd erase, flash, and reset commands, then inspect the nrf54lm20a target support and the flash/load and reset entry points, comparing them with the working nrf54l target. Use the reported IPSR=3 HardFault and secure-state message to narrow the failures. Done means flash programs the image and reset restarts the target without regressing list, rtt, or mass erase.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
embedded-iot
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.