Cannot reprogram nrf9151dk after flashing Dect nr+ shell

Hi,

I have been evaluating the use of nrf9151 using two development kit boards.

On my first board, I set it up initially using quick start under the nRF connect app, this worked fine and I was able to test the LTE modem firmware.

However, intending to use these kits for DECT NR+ development I then proceeded to reflash them through the VScode example.

I first flashed a "blinky" code sample, which worked as expected.

I then flashed the NR+ Shell code sample, although there was an error in the serial terminal upon boot the flash itself appeared to work.

I then attempted to flash the board with the blinky image again, to go back to a working situation. However, this failed.

Now, when I attempt to flash the board from VScode, it fails every time with the following error:

Error: One or more batch tasks failed:
 * 1051272788: Timed out waiting for response from worker. (Generic)

FATAL ERROR: command exited with status 1: nrfutil --json device x-execute-batch --batch-path 'C:\ncs\v3.1.0\nrf\samples\zephyr\basic\blinky\build\generated_nrfutil_batch.json' --serial-number 1051272788

Similarly, if I attempt to use the quickstart program again, it fails to erase the device. The log reports the following error:

2025-09-02T13:26:23.235Z INFO Initialising the bundled nrfutil device
2025-09-02T13:26:23.241Z DEBUG Started watching devices
2025-09-02T13:26:24.010Z INFO Using the bundled core version for nrfutil device: 8.1.1
2025-09-02T13:26:24.048Z INFO Using nrfutil-device version: 2.10.2
2025-09-02T13:26:24.048Z INFO Using nrf-device-lib version: 0.17.71
2025-09-02T13:26:24.049Z INFO Using nrf-probe version: 0.38.0
2025-09-02T13:26:24.049Z INFO Using JLink version: JLink_V8.60
2025-09-02T13:26:24.049Z INFO Your version of SEGGER J-Link (8.60) is newer than the one this app was tested with (8.18). The tested version is not required, and your J-Link version will most likely work fine. If you get issues related to J-Link with your devices, use the tested version.
2025-09-02T13:26:26.236Z DEBUG Selected device: nRF9151 DK
2025-09-02T13:26:26.274Z DEBUG Changed step: Info
2025-09-02T13:26:27.405Z DEBUG Changed step: Rename
2025-09-02T13:26:28.713Z DEBUG Changed step: Program
2025-09-02T13:27:37.966Z ERROR [ProbeLib] [2025-09-02 13:27:37.953656Z] Failed to initialize worker: Timed out waiting for response from worker.
2025-09-02T13:27:42.168Z ERROR [ProbeLib] [2025-09-02 13:27:42.169029Z] Trace channel disconnected unexpectedly.
2025-09-02T13:27:42.173Z ERROR [ProbeLib] [2025-09-02 13:27:42.173569Z] Worker exited with error code 1.

I have access to a second development kit, which has only been reprogrammed from the quickstart app, and I notice some differences between their behaviour.

First, in VSCode under connected devices, the functional development kit shows the NRF9151, two virtual COM ports and an RTT connection. Whereas, the non-functional kit shows only the RTT connection.

Similarly the nrf connect serial terminal app will only recognise the functional development kit.

The nrfconnect programmer is unable to read anything from the non-functional development kit, after a short while it fails with the error:

Failed "reading readback protection status for application core". Error: code: 1, description: Generic, message: Batch task protection-get failed, Emulator error: Failed to open connection
14:35:01.631	Error: Failed with exit code 1. One or more batch tasks failed: * 1051272788: Emulator error: Failed to open connection (Generic) Message: Batch task protection-get failed, Emulator error: Failed to open connection.

Whereas, I can read as expected from the functional kit.

I upgraded J-Link to version 8.60 as it appeared to be a solution to a problem with similar symptoms that I read on this forum. However, this had no effect either way on my problem.

I have not attempted to flash the functional kit in any way, except by using quick start, which has worked normally every time.

Any assistance would be appreciated, thank you.

Parents Reply
  • Good afternoon,

    Your pointer to nrfjprog was the solution to my problem! I ran the command and now my board is working again as expected.

    To answer your other questions: the current measurement jumper was in place - and I did not attempt to connect on other PCs as step 1 solved my issue.

    Is there a way to prevent inadvertently "locking" the board going forwards?

    Thank you for your assistance!

Children
No Data
Related