Xiao nRF54L15 Development Guide: VSCode + nRF Connect SDK

I’ve created two markdown development guides for the Xiao nRF54L15, optimized for use with GitHub Copilot and other AI coding assistants in VSCode with the nRF Connect extension.

Two versions for different use cases:

  • Full Guide (nrf54l15-guide-full.md): Human-readable with detailed explanations, examples, and context. Best for learning and reference.

  • Compressed Guide (nrf54l15-guide-compressed.md): ~65% smaller, AI-optimized for context window efficiency. Contains all essential information in a token-efficient format.

Both guides cover:

  • Complete build/flash/debug workflows

  • Environment setup (temporary & permanent)

  • Multi-core development (ARM Cortex-M33 + RISC-V FLPR)

  • Device tree aliases and peripheral access

  • Recovery procedures for bricked boards

  • GDB debugging commands

  • Project structure requirements

Key features:

  • Enables fully automatic build/flash/recovery inside VSCode with nRF Connect

  • Includes links to Xiao-specific sample code repository

  • PowerShell commands tested on Windows

  • Works with nRF Connect SDK v2.7.0+ (v3.2.0-preview2+ recommended)

Use the compressed version when working with AI assistants that have limited context windows, or switch to the full guide when you need more detailed explanations.

nrf54l15-guides.zip (7.1 KB)

6 Likes

Hi there,

WOW

We know how the nRF54 series is brand-new, multi-core, and full of quirks :face_with_open_eyes_and_hand_over_mouth: (FLPR, P2 domain, recovery procedures, west commands, overlay rules, boot flows, etc.)?
Most beginners drown in that stuff.
Even intermediate devs waste hours searching through random Nordic docs.

This guide packs everything required to build/flash/debug without guesswork into one file.

In plain terms, use this so you don’t:

  • forget the right west commands

  • break the project structure

  • misconfigure VSCode’s nRF Connect extension

  • brick the board without knowing how to revive it

  • fight device tree paths

  • confuse which core runs what

  • lose time to AI assistants that hallucinate wrong build setup

It’s a productivity booster and an error killer, a must read & review.

Really cool @Toastee0

Bonus :grin: You can simply link to the relevant section. :+1:

GL :slight_smile: PJ :v:

3 Likes

Great initiative. Thank you.

1 Like

Thank you!That is Great!

Hi Toastee0,

Everything was installed in the specified directory, and the environment variables were added. When I run west build, it seems unable to find the board. The board information is located at c:\ncs\platform-seeedboards/zephyr/. Is there any missing configuration?

From the platform seeed boards folder, locate and copy just the nrf54L15 sub directory.

Place this in the seeed subfolder of your ncs/SDK/zephyr/boards.

You can also grab 3.2.0 preview 2/3, they already have the files in that location.

When your done you should have something like:

C:\ncs\v3.1.0\zephyr\boards\arm\xiao_nrf54l15
or
C:\ncs\v3.1.0\zephyr\boards\seeed\xiao_nrf54l15

1 Like

I’ve been trying to get gdb working for hours today, but had no success.
I tried different versions of openocd and a bunch of configuration options like -DCONFIG_DEBUG=y CONFIG_FPROTECT=n CONFIG_DEBUG=y CONFIG_DEBUG_OPTIMIZATIONS=y CONFIG_DEBUG_THREAD_INFO=y CONFIG_THREAD_NAME=y

But I always get this error:

(gdb) monitor reset halt
[nrf54l.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xf9000000 pc: 0x0000fb38 msp: 0x200062d8
(gdb) break main
Breakpoint 1 at 0xda48: file C:/Users/Richt/OneDrive/Dokumente/eglo/application/src/eglo_ble_dimmer.c, line 10.
(gdb) continue
Continuing.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0xda48

Command aborted.

Any ideas?

Hi there,

So are you building it with the West debug switch, so it can load the ELF file the openOCD will connect to?, Check out these threads ,maybe they turn on a light :crossed_fingers:

🤠 nRF54L15 Xiao USB West Flash How to; - #2 by PJ_Glasso
this one has some GDB and OpenOCD.
read the how it works part, may jar something loose :grin: :v:
💥 The Xiao gets a Debugger... Seeedineers make MAGIC! - #11 by PJ_Glasso

HTH
GL :santa_claus: PJ :v:

So we are on the same page, You build it with debug image and flash it, then You connect to it- You HALT it- look at registers- Set Brake_points- Tell it to Go.
Rinse and repeat… :+1:

I think it’s this portion…
arm-none-eabi-gdb firmware.elf
(gdb) target remote :3333
(gdb) load

2 Likes

Hi PJ,
Thanks for sharing those videos.

I just followed your debugging video pretty closely, but unfortunately, I still get the same error.
Unlike in your video, I try to debug on the XIAO nRF54L15 directly, but this should be possible via CMSIS-DAP and SWD just by using the USB-C port, right? I also use the Nordic Connect SDK instead of PlatformIO for now.

Log OpenOCD (GDB Server):

要約

PS C:\Users\Richt\OneDrive\Dokumente\eglo\application> openocd -f ‘C:\Program Files\OpenOCD\share\openocd\scripts\interface\cmsis-dap.cfg’ -f ‘C:/Users/Richt/OneDrive/Dokumente/eglo/external/zephyr/boards/seeed/xiao_nrf54l15\support\openocd.cfg’
Open On-Chip Debugger 0.12.0 (2025-07-10)
Warn : Adapter driver already configured, ignoring
nrf54l-load
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2886:0x0066, serial=831F29BE
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Serial# = 831F29BE
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 : [nrf54l.cpu] Examination succeed
Info : [nrf54l.aux] Examination succeed
Info : [nrf54l.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
Info : [nrf54l.aux] gdb port disabled
Info : accepting ‘gdb’ connection on tcp/3333
Info : New GDB Connection: 1, Target nrf54l.cpu, state: halted
undefined debug reason 8 (UNDEFINED) - target needs reset
Warn : Prefer GDB command “target extended-remote :3333” instead of “target remote :3333”
[nrf54l.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xf9000000 pc: 0x0000fdc4 msp: 0x20006bd0
Info : SWD DPIDR 0x6ba02477
Error: Failed to write memory at 0x0000da60
Error: [nrf54l.cpu] can’t add breakpoint: unknown reason

Log GDB Client:

要約

PS C:\Users\Richt\OneDrive\Dokumente\eglo> C:\ncs\toolchains\66cdf9b75e\opt\zephyr-sdk\arm-zephyr-eabi\bin\arm-zephyr-eabi-gdb.exe .\application\build\zephyr\zephyr.elf
GNU gdb (Zephyr SDK 0.17.0) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type “show copying” and “show warranty” for details.
This GDB was configured as “–host=x86_64-host_w64-mingw32 --target=arm-zephyr-eabi”.
Type “show configuration” for configuration details.
For help, type “help”.
Type “apropos word” to search for commands related to “word”…
Reading symbols from .\application\build\zephyr\zephyr.elf…
(gdb) target remote :3333
Remote debugging using :3333
z_arm_reset () at C:/Users/Richt/OneDrive/Dokumente/eglo/external/zephyr/arch/arm/core/cortex_m\reset.S:95
95 movs.n r0, #0
(gdb) monitor reset halt
[nrf54l.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xf9000000 pc: 0x0000fdc4 msp: 0x20006bd0
(gdb) break main
Breakpoint 1 at 0xda60: file C:/Users/Richt/OneDrive/Dokumente/eglo/application/src/eglo_ble_dimmer.c, line 10.
(gdb) continue
Continuing.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0xda60

Command aborted.

It seems OpenOCD has trouble writing to the flash.
I can write to the XIAO board just fine using west flash though.

I can share some more details about my setup and try some more things tomorrow, but I think I’ll call it a day for now.

Try West attach

Or West debug

To launch the West version of the gdb server then talk to it via putty or something.

Make sure to do this in a NRF terminal inside vscode so that it sets the environment variables for the SDK

Or if you’re hardcore you can follow my development guide and set up the environment variables yourself or with an AI assistant check out the docs folder of my repo

There should also be notes on how to do debugging via GDB in there.

:+1:

Works every time, However I don’t think there’s an OpenOCD config file out yet for the Nrf54L15 like there is for the Nrf52, YMMV :v:

GL :slight_smile: PJ :v:

The most recent version of pyOCD supports it so you can try that if you want.

1 Like

It seems like there is some issue with OpenOCD.

My Build Configuration:

Screenshots


A bunch of logs:

Build output (within nRF Connect Terminal)
west build --build-dir c:/Users/Richt/OneDrive/Dokumente/eglo/application/build c:/Users/Richt/OneDrive/Dokumente/eglo/application --pristine --board xiao_nrf54l15/nrf54l15/cpuapp --no-sysbuild -- -DCONF_FILE="prj.conf" -DCONFIG_DEBUG_OPTIMIZATIONS=y -DCONFIG_DEBUG_THREAD_INFO=y -DCONFIG_DEBUG=y

-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: C:/Users/Richt/OneDrive/Dokumente/eglo/application
-- CMake version: 3.21.0
-- Found Python3: C:/ncs/toolchains/66cdf9b75e/opt/bin/python.exe (found suitable version "3.12.4", minimum required is "3.10") found components: Interpreter
-- Cache files will be written to: C:/Users/Richt/OneDrive/Dokumente/eglo/external/zephyr/.cache
-- Zephyr version: 4.2.99 (C:/Users/Richt/OneDrive/Dokumente/eglo/external/zephyr)
-- Found west (found suitable version "1.4.0", minimum required is "0.14.0")
-- Board: xiao_nrf54l15, qualifiers: nrf54l15/cpuapp
-- Found host-tools: zephyr 0.17.0 (C:/ncs/toolchains/66cdf9b75e/opt/zephyr-sdk)
-- Found toolchain: zephyr 0.17.0 (C:/ncs/toolchains/66cdf9b75e/opt/zephyr-sdk)
-- Found Dtc: C:/ncs/toolchains/66cdf9b75e/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
-- Found BOARD.dts: C:/Users/Richt/OneDrive/Dokumente/eglo/external/zephyr/boards/seeed/xiao_nrf54l15/xiao_nrf54l15_nrf54l15_cpuapp.dts
-- Generated zephyr.dts: C:/Users/Richt/OneDrive/Dokumente/eglo/application/build/zephyr/zephyr.dts
-- Generated pickled edt: C:/Users/Richt/OneDrive/Dokumente/eglo/application/build/zephyr/edt.pickle
-- Generated devicetree_generated.h: C:/Users/Richt/OneDrive/Dokumente/eglo/application/build/zephyr/include/generated/zephyr/devicetree_generated.h
Parsing C:/Users/Richt/OneDrive/Dokumente/eglo/application/Kconfig
Loaded configuration 'C:/Users/Richt/OneDrive/Dokumente/eglo/external/zephyr/boards/seeed/xiao_nrf54l15/xiao_nrf54l15_nrf54l15_cpuapp_defconfig'
Merged configuration 'C:/Users/Richt/OneDrive/Dokumente/eglo/application/prj.conf'
Merged configuration 'C:/Users/Richt/OneDrive/Dokumente/eglo/application/build/zephyr/misc/generated/extra_kconfig_options.conf'
Configuration saved to 'C:/Users/Richt/OneDrive/Dokumente/eglo/application/build/zephyr/.config'
Kconfig header saved to 'C:/Users/Richt/OneDrive/Dokumente/eglo/application/build/zephyr/include/generated/zephyr/autoconf.h'
-- Found GnuLd: c:/ncs/toolchains/66cdf9b75e/opt/zephyr-sdk/arm-zephyr-eabi/arm-zephyr-eabi/bin/ld.bfd.exe (found version "2.38")
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/ncs/toolchains/66cdf9b75e/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe
-- Found gen_kobject_list: C:/Users/Richt/OneDrive/Dokumente/eglo/external/zephyr/scripts/build/gen_kobject_list.py
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/Richt/OneDrive/Dokumente/eglo/application/build
←[92m-- west build: building application
[4/306] Generating include/generated/zephyr/version.h
-- Zephyr version: 4.2.99 (C:/Users/Richt/OneDrive/Dokumente/eglo/external/zephyr), build: ncs-v3.2.0-rc1
[5/306] Generating include/generated/zephyr/syscall_dispatch.c, include/generated/zephyr/syscall_exports_llext.c, syscall_weakdefs_llext.c, include/genera
[9/306] Building C object modules/nrf/subsys/nrf_security/src/CMakeFiles/mbedcrypto_base.dir/C_/Users/Richt/OneDrive/Dokumente/eglo/external/modules/crypt
[9/306] Building C object modules/nrf/subsys/nrf_security/src/CMakeFiles/mbedcrypto_base.dir/C_/Users/Richt/OneDrive/Dokumente/eglo/external/modules/crypt
[18/306] Building C object modules/nrf/subsys/nrf_security/src/CMakeFiles/mbedcrypto_base.dir/C_/Users/Richt/OneDrive/Dokumente/eglo/external/modules/cryp
[24/306] Building C object modules/nrf/subsys/nrf_security/src/CMakeFiles/mbedcrypto_base.dir/C_/Users/Richt/OneDrive/Dokumente/eglo/external/modules/cryp
[113/306] Building C object modules/nrf/subsys/nrf_security/src/CMakeFiles/mbedcrypto.dir/C_/Users/Richt/OneDrive/Dokumente/eglo/external/modules/crypto/m
[123/306] Building C object modules/nrf/subsys/nrf_security/src/CMakeFiles/mbedcrypto.dir/C_/Users/Richt/OneDrive/Dokumente/eglo/external/modules/crypto/m
[124/306] Building C object modules/nrf/subsys/nrf_security/src/CMakeFiles/mbedcrypto.dir/C_/Users/Richt/OneDrive/Dokumente/eglo/external/modules/crypto/m
[184/306] Building C object modules/nrf/subsys/nrf_security/src/core/nrf_oberon/CMakeFiles/psa_cor...sers/Richt/OneDrive/Dokumente/eglo/external/nrf/subsy
[215/306] Building C object modules/nrf/subsys/nrf_security/src/drivers/cracen/CMakeFiles/cracen_psa_driver.dir/silexpk/target/hw/ba414/cmddefs_modmath.c.
[245/306] Building C object modules/hal_nordic/modules/hal_nordic/nrfx/CMakeFiles/modules__hal_nor.../Users/Richt/OneDrive/Dokumente/eglo/external/modules
[306/306] Linking C executable zephyr\zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      177788 B      1428 KB     12.16%
             RAM:       32096 B       188 KB     16.67%
        IDT_LIST:          0 GB        32 KB      0.00%
Generating files from C:/Users/Richt/OneDrive/Dokumente/eglo/application/build/zephyr/zephyr.elf for board: xiao_nrf54l15
Flash output (within nRF Connect Terminal)
west flash --build-dir=C:\Users\Richt\OneDrive\Dokumente\eglo\application\build 

-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner openocd
-- runners.openocd: Flashing file: C:/Users/Richt/OneDrive/Dokumente/eglo/application/build/zephyr/zephyr.hex
Open On-Chip Debugger 0.12.0 (2025-07-10) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 d52e355daa09f17ce64819122cb067b8a2ee0d4b
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
nrf54l-load
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2886:0x0066, serial=831F29BE
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Serial# = 831F29BE
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 : [nrf54l.cpu] Examination succeed
Info : [nrf54l.aux] Examination succeed
Info : [nrf54l.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
Info : [nrf54l.aux] gdb port disabled
    TargetName         Type       Endian TapName            State
--  ------------------ ---------- ------ ------------------ ------------
 0* nrf54l.cpu         cortex_m   little nrf54l.cpu         unknown
 1  nrf54l.aux         mem_ap     little nrf54l.cpu         unknown
[nrf54l.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0xf9000000 pc: 0x0000fdc4 msp: 0x20006bd0
1148 bytes written at address 0x00000000
161692 bytes written at address 0x00000480
14940 bytes written at address 0x00027c20
downloaded 177780 bytes in 3.255883s (53.323 KiB/s)
shutdown command invoked
West debug output (within nRF Connect Terminal)
west debug

-- west debug: rebuilding
ninja: no work to do.
-- west debug: using runner openocd
-- runners.openocd: OpenOCD GDB server running on port 3333; thread info enabled
GNU gdb (Zephyr SDK 0.17.0) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-host_w64-mingw32 --target=arm-zephyr-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://github.com/zephyrproject-rtos/sdk-ng/issues>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from C:/Users/Richt/OneDrive/Dokumente/eglo/application/build/zephyr/zephyr.elf...
Remote debugging using :3333
arch_system_halt (reason=reason@entry=31) at C:/Users/Richt/OneDrive/Dokumente/eglo/external/zephyr/kernel/fatal.c:30
30              for (;;) {
Loading section rom_start, size 0x47c lma 0x0
--Type <RET> for more, q to quit, c to continue without paging--
Loading section text, size 0x26a54 lma 0x480
Load failed
(gdb) monitor reset halt
[nrf54l.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0xf9000000 pc: 0x0000fdc4 msp: 0x20006bd0
(gdb) break main
Breakpoint 1 at 0xda60: file C:/Users/Richt/OneDrive/Dokumente/eglo/application/src/eglo_ble_dimmer.c, line 10.
(gdb) continue
Continuing.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0xda60

Command aborted.
West attach output (within nRF Connect Terminal)
west attach
                               
-- west attach: rebuilding
ninja: no work to do.
-- west attach: using runner openocd
-- runners.openocd: OpenOCD GDB server running on port 3333; thread info enabled
GNU gdb (Zephyr SDK 0.17.0) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-host_w64-mingw32 --target=arm-zephyr-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://github.com/zephyrproject-rtos/sdk-ng/issues>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from C:/Users/Richt/OneDrive/Dokumente/eglo/application/build/zephyr/zephyr.elf...
Remote debugging using :3333
arch_system_halt (reason=reason@entry=31) at C:/Users/Richt/OneDrive/Dokumente/eglo/external/zephyr/kernel/fatal.c:30
30              for (;;) {
(gdb) monitor reset halt
[nrf54l.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0xf9000000 pc: 0x0000fdc4 msp: 0x20006bd0
(gdb) break main
Breakpoint 1 at 0xda60: file C:/Users/Richt/OneDrive/Dokumente/eglo/application/src/eglo_ble_dimmer.c, line 10.
(gdb) continue
Continuing.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0xda60

Command aborted.

I just tried the latest version of PyOCD (even newer than the one included in the latest NCS toolchain) and with that debugging worked just fine. Thank you for the great suggestion. I noticed that you can create a runner configuration for PyOCD in Zephyr, so I guess moving forward, I’ll try to add that to the Zephyr nRF54L15 Board definition, so that I can use PyOCD with west. However, I still don’t understand why OpenOCD seems to work fine for other people. The Zephyr Documentation lists OpenOCD debugging as fully supported.

1 Like

Hi there,

So, What you’re seeing actually makes sense with where the tools are right now:

  • PyOCD tends to pick up new Nordic parts pretty fast, and if you’re running the latest version (newer than what NCS bundles), it’s not surprising that it “just works” with nRF54L15.
  • OpenOCD, on the other hand, is a bit more fragmented. Some people saying “it works” may be:
    • On a different board/probe combo (e.g. DK + J-Link),
    • Using a patched or different OpenOCD build,
    • Or running it from the NCS/Zephyr environment shell that points at the right scripts.

The Zephyr docs that say “OpenOCD debugging fully supported” are talking about Zephyr in general – not that every new chip/board has perfect OpenOCD support out of the box in every toolchain bundle.

A couple of things to double-check:

  1. Make sure you’re starting from the NCS/Zephyr environment shell when you run west debug (so you pick up the toolchain’s OpenOCD, not whatever’s on your system PATH).
  2. Check which OpenOCD executable is actually being used (which openocd / openocd --version) and compare that with the one NCS expects.

That said, if PyOCD is working reliably for you on nRF54L15, adding a pyocd runner config to the board definition is a perfectly reasonable path forward. For new silicon, PyOCD often lands in a good state sooner than OpenOCD does.

PyOCD is quite aggressive about adding new Nordic parts, especially for CMSIS-DAP style probes and generic flash algorithms. So “latest PyOCD works” is not surprising. There are multiple OpenOCD builds in the wild:

  • upstream OpenOCD
  • xPack OpenOCD
  • esp-openocd
  • Nordic’s own internal/packaged versions

From that west attach log it looks like your NCS / Zephyr environment is set up correctly:

  • west attach is using the Zephyr SDK’s GDB and OpenOCD runner,
  • OpenOCD starts fine and you can monitor reset halt,
  • The core halts at arch_system_halt(reason=31), so JTAG/SWD is working.

The key line is:

Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x0000da60

That means OpenOCD can control the core, but it doesn’t know how to access/patch the flash region where main() is located. In other words, the nRF54L15 support in the OpenOCD build you’re using is incomplete or has a bad memory map for that device.

That also explains why:

  • PyOCD works (it has a more up-to-date definition for nRF54L15),
  • Some people report “OpenOCD works” (they may be on a Nordic DK, or using a different / patched OpenOCD).

So you didn’t do anything wrong with the environment – you’ve just hit the edge of what that particular OpenOCD build knows how to do with nRF54L15. Using PyOCD as a runner for this board is a good move, and adding a pyocd runner config to the board definition is exactly the right next step.

HTH
GL :santa_claus: PJ :v:

1 Like