nrfjprog verify fails with chiperase

[zilhk]

Hi,

We've been using nrfjprog with no particular issue for a while now. Usually to fully flash a chip (whether it's for a complete re-flash or for a new chip) we run those 2 steps:

nrfjprog -f nrf52 --eraseall
nrfjprog -f nrf52 --program firmware.hex --sectorerase --reset

I was looking for ways to run with just one command and started to use --chiperase.

However on every other run the command fails with a "Write verify failed". It works on the first time but running it again will trigger the error (and the firmware is not run even after a reset). After getting the error, running the command again works fine (and I can see the chip booting our firmware normally).

And this can be repeated, once it has worked, the next flash will fail, and the one after will succeed, etc.

I don't have this issue using --sectorerase but this doesn't erase the pages we use for fstorage.

Here is nrfjprog output when it fails:

nrfjprog -f nrf52 --program firmware.hex --chiperase --verify --reset --log      
Parsing image file.
Verifying programming.
ERROR: [  nRF52] - Data does not match in address range [0x00001000-0x00018fec] (Flash)
ERROR: [  nRF52] - Expected byte value 0x00 but read 0xff at address 0x000122b8.
ERROR: [  nRF52] - Flash verification failed.
ERROR: [  nRF52] - Failed while verifying file firmware.hex.
ERROR: Write verify failed.

I'm using the latest tools, running on Windows 10.

nrfjprog --version
nrfjprog version: 10.15.2 external
JLinkARM.dll version: 7.58b

Is there anything I should do to avoid getting those verify failures? Thanks!

[dejans]

Hi,

Could you provide log.log file from nrfjprog which resides in your application folder?

Best regards,
Dejan

[dejans]

Hi,

What is the actual name of the hex file you want to build - is it _build/full_firmware_factory.hex?
Could you try using "nrfjprog -f nrf52 --eraseall" and "nrfjprog -f nrf52 --program firmware.hex --reset" (without --sectorerase)? Are there any errors in that case?

Best regards,
Dejan

[zilhk]

Thank you!

[dejans]

Hi,

I have asked internally and waiting for the reply.

Best regards,
Dejan

[zilhk]

Thanks!

[dejans]

Hi,

No problem.

Best regards,
Dejan

[dejans]

Hi,

Are you using a watchdog timer in your application?

Best regards,
Dejan

[zilhk]

Hi Dejan,

I believe so, we have a call to "nrf_drv_wdt_init()" with NRF_DRV_WDT_DEAFULT_CONFIG passed as the config.

I'm realizing now that this is a "legacy" feature.

Do you recommend switching to something else?

Thanks.

[dejans]

Hi,

As you can read in the documentation, by default, the watchdog will be active counting down the down-counter while the CPU is sleeping and when it is halted by the debugger. You can also read more about reset behavior.
In your case, the watchdog timer seems to be running while halted. It may be started during the erase operation and finished before the erase operation is performed, thereby causing the error. 

The solution would be either to use two-way workaround which already works well for you, or to disable (turn off) the watchdog timer while debugging.

Best regards,
Dejan

[zilhk]

Thank you for the information.
Setting the watchdog timer behaviour to "NRF_WDT_BEHAVIOUR_PAUSE_SLEEP_HALT" fixes the issue! 

The WDT is started right at the beginning of our "main()" function.