nrfjprog --program: code starts executing though no --reset option has been given on command line. Causes unwanted activation of readback protection.

[Frank Viganske]

I'm using nrfjprog version: 10.13.0 / JLinkARM.dll version: 7.50a to flash a firmware onto a custom PCB with nRF52840. Programming hardware is a nRF52840 DK. Our firmware activates readback protection on the first boot.

Here is the programming script that i use:

nrfjprog -f NRF52 --recover
nrfjprog -f NRF52 --program final_image_1_1_8_no_sp.hex --chiperase
nrfjprog -f NRF52 --verify final_image_1_1_8_no_sp.hex --fast
nrfjprog -f NRF52 --reset

I noticed that sometimes the 3rd and 4th line of the script fail due to activated readback protection. So i assume that the firmware already starts after the --program step. The firmware will then activate the readback protection after a while, and if the timing is bad, then the --verify and --reset will fail.

This is what the output looks like, when the error occurs:

C:\Temp\1.1.8_internal>nrfjprog -f NRF52 --recover
Recovering device. This operation might take 30s.
Erasing user code and UICR flash areas.

C:\Temp\1.1.8_internal>nrfjprog -f NRF52 --program final_image_1_1_8_no_sp.hex --chiperase
Parsing image file.
Applying system reset.
Verified OK.

C:\Temp\1.1.8_internal>nrfjprog -f NRF52 --verify final_image_1_1_8_no_sp.hex --fast
ERROR: The operation attempted is unavailable due to readback protection in
ERROR: your device. Please use --recover to unlock the device.

C:\Temp\1.1.8_internal>nrfjprog -f NRF52 --reset
ERROR: The operation attempted is unavailable due to readback protection in
ERROR: your device. Please use --recover to unlock the device.

Command output after a succesful operation is this:

C:\Temp\1.1.8_internal>nrfjprog -f NRF52 --recover
Recovering device. This operation might take 30s.
Erasing user code and UICR flash areas.

C:\Temp\1.1.8_internal>nrfjprog -f NRF52 --program final_image_1_1_8_no_sp.hex --chiperase
Parsing image file.
Applying system reset.
Verified OK.

C:\Temp\1.1.8_internal>nrfjprog -f NRF52 --verify final_image_1_1_8_no_sp.hex --fast
Verifying programming.
Verified OK.

C:\Temp\1.1.8_internal>nrfjprog -f NRF52 --reset
Applying system reset.
Run.

Though no --reset or --verify option is given with the --program command, it appears to do a system reset and a verify.

A log file from a failed skript execution is attached.

Best regards,

Frank

8203.log.log

[run_ar]

Hi,

Could you try to combine the --program and --verify command like this: nrfjprog --program final_image_1_1_8_no_sp.hex --verify --fast?

Do you have a good connection to the board and a stable power supply?

[Frank Viganske]

Hi,

it works better when i combine the options --program and --verify, as you suggested, But still in 1% of the cases i get the readback protection error. With the original script it was 11%. I let both the orignal script and the modified script run in a loop for 100 iterations and counted the errors.

I also noticed that when the error occurs the RESETREAS register indicates a watchdog reset. After a successful run RESETREAS shows a Software reset.

That surprised me a bit. When i pause the script after the --program operation, there will be no watchdog reset, so it seems the --recover and / or --program operation halts the watchdog. But the --verify seems to start it again, which appears to be the reason why the code starts executing.

The connection to the board is OK, I never had problems with the connection before, until i introduced the verification step in the script. To me it looks that the verify is the main suspect here. The failure rate going down from 11% to 1% after combining program and verify also points into that direction.

We did power supply measurements during hardware validation, and they were stable. But i never did some measurements during programming with the Nordic DK, i can try to do that during the next few days. What voltages are you interested in, just VDD and VDDH or also some of the DEC pins?

[run_ar]

Did you configure the Watchdog to halt while the debugger is connected: Temporarily pausing the watchdog? That might cause the wdt to continue counting after you disconnect the debugger. Notice that not all resets will actually reset the wdt -> Reset behavior. I though the recover command should take care of everything. But I wonder if it could be that the WDT is running even after that. depending on what reset is performed. Could you try adding a pin reset command to the script between the --recover command and the program command. notice, you might need to issue an --pinresetenable command to begin with.

[Frank Viganske]

Hi,

The watchdog is configured by a third party software component that we use, of which i do not have the source. But i inserted a debug print of the WDT->CONFIG register after the initialization of that component. The value read was 1, which is also the default value after a reset.

So that means the watchdog should be paused while the CPU is halted by the debugger.

I added a --pinresetenable and a --pinreset as you suggested. That gave me 0 errors on 100 iterations, so that seems to fix the problem. But i think for safety i will also check for the exit code 16 (for the readback protection error) and repeat the programming if that happens.

Now that i think about it, the --verify --fast may be the option that caused all the trouble. If i understood that correctly, it will execute some code on the target to calculate a hash, so the CPU will no longer be halted by the debugger. That would also cause the watchdog to continue running.

If that is correct, doing a slow verify might also be a possible solution.

[Frank Viganske]

Just wanted to add that i also verified this after upgrading to the 10.13.0 again. That version had a much higher failure rate, but works fine now with the pinreset.