nrfjprog failures

[allard.p]

I'm working on custom test software for use in production programming/testing of my product containing a nRF9160. I'm using the nrfjprog executable, but with problems, every second call to nrfjprog --program is failing:

D:\[path here]\nrfjprog\nrfjprog 
--ini D:\[path here]\nrfjprog\nrfjprog.ini 
-f NRF91 
-c 4000 
-s [serial here] 
--program D:\[path here]\temp_files\74e8207a-5983-41e5-b1e6-45eaa2d0f0fb.hex 
--sectorerase 
--verify 
--log 
[error] [ Client] - Encountered error -102: Command program_file executed for 188 milliseconds with result -102 
[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: 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.

The log file is attached.

nrfjprog v10.22.1

JLINK v7.80c

nrf connect system report:

# nRFConnect System Report - 2023-07-17T12-26-40.066Z

- System:     Acer Aspire TC-885
- BIOS:       American Megatrends Inc ACRSYS - 1072009
- CPU:        1 x Intel Core™ i7-8700 3.2 GHz 12 cores (6 physical)
- Memory:     5.3 GB free of 15.9 GB total
- Filesystem: C: (NTFS) 930.9 GB 47.6% used

- OS:         Microsoft Windows 10 Home (10.0.19045) Windows x64

- Versions
    - kernel: 10.0.19045
    - git: 2.30.0.windows.1
    - node: 16.17.1
    - python: 3.11.0
    - python3: 3.10.11
    - nrf-device-lib-js: 0.6.12
    - nrf-device-lib: 0.15.3
    - nrfjprog DLL: 10.19.1
    - JLink: JLink_V7.80c

- Connected devices:
    - CAFEBABE : COM24
    - 000600105884 Unknown: undefined
    - {34C052A1-08B6-5809-881E-95820D434537} : COM21
    - FTXP9XD7 : COM10
    - {921BE77D-DA9D-11ED-A25F-94C69193D3EE} : COM7, COM8

6712.log.log

[allard.p]

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.

[Michal]

Hello again,

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

Best regards,

Michal

[allard.p]

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.

[Michal]

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

[allard.p]

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.

[Rory]

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"

-- 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
[ #################### ] 0.354s | Erase file - Done erasing
[ #################### ] 1.438s | Program file - Done programming
[ #################### ] 1.643s | Verify file - Done verifying
[ #################### ] 0.370s | Erase file - Done erasing
[ #################### ] 4.304s | Program file - Done programming
[ #################### ] 4.996s | Verify file - Done verifying
Applying pin reset.
-- runners.nrfjprog: Board with serial number 69660205 flashed successfully.

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

[Rory]

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!

[paul.lander]

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.

[Michal]

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

[allard.p]

Any news? Came across this error again today.

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

[Michal]

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