On further analysis I don’t think that’s it 
It could also be related to bandwidth? The UM3301DA has a high enough bandwidth (~20MHz) but may it may not be suitable for the high speed SWDIO transition requirements. This could be a “load vs isolation” issue?
I was thinking that this might be a speed issue, I wonder if it’s just trying to read slightly faster than the device is ready for, getting enough errors and faulting. I believe there’s a way to specify a slower rate on the command line.
The SWCLK frequency is approximately 1.3MHz.
When running a script on a bricked XIAO, the first attempt always fails. From the second attempt onward, the full erase succeeds no matter how many times it is executed. However, once the power is turned OFF, it bricks again. This cycle repeats. It reproduces very reliably.
2 Likes
After running the script to perform a full erase and then turning off the power, it bricks again. However, if you upload something like blinky after the full erase, it won’t brick even after turning off the power.
My XIAO suddenly bricks while in use, and since I don’t understand the root cause of the bricking, I don’t know if this method provides a complete fix or if it’s just a temporary solution.
I was observing the signal level by placing the expansion board pins on the pads of the back side, but since the pin tips are rounded, they couldn’t break through the oxide layer on the pads and were causing poor contact.
After soldering them, I was able to observe the level properly.
I don’t think this issue is related to brick.
Are you using the nrf54L15 that keeps bricking in an expansion base? I’m curious if this might be related.
I also use it mounted on an expansion board. Since SWDIO and SWCLK are constantly stimulated, that might be the cause.
I have the problem without any extensions connected.
My nRF54L15 has only ever been put into an ap-protect locked up state by my own bad code. Thanks for helping eliminate the carrier board possibility as a cause.
1 Like
I had a similar issue as reported by toastee0 with openocd.
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* nrf54l.cpu cortex_m little nrf54l.cpu unknown
1 nrf54l.aux mem_ap little nrf54l.cpu running
I was able to recover the board with a j-link edu. Claude the AI recommended this set of commands and it recovered the board.
# Launch J-Link Commander
JLinkExe -device nRF54L15_xxAA -if SWD -speed 4000
# In the J-Link prompt:
connect
halt
erase
loadfile firmware.hex
reset
go
exit
I have been avoiding that board so I can’t say if it is fixed for good.
Hi there,
So, I’m able to blow up either one of my XIAO’s with code, the nRF54L15 sense or BLE only version. Mostly Memory writes… usually the result of a misconfigured or even more 
mis-understood concept of how stuff works in the chair.
So one little prj.conf or xiao_nrf54l15_nrf54l15_cpuapp.overlay and crash city… as in all things turn on the LOGGING helps and setting a good debug level will give you some meaningful info on the console before it locks or Halts 
here is some stuff:
this one is memory…
- west flash: using runner openocd
-- runners.openocd: Flashing file: D:/Nordic/myapps/workspace/T_ROLO/build_xiao/merged.hex
Open On-Chip Debugger 0.12.0 (2023-01-14-23:37)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
nrf54l-load
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2886:0x0066, serial=E4E44CBA
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Serial# = E4E44CBA
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x6ba02477
Info : [nrf54l.cpu] Cortex-M33 r1p0 processor detected
Info : [nrf54l.cpu] target has 8 breakpoints, 4 watchpoints
Info : starting gdb server for nrf54l.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : gdb port disabled
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* nrf54l.cpu cortex_m little nrf54l.cpu running
1 nrf54l.aux mem_ap little nrf54l.cpu running
[nrf54l.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xf9000000 pc: 0x0000252c msp: 0x20008e10
219132 bytes written at address 0x00000000
468 bytes written at address 0x00035800
30480 bytes written at address 0x000359e0
downloaded 250080 bytes in 4.876161s (50.084 KiB/s)
Error: [nrf54l.cpu] clearing lockup after double fault
[nrf54l.cpu] halted due to debug-request, current mode: Handler HardFault
xPSR: 0x09000003 pc: 0xeffffffe msp: 0x20008d28
shutdown command invoked
PS D:\Nordic\myapps\workspace\T_ROLO>
Jlink , connect and erase , Then Loadfile with known good HEX no issues after that TECH. all other methods read and write it after.
here is a programmer read after the recovery, READ…
File on left , Xiao on the Right.
I’m wondering if the OpenOCD doesn’t do a complete erase or better a correct sector erase before it rewrites, which BTW is how it normally does it, not a full erase. This may be why if We full erase outside of it(whatever version) it works again, but the OpenOcd fails… food for thought.
Also the Chocolatey OpenOcd doesn’t have what the NCS_OpenOcd has or visa versa, be aware. I’m looking more into it, I would imagine it includes the scripts. (those can lean on the Python system too)
here is a text from a Bad GPIO , interrupt mis configured… had to JLink it back. (i’ll post a video of the process I used)
Crash log output, no touch INT hooked..
---- Opened the serial port COM25 ----
[00:00:00.158,827] <err> chsc6x: Could not configure interrupt GPIO interrupt: -134
*** Booting nRF Connect SDK v3.1.1-e2a97fe2578a ***
*** Using Zephyr OS v4.1.99-ff8f0c579eeb ***
[00:00:00.158,956] <err> os: ***** MPU FAULT *****
[00:00:00.158,961] <err> os: Data Access Violation
[00:00:00.158,965] <err> os: MMFAR Address: 0xc
[00:00:00.158,975] <err> os: r0/a1: 0x00000000 r1/a2: 0x00000009 r2/a3: 0x00000000
[00:00:00.158,982] <err> os: r3/a4: 0x00000000 r12/ip: 0x00000000 r14/lr: 0x0001dccd
[00:00:00.158,986] <err> os: xpsr: 0x69000000
[00:00:00.158,990] <err> os: Faulting instruction address (r15/pc): 0x0002e382
[00:00:00.159,015] <err> os: >>> ZEPHYR FATAL ERROR 19: Unknown error on CPU 0
[00:00:00.159,029] <err> os: Current thread: 0x20001218 (unknown)
[00:00:00.237,071] <err> os: Halting system
Once they are Jlinked back , I use @msfujino’s IMU test “zephyr.hex” for the Sense version because I get Visual display and IMU test in one (video forthcoming )
for the BLE only I use the WatchFace.hex (rolo) because the Flasher’s used all provide a reset the result it instant…or pretty close, so you know if it works or not.
If the connections are not solid and reliable the SWD is sketchy and requires several retries until it pops. But with shorter cables it works repeatable every time.
HTH
GL 
PJ 
I just double tap it with the pyocd erase script using the onboard dap link. For some reason I always have to run it twice but it always seems to work.
Hi there,
So , that is right in line with what I’m thinking , the OpenOCD pulls a config, AFAIK Openocd, when flashing
" With OpenOCD, the program command sector-erases whatever regions it’s about to write, so your west flash -r openocd … already erased the necessary pages before programming."
If you want to force a full-chip erase (e.g., to clear leftovers/UICR), you’ve got a few options:
west flash -d build_xiao -r openocd --erase
or, Pure OpenOCD: mass erase only (Adjust the interface path if needed.)
openocd -f interface/cmsis-dap.cfg -f target/nrf54l.cfg ^
-c "init; halt; flash erase_sector 0 0 last; shutdown"
That erases all sectors of flash bank 0. After that, program as usual:
openocd -s "C:/ncs/toolchains/c1a76fddb2/opt/share/openocd/scripts" `
-f interface/cmsis-dap.cfg `
-f target/<TARGET_FILE> `
-c "adapter speed 1000; init; halt; nrf54l mass_erase; sleep 200; reset halt; exit"
Chocolatey OpenOCD, which doesn’t have Nordic’s nRF54L scripts. Use the OpenOCD that ships with NCS and point it at its scripts folder.
to Program
openocd -s "C:/ncs/toolchains/c1a76fddb2/opt/share/openocd/scripts" `
-f interface/cmsis-dap.cfg `
-f target/<TARGET_FILE> `
-c "adapter speed 1000; init; halt; program D:/Nordic/myapps/workspace/T_ROLO/build_xiao/merged.hex verify reset exit"
Notes
- If
nordic_nrf54l.cfg(or similar) isn’t present, your OpenOCD build may be too old. Use the OpenOCD bundled with NCS (the onewest flashuses), which lives under the same…\opt\toolchain tree you referenced above. - You can also try a board cfg if one exists, e.g.
-f board/seeed_xiao_nrf54l15.cfg. - Keep
adapter speed 1000(or lower) if you see SWD reliability issues. - Use a mass erase only when you suspect residue (e.g., in config/UICR areas) is causing odd behavior. Otherwise, the normal
west flash -r openocdflow is fine and faster.
J-Link’ng it means,
-ERASE and WRITE…(loadfile c:\path\to\gold\merged.hex)
HTH
GL PJ
Had to do a mass erase due to an upload failure. so i grabbed a screenshot of the “double tap” method I have to use.
the original upload failed while inserted into xiao expansion base loading a really simple sample file.
Hi there,
So Good catch, I’m starting to wonder if the flash is suspect or this new ram they are using isn’t quit dialed in yet. Or more likely the OpenOCD nrf54l15 config file isn’t all it needs to be .We are definitely working this thing out LOL
GL PJ
I’m getting more of the issues when flashing in the Xiao expansion board. Especially if I don’t pay attention to if the pogo pins are fully engaged.
I know you made the big buttons… do you think you could make a board clip or something we could 3D print to hold the unit in place too?
Hi there,
SO , long over due… Yes just getting the new printer dialed in so it a WIP but time to STOP using the Alien LOW Tech solution AI couldn’t have thunk it
Pink no less … 
HTH
GL PJ
1 Like
I have one of those crappy dollar store clamps somewhere!
The nRF54L15 Wiki provides a factory reset script. Since devices may occasionally become bricked when frequently using OpenOCD, this script enables quick restoration of the device to a functional state.
1 Like