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 