Faster flashing with VS code and Segger JLINK

[wallyb]

Hello,

I'm developing for a 5340 and using VS code, NRF SDK, and a Segger jlink plus.

My app with Wi-Fi enabled is large:

Memory region Used Size Region Size %age Used
FLASH: 882112 B 1 MB 84.12%
RAM: 270360 B 448 KB 58.93%
IDT_LIST: 0 GB 2 KB 0.00%
* Terminal will be reused by tasks, press any key to clo

Flashing the chip takes a while.  The terminal print says it is taking ~40 seconds, while in reality, it takes about 90. 

-- west flash: using runner nrfjprog
-- runners.nrfjprog: Flashing file: /Users/wally/code/g5fw/g5nrf/build/zephyr/zephyr.hex
[ #################### ] 30.215s | Erase file - Done erasing
[ #################### ] 5.449s | Program file - Done programming
[ #################### ] 5.606s | Verify file - Done verifying
Applying pin reset.

 The bulk of the time looks to be spent during the erase section, which by my stopwatch takes over a minute.

I'm less concerned about the accuracy of the terminal prints, than making the flash faster if possible.

How can I verify that the NRF plugin is using the fastest Segger settings possible, and are there other configurations I can optimize?

thanks

W

[trampas]

I am having the same problems...  Anyone find the answer? 

[liteyear]

FWIW, I discovered I can disable "sectorerase" and get far more bearable flash times. The jury is still out on what is lost by doing this, but as far as I can tell the script responsible is hack on top of hack on top of hack. Much improvement is possible.

Details in this thread.

[trampas]

I have found that in NRF Connect on VSCODE if click the symbol in the left for flash that looks like chip, it will go about 13 seconds faster.  I think it erases all of flash at once then programs, but not sure. 

Nordic really needs to spend some time on their VSCode integration and talk to real developers about pain points with Zephyr and VSCode.   Right now it just one hack on another hack...   

[liteyear]

Yes I think that's the "Erase and Flash" button. Who knows what it does under the hood (I find this all pretty opaque) but I also believe it seems more reliable. The problem is it can't be invoked when clicking "Debug", you have to wait out the failure if you accidentally click the full button, and it's all a waste of time anyway because when you're doing incremental changes there's obviously a shorter method!