nrfjprog --verify fails when programming just after a recover (nrf5340)

RE: nrfjprog --verify fails when programming just after a recover (nrf5340)

ludelle — Thu, 11 Jan 2024 15:26:19 GMT

Thank you for your feedback,

I will use the single step solution to keep short duration for programmation.

regards

RE: nrfjprog --verify fails when programming just after a recover (nrf5340)

dejans — Thu, 11 Jan 2024 13:09:07 GMT

Hi,

Using --recover and --program as separated steps is not expected to work unless you add some erase options to the --program invocation. This is due to the existence of small firmware image which is written to the board (when doing --recover as a standalone step), and which keeps AP protection disabled. Although this might not be what you initially wanted, the easiest way to proceed would be to keep using --program with --recover in a single step, and avoid using standalone --recover step.

Best regards,
Dejan

RE: nrfjprog --verify fails when programming just after a recover (nrf5340)

dejans — Tue, 09 Jan 2024 15:47:18 GMT

Hi,

We will track this issue internally. At the moment, I am not able to provide any estimate on how long fixing this issue could last.

Thank you for reporting this issue and for your patience.

Please let me know if you have any further questions.

Best regards,
Dejan

RE: nrfjprog --verify fails when programming just after a recover (nrf5340)

dejans — Thu, 04 Jan 2024 15:10:12 GMT

Hi,

I have reproduced your reported issue. We will look into it internally. I will get back to you with new information, probably during next week.

Best regards,
Dejan

RE: nrfjprog --verify fails when programming just after a recover (nrf5340)

ludelle — Wed, 03 Jan 2024 12:58:51 GMT

Hi,

It work with --sectorerase, however it take a significant additionnal time.

This is described in nrfjprog --help:

--sectoranduicrerase and --sectorerase
operations normally take significantly longer time
compared to --chiperase operation so use them with
caution.

On our project erase/flash/verify for the two coprocessors take 32s instead of ~ 15s using --recover on single-line.

For the time being we can use the single line command, but it does not fit well with our 'standard flash process'.

Note also that if we retry the procedure 1) and 2) and try to program again with same command line it give another error type.This one is also disturbing because we do not protect the CP_NETWORK and recover of 1) must have removed any protection

3) program with --verify the CP_NETWORK (without --recover)

Programmation failed :

[error] [ Worker] - Can't read memory descriptors, ap-protection is enabled.

nrfjprog --program build/zephyr/GENERATED_CP_NETWORK_merged_domains.hex --verify -f NRF53 --coprocessor CP_NETWORK
[error] [ Client] - Encountered error -90: Command read_memory_descriptors executed for 1 milliseconds with result -90
[error] [ Worker] - Can't read memory descriptors, ap-protection is enabled.
[error] [ Client] - Encountered error -90: Command program_file executed for 31 milliseconds with result -90
[error] [ nRF53] - Failed while detecting device memory block protection status!
[error] [ nRF53] - Failed while reading device information.
[error] [ Worker] - Access protection is enabled, can't read block protection state.
ERROR: The operation attempted is unavailable due to readback protection in
ERROR: your device. Please use --recover to unlock the device.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.

Regards,

RE: nrfjprog --verify fails when programming just after a recover (nrf5340)

dejans — Wed, 03 Jan 2024 10:58:24 GMT

Hi,

You could try to add --sectorerase.

nrfjprog -f NRF53 --program merged_domains.hex --coprocessor CP_NETWORK --verify --sectorerase

Best regards,
Dejan