Trouble programming custom nRF54L15 board — possible soldering or programmer issue?

Hey everyone,

I’ve been banging my head against an issue with my custom nRF54L15 board, and I’m under a bit of pressure to get five samples working. Unfortunately, the PCB production was delayed, and now I’m stuck trying to figure out whether my problem is due to hardware (soldering) or programming/debug setup.

Background

There was also a shortage of nRF54L15 chips, so I had to buy and hand-solder them myself — which hasn’t been fun.

I’ve worked with nRF52 for quite a while, using a J-Link v9 programmer (likely a Chinese clone), and it works perfectly fine there.

Programming setup

On my nRF54L15 board, I’m connecting:

  • SWDIO

  • SWDCLK

  • RESET

When these are connected, the J-Link reports no errors — it programs successfully.
However, the firmware doesn’t seem to run (e.g., setting a GPIO high doesn’t change the output).

Debugging attempts

When I try to enter debug mode, that’s where things fall apart:

  • The J-Link v9 doesn’t seem to handle it — breakpoints don’t work, and I can’t see any activity.

  • To rule out my code, I switched to the official nRF54L15 DK (PCA10156 Rev 0.9.1), where debugging works fine.
    Of course, I get expected runtime errors because the sensors (I²C) aren’t connected.

Trying external programming via DK

Then I tried programming my custom board via the P19 external debug connector on the DK:

  • Set the SELECT pin to GND (to enable external mode)

  • But I get this error:

Error: One or more batch tasks failed: * 1057743646: Device error: Setting the debug port SELECT register failed while powering up sys and debug regions (Unknown Error in J-Link DLL (error code = -1)). This might indicate that the debug port is unavailable.

From what I can tell, this means the debug port isn’t responding — which could mean:

  • The chip isn’t properly soldered

  • Or there’s an issue with the power/debug connections

I’ve triple-checked the wiring, even re-soldered the chip, but still no luck.

When I test with JLinkExe, using the same wiring on the J-Link v9, here’s what I get:

SEGGER J-Link Commander V8.10i (Compiled Nov 27 2024 12:20:22)
DLL version V8.10i, compiled Nov 27 2024 12:19:40

Connecting to J-Link via USB...O.K.
Firmware: J-Link V9 compiled May  7 2021 16:26:12
Hardware version: V9.60
J-Link uptime (since boot): N/A (Not supported by this model)
S/N: 69651415
License(s): RDI, GDB, FlashDL, FlashBP, JFlash
VTref=3.311V


Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: NRF54L15_M33
Type '?' for selection dialog
Device>NRF54L15_M33
Please specify target interface:
  J) JTAG (Default)
  S) SWD
  T) cJTAG
TIF>S
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "NRF54L15_M33" selected.


Connecting to target via SWD
ConfigTargetSettings() start
ConfigTargetSettings() end - Took 279us
InitTarget() start
PROT status: 0x00000000
InitTarget() end - Took 1.92ms
Found SW-DP with ID 0x6BA02477
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set, ADDR: 0x00000000)
AP[1]: APB-AP (IDR: Not set, ADDR: 0x00000000)
AP[2]: MEM-AP (IDR: Not set, ADDR: 0x00000000)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FE000
CPUID register: 0x411FD210. Implementer code: 0x41 (ARM)
Feature set: Mainline
Cache: No cache
Found Cortex-M33 r1p0, Little endian.
Cortex-M (ARMv8-M and later): The connected J-Link (S/N 69651415) uses an old firmware module that does not handle I/D-cache correctly. Proper debugging functionality cannot be guaranteed if cache is enabled
FPUnit: 8 code (BP) slots and 0 literal slots
Security extension: implemented
Secure debug: enabled
CoreSight components:
ROMTbl[0] @ E00FE000
[0][0]: E00FF000 CID B105100D PID 000BB4C9 ROM Table
ROMTbl[1] @ E00FF000
[1][0]: E000E000 CID B105900D PID 000BBD21 DEVARCH 47702A04 DEVTYPE 00 Cortex-M33
[1][1]: E0001000 CID B105900D PID 000BBD21 DEVARCH 47701A02 DEVTYPE 00 DWT
[1][2]: E0002000 CID B105900D PID 000BBD21 DEVARCH 47701A03 DEVTYPE 00 FPB
[1][3]: E0000000 CID B105900D PID 000BBD21 DEVARCH 47701A01 DEVTYPE 43 ITM
[1][5]: E0041000 CID B105900D PID 002BBD21 DEVARCH 47724A13 DEVTYPE 13 ETM
[0][1]: E0040000 CID B105900D PID 000BBD21 DEVARCH 00000000 DEVTYPE 11 TPIU
Memory zones:
  Zone: "Default" Description: Default access mode
Cortex-M33 identified.

Using the nRF54L15 Dev Kit:

SEGGER J-Link Commander V8.10i (Compiled Nov 27 2024 12:20:22)
DLL version V8.10i, compiled Nov 27 2024 12:19:40

Connecting to J-Link via USB...O.K.
Firmware: J-Link OB-nRF5340-NordicSemi compiled Oct  9 2024 11:01:34
Hardware version: V1.00
J-Link uptime (since boot): 0d 00h 01m 31s
S/N: 1057743646
License(s): RDI, FlashBP, FlashDL, JFlash, GDB
USB speed mode: Full speed (12 MBit/s)
VTref=3.300V


Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: CORTEX-M33
Type '?' for selection dialog
Device>NRF54L15_M33
Please specify target interface:
  J) JTAG (Default)
  S) SWD
  T) cJTAG
TIF>S
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "NRF54L15_M33" selected.


Connecting to target via SWD
ConfigTargetSettings() start
ConfigTargetSettings() end - Took 11us
InitTarget() start
InitTarget() end - Took 102ms
Failed to attach to CPU. Trying connect under reset.
ConfigTargetSettings() start
ConfigTargetSettings() end - Took 6us
InitTarget() start
InitTarget() end - Took 3.78ms
Error occurred: Could not connect to the target device.
For troubleshooting steps visit: https://wiki.segger.com/J-Link_Troubleshooting

What could be the issue? It has been three days already and I don't see how to proceed from here ... 

Has anyone successfully used the P19 interface on the DK to program an external nRF54L15?

Best regards,

Fernando Fontes

Parents
  • Hi again everyone,

    I did some investigation with the oscilloscope and noticed a lot of distortion on the SWD lines. Then I found a post describing exactly the same issue I was having. Apparently, the dev kit that I have is not able to work with the 30 cm programming cable that I'm using.

    I’ve already ordered two more dev kits from Digi-Key, but since I’m not sure which version I’ll receive, I also modified my 0.9.1 version. I removed the level shifter and forced 3.3 V as the main voltage (since my custom board runs at 3.3 V).

    That worked — I was able to program my board using the dev kit. However, to my surprise, I still couldn’t debug my application. At least I managed to rule out the possibility that the issue was caused by the Chinese J-Link.

    After comparing the dev kit schematic with mine, I noticed the only difference was the missing external flash chip. I started wondering whether I had somehow included it in my device tree files. While searching, I came across several threads about MCUBoot, and eventually found this one. To my surprise, the real issue was the missing configuration options:

    CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n

    It never crossed my mind that I needed to explicitly specify the absence of the 32 kHz crystal. That would have saved me many hours of debugging!

    Anyway, it’s working now. I’m leaving this here in case anyone else runs into the same issue.

    Best regards,
    Fernando Fontes

Reply
  • Hi again everyone,

    I did some investigation with the oscilloscope and noticed a lot of distortion on the SWD lines. Then I found a post describing exactly the same issue I was having. Apparently, the dev kit that I have is not able to work with the 30 cm programming cable that I'm using.

    I’ve already ordered two more dev kits from Digi-Key, but since I’m not sure which version I’ll receive, I also modified my 0.9.1 version. I removed the level shifter and forced 3.3 V as the main voltage (since my custom board runs at 3.3 V).

    That worked — I was able to program my board using the dev kit. However, to my surprise, I still couldn’t debug my application. At least I managed to rule out the possibility that the issue was caused by the Chinese J-Link.

    After comparing the dev kit schematic with mine, I noticed the only difference was the missing external flash chip. I started wondering whether I had somehow included it in my device tree files. While searching, I came across several threads about MCUBoot, and eventually found this one. To my surprise, the real issue was the missing configuration options:

    CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n

    It never crossed my mind that I needed to explicitly specify the absence of the 32 kHz crystal. That would have saved me many hours of debugging!

    Anyway, it’s working now. I’m leaving this here in case anyone else runs into the same issue.

    Best regards,
    Fernando Fontes

Children
Related