NRF53 programming by using nrfjprog-Q

[Steven Wen]

Here is my script for programming. Does the sequence is OK? or any advice to improve? 

nrfjprog --eraseall

nrfjprog --recover --family NRF53 --coprocessor CP_APPLICATION
nrfjprog --recover --family NRF53 --coprocessor CP_NETWORK
nrfjprog --qspieraseall

nrfjprog --recover --family NRF53 --coprocessor CP_APPLICATION
nrfjprog --recover --family NRF53 --coprocessor CP_NETWORK
nrfjprog --recover --family NRF53 --coprocessor CP_NETWORK --program B1_net.hex --verify

nrfjprog --pinreset --family NRF53 --coprocessor CP_NETWORK
nrfjprog --pinreset --family NRF53 --coprocessor CP_APPLICATION

nrfjprog --recover --family NRF53 --coprocessor CP_APPLICATION
nrfjprog --recover --family NRF53 --coprocessor CP_APPLICATION --program B2_app.hex --verify

nrfjprog --pinreset --family NRF53 --coprocessor CP_NETWORK
nrfjprog --pinreset --family NRF53 --coprocessor CP_APPLICATION

[SwRa]

Hi Steven,

I have added some pointers for you to consider.

The --recover command already performs a full erase (including UICR) and disables access protection. Running --eraseall and multiple --recover commands is unnecessary. See here: (+) Differences eraseall and recover - Nordic Q&A - Nordic DevZone - Nordic DevZone 

nrfjprog --qspieraseall is only needed if you have external QSPI flash. If not, you can skip this step.

It is recommended to use --program ... --recover in a single command
This ensures the device is recovered, erased, programmed, and verified in one atomic operation, avoiding issues with leftover firmware from the recovery step. This has been discussed in the Devzone ticket: nrfjprog --verify fails when programming just after a recover (nrf5340) 

 When programming both cores separately, always program the network core first, then the application core.

nrfjprog --pinreset is required only if your application specifically requires a hardware reset after programming. You can avoid this step if you don't require hardware reset..

A simplified sequence is as follows:

Recover and program network core:
nrfjprog --program B1_net.hex --family NRF53 --coprocessor CP_NETWORK --recover --verify

Recover and program application core:
nrfjprog --program B2_app.hex --family NRF53 --coprocessor CP_APPLICATION --recover --verify

Optionally, reset the device:
nrfjprog --pinreset --family NRF53

Best Regards,

Swathy

[Steven Wen]

Hi Swathy,

Here is our logging file for the error after sending command (recover --family NRF53 --coprocessor CP_NETWORK ). but it could be OK after retry. Does it related to command? it happen very often when IC is blank. what does the error message mean? do we have any way to avoid the error occurring?

C:\grmn\prj\mfg\ITMXP>.\JLink\ECOS_box\Garmin\nrfjprog.exe --recover --family NRF53 --coprocessor CP_APPLICATION 
02:51:53 251 , Recovering device. This operation might take 30s.
02:51:54 421 , Writing image to disable ap protect.
02:51:54 485 , Erasing user code and UICR flash areas.
02:51:54 579 , C:\grmn\prj\mfg\ITMXP>.\JLink\ECOS_box\Garmin\nrfjprog.exe --recover --family NRF53 --coprocessor CP_NETWORK 
02:51:54 902 , Recovering device. This operation might take 30s.
02:52:06 385 , ERROR: Recover failed. Please make sure that the correct device family is given

[SwRa]

Hi Steven,

It is not a problem with your command syntax, but rather with the device state or debug interface readiness. The error from the log indicates that the tool was unable to communicate properly with the target device. This is commonly caused when the device is in a blank or protected state or when access protection or readback protection is enabled. Sometimes, the J-Link or the target device may not be ready, especially right after a reset or power cycle. This might also be the reason.

As you have noticed, simply retrying the recover command works. Ensure your J-Link or debugger is properly connected and recognized by your system. Also, always recover the Network core first, then the Application core. Recovering the Application core first can lead to issues, as the Network core recovery erases both cores.

Regards,

Swathy