nRF52833 DAP / J-Link DebugPort register 2 : unknown error in J-Link DLL

Hello,

We designed and tested a firmware on the nRF52833-DK board, whith plenty of debug sessions and reprogramming.

Then it has been build for our custom board, based on the nRF52833 chip too, used as a peripheral for a modem host (SPI line).

Using our J-Link (SWD mode), I programmed succesfully 5 boards last week (nrfutil and nrf Programmer), but not tested the boards, I had to leave them few days. Especially one board as been labelled "nrf dev" proof that the programming were successfull.

Today, I tried all the boards the whole morning, impossible to reprogram the boards.

Our EMS also sent us back few samples or faulty boards with a similar behavior (after analysis).

nRFutil error is always :

    PS C:\Users\xxx\Documents\PartageVM\PJ-Thintrack\thintrackBLE\thintrackble> & 'C:\Users\PascalDelrot\bin\nrfutil.exe'
     device program --serial-number 000260111492 --firmware .\build_thintrack\zephyr\zephyr.hex
    [00:00:00] ------   0% [260111492] Failed, [Probe] Device error: Failed to write DebugPort register 2: Unknown Error in J-Link
    Error: One or more program tasks failed:
     * 260111492: [Probe] Device error: Failed to write DebugPort register 2: Unknown Error in J-Link DLL (error code =-1), code: Generic

I looked at these tickets : devzone.nordicsemi.com/.../unable-to-recover-nrf52832-after-debugging-session (mentionned here too devzone.nordicsemi.com/.../nrf9160dk-failed-to-write-debugport-register-2-unknown-error-in-j-link-dll), or (devzone.nordicsemi.com/.../1775) or devzone.nordicsemi.com/.../cannot-program-bmd-340-with-nrf52dk (no solution)

They did not help.

Here what I tried :

- wirings checks several times
- J-Link libraries update to 8.10f (the version expected by nrfutil)
- J-Link firmware version check (up to date)
- VDD disconnection => LOW_VOLTAGE detected, the VDD is correct (1.8V)
- reset pin control (high and low) before and during programming
- batch script requesting "recover" in loop, doing power on/off or reset pin toggling

It seems to me that I'll not be able to reprogram the devices once programmed a first time.

Question :
- any other tips ? or tricks ?
- why on the nRF52-DK I'm able to reprogram the devices dozen of times ? (in VSCode only the overlay files are different)

Thanks !

LOGS
    ./nrfutil device recover --serial-number 000260111492 --log-level trace
=> C:\Users\xxx\.nrfutil\logs

[2025-02-05T09:54:26.838Z] [40364] TRACE - [ProbeLib] [2025-02-05 09:54:26.838049Z] {jlink_usb_000260111492} Retrieved JLink firmware string: J-Link V10 compiled Jan 30 2023 11:28:07
[2025-02-05T09:54:26.838Z] [40364] INFO - [ProbeLib] [2025-02-05 09:54:26.838064Z] {jlink_usb_000260111492} Emulator Usb(JLinkSerialNumber(260111492)) running firmware: J-Link V10 compiled Jan 30 2023 11:28:07
[2025-02-05T09:54:26.838Z] [40364] TRACE - [ProbeLib] [2025-02-05 09:54:26.838071Z] {jlink_usb_000260111492} <- connect
[2025-02-05T09:54:26.838Z] [40364] DEBUG - [ProbeLib] [2025-02-05 09:54:26.838167Z] {jlink_usb_000260111492} Probe worker received message: Request(DeviceInformation)
[2025-02-05T09:54:26.838Z] [40364] DEBUG - [ProbeLib] [2025-02-05 09:54:26.838683Z] {jlink_usb_000260111492} JLINKARM_HW_STATUS: JLINKARM_HW_STATUS { VTarget: 1802, tck: 0, tdi: 0, tdo: 0, tms: 0, tres: 1, trst: 0 }
[2025-02-05T09:54:26.838Z] [40364] TRACE - [ProbeLib] [2025-02-05 09:54:26.838695Z] {jlink_usb_000260111492} CORESIGHT_Configure
[2025-02-05T09:54:26.939Z] [40364] INFO - [ProbeLib] [2025-02-05 09:54:26.939530Z] {jlink_usb_000260111492} -> Powering up sys and debug region
[2025-02-05T09:54:26.939Z] [40364] TRACE - [ProbeLib] [2025-02-05 09:54:26.939567Z] {jlink_usb_000260111492} -> write_dp_unchecked
[2025-02-05T09:54:26.940Z] [40364] WARN - [ProbeLib] [2025-02-05 09:54:26.940349Z] {jlink_usb_000260111492} DAP write error: DebugPort,  register 2 = 0x00000000, err: Unknown Error in J-Link DLL (error code =-1)
[2025-02-05T09:54:26.940Z] [40364] DEBUG - [ProbeLib] [2025-02-05 09:54:26.940391Z] {jlink_usb_000260111492} Aborting debug operation, writing 0x1FF to ABORT register
[2025-02-05T09:54:26.941Z] [40364] TRACE - [ProbeLib] [2025-02-05 09:54:26.941111Z] {jlink_usb_000260111492} <- write_dp_unchecked
[2025-02-05T09:54:26.941Z] [40364] INFO - [ProbeLib] [2025-02-05 09:54:26.941134Z] {jlink_usb_000260111492} <- Powering up sys and debug region


VScode programming

        PS C:\Users\xxx\Documents\PartageVM\PJ-Thintrack\thintrackBLE\thintrackble> nrfjprog --program 'c:\Users\PascalDelrot\Documents\PartageVM\PJ-Thintrack\thintrackBLE\thintrackble\build_thintrack\zephyr\zephyr.hex' --chiperase --verify -f NRF52 --snr 260111492 --log
    [error] [ Client] - Encountered error -102: Command read_device_info executed for 156 milliseconds with result -102
    [error] [ Worker] - An unknown error.
    [error] [ Client] - Encountered error -102: Command read_memory_descriptors executed for 46 milliseconds with result -102
    Failed to read device memories.
    [error] [ Worker] - An unknown error.
    ERROR: JLinkARM DLL reported an error. Try again. If error condition
    ERROR: persists, run the same command again with argument --log, contact Nordic
    ERROR: Semiconductor and provide the generated log.log file to them.
    PS C:\Users\xxx\Documents\PartageVM\PJ-Thintrack\thintrackBLE\thintrackble>


log.log : the first error is

    [2025-Feb-05 12:08:56] [debug] [SeggerBackend] - Select AP 255, DP Bank 0, AP Bank 255
    [2025-Feb-05 12:08:56] [trace] [  JLink] - JLINK_CORESIGHT_WriteAPDPReg(DP reg 0x02, 0x00000000)  
    [2025-Feb-05 12:08:56] [trace] [  JLink] - - 1.034ms returns -1  



Parents
  • Hi,

     

    Here what I tried :

    - wirings checks several times
    - J-Link libraries update to 8.10f (the version expected by nrfutil)
    - J-Link firmware version check (up to date)
    - VDD disconnection => LOW_VOLTAGE detected, the VDD is correct (1.8V)
    - reset pin control (high and low) before and during programming
    - batch script requesting "recover" in loop, doing power on/off or reset pin toggling

    It seems to me that I'll not be able to reprogram the devices once programmed a first time.

    If you have tried all of these things, the recommendation is to check the soldering around the device and possibly reflow the nRF.

    If you measure the power consumption of the board, that can give an indication on what is going on, for instance. Is the current draw dynamic (ie. fluctuates a lot) or is it static?

    Does your design include DCDC inductors? If your firmware enables DCDC without external components being in-place, it will effectively go into a power-on-reset loop.

     

    Kind regards,

    Håkon

Reply
  • Hi,

     

    Here what I tried :

    - wirings checks several times
    - J-Link libraries update to 8.10f (the version expected by nrfutil)
    - J-Link firmware version check (up to date)
    - VDD disconnection => LOW_VOLTAGE detected, the VDD is correct (1.8V)
    - reset pin control (high and low) before and during programming
    - batch script requesting "recover" in loop, doing power on/off or reset pin toggling

    It seems to me that I'll not be able to reprogram the devices once programmed a first time.

    If you have tried all of these things, the recommendation is to check the soldering around the device and possibly reflow the nRF.

    If you measure the power consumption of the board, that can give an indication on what is going on, for instance. Is the current draw dynamic (ie. fluctuates a lot) or is it static?

    Does your design include DCDC inductors? If your firmware enables DCDC without external components being in-place, it will effectively go into a power-on-reset loop.

     

    Kind regards,

    Håkon

Children
  • Hi. Thanks for the answer.
    My bad, I made a mix-up in my wiring documentation. Table pin numbers were correct, but not the cables's color names that I followed this morning. Really sorry for that.

    So the dev boards were reprogrammed.


    The faulty board from the EMS still had the same error message even after programming wiring correction.

    I've been able to reprogram it, by forcing RESET pin to low before the programming, and pull it to high level before the timeout.

    Regarding the DC-DC, there is one, also powering the modem host. Nothing strange. Power consumption of the board (50mA) is quite high regarding the nRF52 itself, but as you mentionned it could something to monitor. We have a ferrite chip on the power supply to disconnect to measure only the nRF consumption if needed.

    Best regards,

Related