How to improve programming speed

[exigtron]

Hi 

I use the following script to program my boards which takes 20 to 30 seconds to complete. But recovery and programming done through SES for the same code is much faster and completes within 5 seconds. The nRF52 DK is used as a SWD programmer.

echo STARTTIME %Time%

nrfjprog --recover -f NRF52
nrfjprog --program myprogram.hex --verify --chiperase -f NRF52
nrfjprog --pinresetenable
nrfjprog --rbp ALL --family NRF52
nrfjprog --pinreset

echo ENDTIME %Time%

I also tried setting the --clockspeed to 4000 but it didn't help. I saw that SES runs some scripts like InitTarget() and TargetInterface.resetAndStop() but couldn't find much info about them.

I'd like to know how SES achieves faster programming and how to achieve similar programming speeds using command line tools like nrfjprog. Involving a third party to pre-program the units isn't an option.

[haakonsh]

Well, SES most likely does not disable/enable readback protection and verify the flash content. 

Also, you don't need to use --chiperase following a --recover, as the --recover will execute an 'erase all' operation in order to clear the APPROTECT (read-back protection) register in UICR. 

[exigtron]

Hi Haakonsh

Thanks for the suggestions, I'll remove the chiperase which may help, but the most time consuming part seems to be the recover step when using nrfjprog. 

My application has read back protection enabled using either nrfjprog or by configuring APPROTECT through code. If I connect with J-Link using SES or J-Link Commander, I get a message asking if I want to unsecure the device to reprogram it. Clicking on Yes unsecures the device much faster than it takes nrfjprog to recover it. Please see the attached log and screenshot.

Connecting ‘J-Link’ using ‘USB’
Connecting to target using SWD
Loaded C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.16/bin/JLink_x64.dll
Firmware Version: J-Link OB-SAM3U128-V2-NordicSemi compiled Mar 17 2020 14:43:00
DLL Version: 6.80a
Hardware Version: V1.00
Target Voltage: 3.300
Device "NRF52832_XXAA" selected.
InitTarget() start
Device will be unsecured now.
InitTarget() end
Found SW-DP with ID 0x2BA01477
DPIDR: 0x2BA01477
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
AP[1]: JTAG-AP (IDR: 0x02880000)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
ROMTbl[0][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU
ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM

I'd like some help to make sense of what happens here and how does it differ from doing a recover with nrfjprog. I assume SES uses J-link directly to manipulate APPROTECT registers to remove read back protection without using nrfjprog. I like the simplicity offered by nrfjprog but would like some speed gains which may help during production. Feels like I'm getting in to J-link territory here, are there some scripts I could try?

I found something in the link below but still trying to make sense of it devzone.nordicsemi.com/.../approtect-and-dap

[exigtron]

I've enabled read back protection (RBP) during development only to understand how it works and to determine the path for production. I don't mind the delays during development, my question is more about making things faster during production and was wondering how SES is able to recover or unprotect faster than nrfjprog.

I also read the whitepaper on production and feel I may be on the right track that using jlink commands is faster. Also found something here https://devzone.nordicsemi.com/f/nordic-q-a/14708/erasing-bmd-300

I'll try it out once I gain more familiarity.

The whitepaper mentions something about waiting 15 seconds, could it be that recovery with nrfjprog takes more time as it's hardcoded to wait 15 seconds?

infocenter.nordicsemi.com/index.jsp

[haakonsh]

Try using just an eraseall instead of recover when using nrfjprog. As far as i know they should both disable readback protection. 

[exigtron]

eraseall does not disable readback protection, I get the below errors if I try it. I think the only option with nrfjprog is the recover option.

nrfjprog --eraseall -f NRF52
ERROR: The operation attempted is unavailable due to readback protection in
ERROR: your device. Please use --recover to unlock the device.

nrfjprog --program my_program.hex --verify --fast --eraseall -f NRF52
ERROR: The operation attempted is unavailable due to readback protection in
ERROR: your device. Please use --recover to unlock the device.

[haakonsh]

You're right that does not work. 

exigtron said:

The whitepaper mentions something about waiting 15 seconds, could it be that recovery with nrfjprog takes more time as it's hardcoded to wait 15 seconds?

 I tested this myself on my nRF52DK, the --recover option took ~3-4s to complete. I tested with empty flash and with a large FW it did not matter. 

[exigtron]

Hi Haakonsh

Sorry for the delay in responding. I didn't get a chance to run more experiments to see if the speed could be improved, but found a few links with the type of answers I was looking for. Sharing the same in case anyone has similar questions later.

https://devzone.nordicsemi.com/f/nordic-q-a/62020/replacing-nrfjprog-with-jlinkexe

devzone.nordicsemi.com/.../what-are-the-raw-jlink-exe-commands-sent-by-nrfjprog-exe
devzone.nordicsemi.com/.../approtect-and-dap

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fnwp_027%2FWP%2Fnwp_027%2Fintro.html&cp=16_8

infocenter.nordicsemi.com/index.jsp

[Joel]

I am no expert but the maximum clockspeed of writing to device is set by nrfjprog.ini file. By default this is set to 2000. Try editing the .ini file and see if that increases speed of write.

[haakonsh]

Don't go over 8MHz, it is untested and therefore undefined behavior.