nrfjprog failures

RE: nrfjprog failures

Michal — Tue, 04 Mar 2025 23:46:10 GMT

Hello,

Thank you for the information, could you make a new ticket about that?

Best regards,

Michal

RE: nrfjprog failures

DmytroSes — Fri, 28 Feb 2025 15:29:55 GMT

I have experienced the similar issue, when developing an application for nRF54l15. I was not able to flash a firmware over an existing one without full chip erase. This issue was reproducible specifically when I compiled my code with MCUboot and a custom board. I resolved the problem by disabling FPROTECT for MCUboot in sysbuild/mcuboot.conf:

CONFIG_FPROTECT=n

RE: nrfjprog failures

joel-sc — Wed, 13 Nov 2024 14:33:09 GMT

I'll do it as soon I rework on this issue.

RE: nrfjprog failures

Michal — Mon, 11 Nov 2024 12:43:36 GMT

Could you make a new ticket with the information about your setup for a proper follow-up?

Best regards,

Michal

RE: nrfjprog failures

Michal — Mon, 11 Nov 2024 12:07:05 GMT

I am trying to find out internally about it.

RE: nrfjprog failures

joel-sc — Fri, 01 Nov 2024 07:58:55 GMT

Yes 10.18.1 works.

Would it be possible to know what is the issue ?

RE: nrfjprog failures

Michal — Tue, 29 Oct 2024 17:16:49 GMT

No update I'm afraid.

Are you able to use the 10.18.1 version instead?

RE: nrfjprog failures

joel-sc — Tue, 22 Oct 2024 12:37:04 GMT

HI Michal

Is there any new from this issue?

I've got the same kind of issue with the last nrf command line tools release (nrf-command-line-tools_10.24.2_amd64.deb) on Linux. This package is bundled with JLink_Linux_V794e_x86_64.

best

RE: nrfjprog failures

Michal — Tue, 03 Oct 2023 22:53:02 GMT

I don't have any news yet unfortunately, except for that our developers are looking into it.

Please use any workarounds that you have found for now.

Best regards,

Michal

RE: nrfjprog failures

allard.p — Thu, 28 Sep 2023 11:22:21 GMT

Any news? Came across this error again today.

Tried 10.18.1 today, as Rory suggested, and this version seems to work (limited testing).

RE: nrfjprog failures

Michal — Wed, 06 Sep 2023 17:34:43 GMT

Thank you for the updates and successes in debugging this issue.

Just wanted to let you all know that I am inquiring our developers about any possible actions.

Best regards,

Michal

RE: nrfjprog failures

paul.lander — Sun, 27 Aug 2023 19:08:34 GMT

We've also experienced this problem and found a temporary solution by matching particular versions of nrfjprog DLL and JLink software. The problem seems to be more acute with the Apple M1 architecture, but bear in mind nRF Connect Extensions pack may update your command line tools and older versions of JLinkExe have more quirks.

I wrote up our findings in this support case.

RE: nrfjprog failures

Rory — Sat, 26 Aug 2023 11:54:05 GMT

I just downgraded my version of nRF Command Line Tools to 10.18.1 (x64), and flashing without fully erasing (i.e. --sectorerase) is working now.

Try downgrading to nRF Command Line Tools 10.18.1 and confirm that the problem persists. Downgrading completely fixed the issue for me with both the nRF9160 and the nRF5340. Hope this helps!

RE: nrfjprog failures

Rory — Wed, 23 Aug 2023 11:45:07 GMT

I am seeing this same problem with flashing the nRF5340 in VS Code without a full erase, but instead using --sectorerase.

I am using:

J-Link V7.92a (latest)

nRF Command Line Tools 10.23.0 (latest)

nrfjprog 10.23.0 (latest)

When flashing from the latest version of VS Code with a full chip erase, it works perfectly:

Flashing build to 69660205
C:\Windows\system32\cmd.exe /d /s /c "west flash -d c:\ble\patriot\build --skip-rebuild --dev-id 69660205 --erase"

Then if I attempt to flash it again immediately after without selecting a full chip erase, it fails to flash:

Flashing build to 69660205
C:\Windows\system32\cmd.exe /d /s /c "west flash -d c:\ble\patriot\build --skip-rebuild --dev-id 69660205"

-- west flash: using runner nrfjprog
-- runners.nrfjprog: Flashing file: c:\ble\patriot\build\zephyr\merged_domains.hex
-- runners.nrfjprog: c:\ble\patriot\build\zephyr\merged_domains.hex targets both nRF53 coprocessors; splitting it into: c:\ble\patriot\build\zephyr\GENERATED_CP_NETWORK_merged_domains.hex and c:\ble\patriot\build\zephyr\GENERATED_CP_APPLICATION_merged_domains.hex
[ #################### ] 12.986s | Erase file - Done erasing
[error] [ Client] - Encountered error -102: Command program_file executed for 72 milliseconds with result -102
[error] [ nRF53] - Failed while detecting device memory block protection status!
[error] [ nRF53] - Failed while reading device information.
[error] [ Worker] - JLinkARM.dll Halt returned error 1.
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.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.
FATAL ERROR: command exited with status 33: nrfjprog --program 'c:\ble\patriot\build\zephyr\GENERATED_CP_NETWORK_merged_domains.hex' --sectorerase --verify -f NRF53 --coprocessor CP_NETWORK --snr 69660205

If I try to flash it again with full chip erase, it still fails. The only thing that seems to allow it to be flashed again is doing an nrfjprog --recover or using the Programmer app from nRF Connect Desktop to fully erase the chip.

Flashing build to 69660205
C:\Windows\system32\cmd.exe /d /s /c "west flash -d c:\ble\patriot\build --skip-rebuild --dev-id 69660205 --erase"

-- west flash: using runner nrfjprog
-- runners.nrfjprog: mass erase requested
-- runners.nrfjprog: Flashing file: c:\ble\patriot\build\zephyr\merged_domains.hex
-- runners.nrfjprog: c:\ble\patriot\build\zephyr\merged_domains.hex targets both nRF53 coprocessors; splitting it into: c:\ble\patriot\build\zephyr\GENERATED_CP_NETWORK_merged_domains.hex and c:\ble\patriot\build\zephyr\GENERATED_CP_APPLICATION_merged_domains.hex
[error] [ Client] - Encountered error -90: Command read_memory_descriptors executed for 15 milliseconds with result -90
[error] [ Worker] - Can't read memory descriptors, ap-protection is enabled.
[error] [ Client] - Encountered error -90: Command erase_file executed for 62 milliseconds with result -90
[error] [ nRF53] - Failed while erasing device. -90: Access protection is enabled, can't read block protection state.
[error] [ Worker] - Access protection is enabled, can't read block protection state.
ERROR: The operation attempted is unavailable due to readback protection in
ERROR: your device. Please use --recover to unlock the device.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.
ERROR: runners.nrfjprog: Flashing failed because the target must be recovered.
To fix, run "west flash --recover" instead.
Note: your target is an nRF53; all flash memory for both the network and application cores will be erased prior to reflashing.
FATAL ERROR: command exited with status 24: nrfjprog --program 'c:\ble\patriot\build\zephyr\GENERATED_CP_NETWORK_merged_domains.hex' --chiperase --verify -f NRF53 --coprocessor CP_NETWORK --snr 69660205

RE: nrfjprog failures

allard.p — Tue, 22 Aug 2023 07:10:39 GMT

Not sure what you mean with 'DK', but if it is the debug probe, this is connected directly to the PC, no hubs.

I've two situations with programming troubles:

- The testboard situation, where the DUT is tested and programmed, here is also a USB<->UART connected. In this case NRFJPROG is called from my test software. In this case every second try succeeds.

- Programming in development from VSCode. In this case programming always fails, only full erase works, not '--sectorerase'.

I also tested without USB<->UART connected, no change. When i change the debug probe from a JLink plus to a Jlink base the error message in VSCode changes slightly.

This is with the plus version:

-- west flash: using runner nrfjprog
-- runners.nrfjprog: Flashing file: D:\[PATH]\merged.hex
[ #################### ]  13.455s | Erase file - Done erasing                                                          
[error] [  nRF91] - The write access failed, but no cause could be determined.                                         
[error] [  nRF91] - It may be due to an unaligned access, accessing a nonexistent memory, or a communication issue.
[error] [  nRF91] - Failed while performing 'Write' operation on target address 0x00000000. 
-102: An unknown error.
[error] [  nRF91] - Failed while reading device information.
[error] [ Worker] - An unknown error.
[error] [ Client] - Encountered error -102: Command program_file executed for 203 milliseconds with result -102
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.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.
FATAL ERROR: command exited with status 33: nrfjprog --program 'D:\[path]\merged.hex' --sectorerase --verify -f NRF91 --snr [serial]

And with the base version:

-- west flash: using runner nrfjprog
-- runners.nrfjprog: Flashing file: D:\[path]\merged.hex
[error] [ Client] - Encountered error -102: Command erase_file executed for 217 milliseconds with result -102          
[error] [  nRF91] - Failed while performing 'Erase' operation on target address 0x00000000. 
-102: JLinkARM.dll WriteU32 returned error -1.
[error] [  nRF91] - Failed while erasing device. -102: JLinkARM.dll WriteU32 returned error -1.
[error] [ Worker] - JLinkARM.dll WriteU32 returned error -1.
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.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.
FATAL ERROR: command exited with status 33: nrfjprog --program 'D:\[PATH]\merged.hex' --sectorerase --verify -f NRF91 --snr [serial]

With the plus version I am able to execute a sector erase in J-Flash without problems.

RE: nrfjprog failures

Michal — Mon, 21 Aug 2023 14:35:46 GMT

Thank you for checking.

How are you connecting the DK by the way? Are you connecting the USB directly to your PC, or via a hub?

There is no COM port connected to the DK when trying to flash for the first time, right?

Best regards,

Michal

RE: nrfjprog failures

allard.p — Mon, 21 Aug 2023 13:48:30 GMT

Firmware is up to date:

SEGGER J-Link Configuration V7.88j
Logging started @ 2023-08-21 15:47
Updating firmware of probe/ programmer 1 of 1 via USB (SN: 6001xxxx)...Not updated, probe/ programmer firmware is already up to date.

RE: nrfjprog failures

Michal — Mon, 21 Aug 2023 13:15:21 GMT

Did you try upgrating the OB JLink firmware using Segger tools?

Best regards,

Michal

RE: nrfjprog failures

allard.p — Mon, 21 Aug 2023 11:54:27 GMT

I removed my version of NRFJPROG and installed v10.23.0. This version comes with jlink driver 7.88j, same problems. I assume NRF connect for VScode takes the NRFJPROG version installed under "C:\Program Files\Nordic Semiconductor\nrf-command-line-tools" ?

RE: nrfjprog failures

Michal — Mon, 21 Aug 2023 11:02:28 GMT

Hello again,

Could you try upgrading your JLink driver? It may have gotten fixed around 7.82.

Best regards,

Michal

RE: nrfjprog failures

Michal — Mon, 21 Aug 2023 08:14:21 GMT

Hello,

I am going to consult with the experts and get back to you.

Best regards,

Michal

RE: nrfjprog failures

allard.p — Thu, 17 Aug 2023 09:13:14 GMT

I checked my application, I do not set APPROTECT anywhere. The --recover works, but triggers a full flash erase (?), i do not want this, because it erases all my settings etc.

I also have the problem with programming from VSCode. Program + erase always works. Program with --sectorerase does not work, the same 'unknown error (-102)'. The error occurs after 'erasing sector 2':

[ ############# ] 0.259s | Erasing non-volatile memory - block 2 of 2

The erase of block1 succeeded, so i do not think the problem is with APPROTECT. I'm also able to connect with J-LINK commander, so the debug port is working.

I did not have these errors in the past, but I do not known what caused the errors to happen.

RE: nrfjprog failures

Rory — Tue, 18 Jul 2023 09:43:40 GMT

nRF91 and nRF53 devices can have their CTRL-AP port that the JLink uses become locked for readback protection (and programming) using the APPROTECT feature. When this happens, you need to recover the device with the command below before you can program it again.

nrfjprog --family NRF91 --recover