NRF52811_xxAA_REV2 verify failed with firmware compiled against nRF5 SDK v17.1.0

[Mateoosh]

Hi,

We have a project based on NRF52811_xxAA_REV1 running on multiple devices without any problem.

Nordic announced recently newer version of SoC (REV2, aka B0) and since nrf5 SDK is present in "compatible downloads" I was (almost) sure, current firmware (bluetooth peripheral, S112 v 7.2.0) will work with REV2 as well.

Programming is OK, however verify fails with a message:

[ #################### ] 1.558s | Program file - Done programming
[error] [ Client] - Encountered error -160: Command verify_file executed for 109 milliseconds with result -160
[error] [ nRF52] - Failed while performing 'Verify' operation on target address 0x00000000.
-160: Data does not match in address range [0x00000000 - 0x00000AFF] (Flash)
Expected byte value 0x04 but read 0x00 at address 0x00000001.
[error] [ nRF52] - Failed while verifying device. -160: Data does not match in address range [0x00000000 - 0x00000AFF] (Flash)
Expected byte value 0x04 but read 0x00 at address 0x00000001.
[error] [ Worker] - Data does not match in address range [0x00000000 - 0x00000AFF] (Flash)
Expected byte value 0x04 but read 0x00 at address 0x00000001.
ERROR: Write verify failed.

using

nrfjprog version: 10.24.2 external
JLinkARM.dll version: 7.80c

Is there any "trick" to make it work, or REV2 FW MUST be compiled against newer Nordic nRF Connect SDK ? 

Best,

Matt

[Mateoosh]

OK, I'll reply to myself, since I made it work: 

Based on   nrfjprog verify fails with chiperase i introduced an --eraseall step , so instead of:

nrfjprog -f nrf52 --recover

nrfjprog -f nrf52 --program fw.hex --verify

(this workflow works with REV1 perfectly)

I ran:

nrfjprog -f nrf52 --recover

nrfjprog -f nrf52 --eraseall

nrfjprog -f nrf52 --program fw.hex --verify

and REV2 verify was OK, device runs :-)

[tesc]

Hi,

Thank you for sharing your solution to the issue.

I did find it a bit strange that an --eraseall is needed, since the --recover should already have erased all user available non-volatile memory. Nevertheless, it looks like use of watchdog timer could explain behavior like the one you see, yes, as described in nrfjprog verify fails with chiperase.

Regards,
Terje