nRF Connect VSCode plugin flashing on nRF5340 not working with runner jlink or nrfutil

RE: nRF Connect VSCode plugin flashing on nRF5340 not working with runner jlink or nrfutil

fnfweek — Tue, 13 Aug 2024 04:52:09 GMT

Great answer, thank you so much.

RE: nRF Connect VSCode plugin flashing on nRF5340 not working with runner jlink or nrfutil

jakkra — Tue, 14 May 2024 20:12:32 GMT

Yes this I'm aware of. Experimented with JLink, and doing an erase and then program using JLink takes:

time /opt/SEGGER/JLink_V788k/JLinkExe -nogui 1 -if swd -speed 4000 -device nrf5340_xxaa_app -CommanderScript jlink_erase -nogui 1 && time /opt/SEGGER/JLink_V788k/JLinkExe -nogui 1 -if swd -speed 4000 -device nrf5340_xxaa_app -CommanderScript jlink_file_flash -nogui 1

0m1,393s(erase) + 0m8,581s(program+verify) = ~10s

Vs.

time nrfjprog --program app/build_debug/zephyr/merged.hex --chiperase --verify

real 0m21,907s

So there are defenately room for improvement by getting the jlink runner functional for nRF53.

I'll file a bug into Zephyr instead for getting jlink runner functional, and hopefully I get some time myself to fix this.

You can close this ticket, thank you 🙂

RE: nRF Connect VSCode plugin flashing on nRF5340 not working with runner jlink or nrfutil

Marte Myrvold — Tue, 14 May 2024 13:08:01 GMT

Hi,

The main culprit when using nrfjprog as runner is the erase type that west uses as default, which is --sectoranduicrerase for the nRF52 device family and --sectorerase for other device families. Here you can see the time it takes to program the Matter light bulb sample on the nRF52840 DK using nrfjprog directly with sectoranduicrerase:

~/ncs/nrf/samples/matter/light_bulb/build/zephyr$ time nrfjprog --program merged.hex --sectoranduicrerase --verify
[ #################### ]  22.069s | Erase file - Done erasing                                                          
[ #################### ]  10.054s | Program file - Done programming                                                    
[ #################### ]   9.856s | Verify file - Done verifying                                                       

real	0m43,825s
user	0m0,943s
sys	0m1,267s

If you use west --erase instead of west, it will use the --chiperase flag, which should reduce the time:

~/ncs/nrf/samples/matter/light_bulb/build/zephyr$ time nrfjprog --program merged.hex --chiperase --verify
[ #################### ]   0.207s | Erase file - Done erasing                                                          
[ #################### ]  10.052s | Program file - Done programming                                                    
[ #################### ]   9.856s | Verify file - Done verifying                                                       

real	0m21,863s
user	0m0,522s
sys	0m1,067s

~/ncs/nrf/samples/matter/light_bulb/build$ time west flash --skip-rebuild --erase
-- west flash: using runner nrfjprog
-- runners.nrfjprog: mass erase requested
-- runners.nrfjprog: reset after flashing requested
Using board 683635785
-- runners.nrfjprog: Flashing file: /home/marte/ncs/nrf/samples/matter/light_bulb/build/zephyr/merged.hex
[ #################### ]   0.206s | Erase file - Done erasing                                                          
[ #################### ]  10.051s | Program file - Done programming                                                    
[ #################### ]   9.852s | Verify file - Done verifying                                                       
Enabling pin reset.
Applying pin reset.
-- runners.nrfjprog: Board with serial number 683635785 flashed successfully.

real	0m25,646s
user	0m1,637s
sys	0m3,439s

It is still not as good as jlink, but it is an improvement.

Using --erase is the same as the 'Erase and Flash to Board' action in the vscode extension:

Best regards,
Marte

RE: nRF Connect VSCode plugin flashing on nRF5340 not working with runner jlink or nrfutil

jakkra — Tue, 14 May 2024 10:33:47 GMT

I understand that, however you should look into why nrfjprog is so much slower than jlink to flash. Since Nordic customers will reflash their FW ALOT, saving a few seconds each time makes a huge difference in the user experience.

RE: nRF Connect VSCode plugin flashing on nRF5340 not working with runner jlink or nrfutil

Marte Myrvold — Tue, 14 May 2024 10:18:16 GMT

Hi,

Thank you for clarifying.

The only option I see for using JLink is to modify the script to handle multiple cores. Since we recommend using nrfjprog, and this works, we can unfortunately not prioritize resources for this at the moment.

Best regards,
Marte

RE: nRF Connect VSCode plugin flashing on nRF5340 not working with runner jlink or nrfutil

jakkra — Mon, 13 May 2024 14:15:11 GMT

Hi and thank you. I fixed the issue with nrfutil of you check me last comment.

2 Reasons I want to use JLink Runner:

1. I want to use jlink runner is because it's alot faster.

jlink: 0m25,406s (NOTE excluding net core, looking at nrfjprog log, it takes about 10s for net core, so add that here then). So let's say JLINK is 35s, so pretty much half time of the other two.

nrfutil: 1m12,801s

nrfjprog: 1m18,912s

Full log from all of them:

jlink:
jakkra@jakkra-XPS-15-9560:~/Documents/project$ time west flash -d /home/jakkra/Documents/project/app/build_debug_v5_rtt --skip-rebuild -i 760208501
-- west flash: using runner jlink
-- runners.jlink: JLink version: 7.88k
-- runners.jlink: Flashing file: /home/jakkra/Documents/project/app/build_debug_v5_rtt/zephyr/merged.hex
Downloading file [/home/jakkra/Documents/project/app/build_debug_v5_rtt/zephyr/merged.hex]...
Comparing flash   [100%] Done.
Erasing flash     [100%] Done.
Programming flash [100%] Done.
J-Link: Flash download: Bank 2 @ 0x00000000: 5 ranges affected (790528 bytes)
J-Link: Flash download: Total: 24.172s (Prepare: 0.118s, Compare: 0.223s, Erase: 16.617s, Program & Verify: 7.120s, Restore: 0.093s)
J-Link: Flash download: Program & Verify speed: 108 KB/s
O.K.
J-Link>g
J-Link>writeDP 1 0
Writing DP register 1 = 0x00000000 (0 write repetitions needed)
J-Link>readDP 1
Reading DP register 1 = 0x00000040 (0 read repetitions needed)
J-Link>q

Script processing completed.


real    0m25,406s
user    0m1,141s
sys     0m1,548s

nrfutil:
jakkra@jakkra-XPS-15-9560:~/Documents/dproject$ time west flash -d /home/jakkra/Documents/dproject/app/build_debug_v5_rtt --skip-rebuild -i 760208501
-- west flash: using runner nrfutil
-- runners.nrfutil: reset after flashing requested
-- runners.nrfutil: Flashing file: /home/jakkra/Documents/dproject/app/build_debug_v5_rtt/zephyr/merged_domains.hex
-- runners.nrfutil: /home/jakkra/Documents/dproject/app/build_debug_v5_rtt/zephyr/merged_domains.hex targets both nRF53 coprocessors; splitting it into: /home/jakkra/Documents/dproject/app/build_debug_v5_rtt/zephyr/GENERATED_CP_NETWORK_merged_domains.hex and /home/jakkra/Documents/dproject/app/build_debug_v5_rtt/zephyr/GENERATED_CP_APPLICATION_merged_domains.hex
-- runners.nrfutil: Upload image.
-- runners.nrfutil: Upload image.
-- runners.nrfutil: Started
-- runners.nrfutil: Board with serial number 760208501 flashed successfully.

real    1m12,801s
user    0m7,425s
sys     0m5,426s

nrfjprog:
jakkra@jakkra-XPS-15-9560:~/Documents/dproject$ time west flash -d /home/jakkra/Documents/dproject/app/build_debug_v5_rtt --skip-rebuild -i 760208501
-- west flash: using runner nrfjprog
-- runners.nrfjprog: reset after flashing requested
-- runners.nrfjprog: Flashing file: /home/jakkra/Documents/dproject/app/build_debug_v5_rtt/zephyr/merged_domains.hex
-- runners.nrfjprog: /home/jakkra/Documents/dproject/app/build_debug_v5_rtt/zephyr/merged_domains.hex targets both nRF53 coprocessors; splitting it into: /home/jakkra/Documents/dproject/app/build_debug_v5_rtt/zephyr/GENERATED_CP_NETWORK_merged_domains.hex and /home/jakkra/Documents/dproject/app/build_debug_v5_rtt/zephyr/GENERATED_CP_APPLICATION_merged_domains.hex
[ #################### ]  10.910s | Erase file - Done erasing                                                          
[ #################### ]   1.497s | Program file - Done programming                                                    
[ #################### ]   1.477s | Verify file - Done verifying                                                       
[ #################### ]  39.834s | Erase file - Done erasing                                                          
[ #################### ]   8.724s | Program file - Done programming                                                    
[ #################### ]   8.654s | Verify file - Done verifying                                                       
Applying pin reset.
-- runners.nrfjprog: Board with serial number 760208501 flashed successfully.

real    1m18,912s
user    0m6,498s
sys     0m5,105s

2. I quite often have issues where it randomly get into a state where I need to recover my board when developing. I don't have reset line connected, hence always doing softreset. I'm also most of the time doing a full chip erase when flashing to save time. This is the reason I wanted to try using JLink instead to see if this issue goes away.

But anyway, thanks for checking. I'll try to patch Zephyr so it works for me using JLink. Thanks for the help.

RE: nRF Connect VSCode plugin flashing on nRF5340 not working with runner jlink or nrfutil

Marte Myrvold — Mon, 13 May 2024 11:53:19 GMT

Hi,

Is there a particular reason you want to use the jlink runner instead of nrfjprog?

Using nrfutil as runner worked out of the box when I tested the Peripheral LBS sample in nRF Connect SDK v2.6.1, so I do not know why you get the error regarding execute-batch.

The script for the jlink runner does not use the NrfBinaryRunner class from nrf_common.py. In nrf_common.py, the merged_domains.hex file is split into two separate files that are programmed to each core separately by program_hex_nrf53():

-- runners.nrfjprog: Flashing file: /home/mamy/ncs/nrf/samples/bluetooth/peripheral_lbs/build/zephyr/merged_domains.hex
-- runners.nrfjprog: /home/mamy/ncs/nrf/samples/bluetooth/peripheral_lbs/build/zephyr/merged_domains.hex targets both nRF53 coprocessors; splitting it into: /home/mamy/ncs/nrf/samples/bluetooth/peripheral_lbs/build/zephyr/GENERATED_CP_NETWORK_merged_domains.hex and /home/mamy/ncs/nrf/samples/bluetooth/peripheral_lbs/build/zephyr/GENERATED_CP_APPLICATION_merged_domains.hex

-- runners.nrfutil: Flashing file: /home/mamy/ncs/nrf/samples/bluetooth/peripheral_lbs/build/zephyr/merged_domains.hex
-- runners.nrfutil: /home/mamy/ncs/nrf/samples/bluetooth/peripheral_lbs/build/zephyr/merged_domains.hex targets both nRF53 coprocessors; splitting it into: /home/mamy/ncs/nrf/samples/bluetooth/peripheral_lbs/build/zephyr/GENERATED_CP_NETWORK_merged_domains.hex and /home/mamy/ncs/nrf/samples/bluetooth/peripheral_lbs/build/zephyr/GENERATED_CP_APPLICATION_merged_domains.hex

The jlink runner does not have a way to handle the two cores, which causes it to fail when flashing applications for both cores.

Best regards,
Marte

RE: nRF Connect VSCode plugin flashing on nRF5340 not working with runner jlink or nrfutil

jakkra — Sun, 12 May 2024 13:56:27 GMT

Ok, after some debugging/searching I found the fix in upstream Zephyr for the nrfutil flashing https://github.com/zephyrproject-rtos/zephyr/commit/0387214bfcafa30e11f8b4d11889f8b55a998fff

Anyway, I want to use jlink and it doesn't work.