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

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

Frank Viganske — Mon, 20 Sep 2021 08:29:06 GMT

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.

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

Frank Viganske — Mon, 20 Sep 2021 07:17:57 GMT

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.

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

run_ar — Fri, 17 Sep 2021 14:04:31 GMT

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.

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

Frank Viganske — Mon, 13 Sep 2021 11:34:37 GMT

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?

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

run_ar — Fri, 10 Sep 2021 13:32:07 GMT

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?

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

Frank Viganske — Mon, 06 Sep 2021 13:31:01 GMT

Update: i inserted a "pause" command after the --program and the --verify command and added some debug prints to the firmware when it starts. That showed me that the firmware does not start until the --verify operation begins.

Also i tried downgrading to an older nrfjprog version (10.5.0) to see if that changes anything. The error occurs also with the older version, only a bit less often.

Frank