• State Verified Answer
  • Replies 2 replies
  • Subscribers 65 subscribers
  • Views 104 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 329541
Options

"--verify" does no longer work when chip changed from QIAAD0 to QIAAF0

linusRyttermalm

Our production line has stopped working since our PCB supplier has changed our MCU (N52840) from QIAAD0 to QIAADF0.

We have tracked down the issue to a "--verify" flag used when flashing the device.

In production the device is flashed with a softdevice and a bootloader.

Our production scripts are called from function in python but in sequence (in order) they look like this:

nrfjprog -f nrf52 --recover
nrfjprog -f nrf52 --program minimal_bootloader.hex --verify
nrfjprog -f nrf52 --program "+NRF_SDK+"/components/softdevice/s140/hex/s140_nrf52_7.2.0_softdevice.hex --verify --reset

We can flash the device without "--verify" and it seems to work fine.

However, we would like to know what the changes are, since the errata does not indicate anything.

And we want to make sure to avoid running in to any complications down the line.

Error occurs on -> "nrfjprog -f nrf52 --program "+NRF_SDK+"/components/softdevice/s140/hex/s140_nrf52_7.2.0_softdevice.hex --verify --reset"

Error message:

"Encountered error -160: Command verify_file executed for 110 milliseconds with result -160

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: Write verify failed."

Parents
  • +1

    Hello Linus,

    There was a big change in the APPROTECT, which is probably what you are seeing. 

    The thing is that in the latest revisions of all the nRF52 chips, APPROTECT is enabled by default. So if you erase the chip, and reset it (or power cycle), APPROTECT is enabled, and you would need to recover in order to access it.

    This means that the recover command doesn't leave it blank anymore. The recover command writes a few bytes to turn off the APPROTECT. So the "issue" is that when you:

    1: recover

    2: program

    3: verify

    Then whatever is in the flash of the application may not be exactly what the .hex file says, because it also has the part that disables the APPROTECT. So one workaround is to add --sectorerase, like you did.

    I also think you can do this:

    recover -> eraseall -> program --verify

    As long as you don't reset the device between eraseall and program, the debugger should be able to access it.

    In a production point of view, it is quicker to eraseall than using the sectorerase flag. That is because it is faster to erase the entire flash than to erase one page at the time.

    Best regards,

    Edvin

Reply
  • +1

    Hello Linus,

    There was a big change in the APPROTECT, which is probably what you are seeing. 

    The thing is that in the latest revisions of all the nRF52 chips, APPROTECT is enabled by default. So if you erase the chip, and reset it (or power cycle), APPROTECT is enabled, and you would need to recover in order to access it.

    This means that the recover command doesn't leave it blank anymore. The recover command writes a few bytes to turn off the APPROTECT. So the "issue" is that when you:

    1: recover

    2: program

    3: verify

    Then whatever is in the flash of the application may not be exactly what the .hex file says, because it also has the part that disables the APPROTECT. So one workaround is to add --sectorerase, like you did.

    I also think you can do this:

    recover -> eraseall -> program --verify

    As long as you don't reset the device between eraseall and program, the debugger should be able to access it.

    In a production point of view, it is quicker to eraseall than using the sectorerase flag. That is because it is faster to erase the entire flash than to erase one page at the time.

    Best regards,

    Edvin

Children
No Data
Related