nrf5340 debugging restart is too slow

[vinodsdw]

I was using earlier IAR and embedded segger IDE for previous nrf52 versions.

Recently Nordic moved to VS code and things are not smooth as earlier.

When I click debug, it loads the firmware to the nrf5340.

While debugging , if I want to restart the code from beginning, it loads the entire firmware again by erasing the chip.

This is really annoying and I am not sure why it is loading again by taking several seconds ?

Is there any workaround for solving this, coz it really affects the debugging time.

[Susheel Nuguru]

Hi Vinod, 

This is something new that I heard that while trying to restart the debugging, the IDE re-flashes the chip.

I have been using debugging feature in the Visual Studio Code in many occasions and I did not see this before. Are you use that you are restarting the debugging and not exiting the debugger instead of stopping it?
Can you also give me your Visual Studio Code version number so that I can try debugging with the same VSC  version at my desk.

[vinodsdw]

Flashing build to 175103844
C:\Windows\system32\cmd.exe /d /s /c "west flash -d f:\nrf_application\peripheral_lbs2\build --skip-rebuild --dev-id 175103844"

-- west flash: using runner nrfjprog
-- runners.nrfjprog: Flashing file: F:\nrf_application\peripheral_lbs2\build\zephyr\merged_domains.hex
-- runners.nrfjprog: F:\nrf_application\peripheral_lbs2\build\zephyr\merged_domains.hex targets both nRF53 coprocessors; splitting it into: F:\nrf_application\peripheral_lbs2\build\zephyr\GENERATED_CP_NETWORK_merged_domains.hex and F:\nrf_application\peripheral_lbs2\build\zephyr\GENERATED_CP_APPLICATION_merged_domains.hex
[ #################### ] 11.913s | Erase file - Done erasing
[ #################### ] 1.120s | Program file - Done programming
[ #################### ] 1.120s | Verify file - Done verifying
[ #################### ] 4.812s | Erase file - Done erasing
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
[error] [ nRF53] - The write access failed, but no cause could be determined.
[error] [ nRF53] - It may be due to an unaligned access, accessing a nonexistent memory, or a communication issue.
[error] [ nRF53] - Failed writing to code!
[error] [ nRF53] - Failed to program flash
[error] [ nRF53] - Failed while programming file F:\nrf_application\peripheral_lbs2\build\zephyr\GENERATED_CP_APPLICATION_merged_domains.hex.
ERROR: JLinkARM DLL reported an error. Try again. If error condition
ERROR: persists, run the same command again with argument --log, contact Nordic
ERROR: Semiconductor and provide the generated log.log file to them.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.
FATAL ERROR: command exited with status 33: nrfjprog --program 'F:\nrf_application\peripheral_lbs2\build\zephyr\GENERATED_CP_APPLICATION_merged_domains.hex' --sectorerase --verify -f NRF53 --snr 175103844 --coprocessor CP_APPLICATION

* The terminal process terminated with exit code: 33.
* Terminal will be reused by tasks, press any key to close it.

[Susheel Nuguru]

It looks like this is something we have already seen. 

The Visual studio code normally gives you a notification popup asking you to erase the flash since programming the chip on an already program chip does not work without an erase. That should have happened seamlessly but it looks like there are sometimes errors like what you see.

If the popup on the VSC does not show up, just open the command program and erase the chip 

nrfjprog --coprocessor CP_NETWORK -e
nrfjprog --coprocessor CP_APPLCIATION -e 

[vinodsdw]

If I do nrfjprog --recover it works

But I remember when I was working on IAR with same segger, it never used to try loading again even if I stop and start the debugger, it might be assuming the code is still there in the chip either by reading any sort of checksum or the entire code and verifying or by assuming with in short period of time if we stop and start, there is very less chance for changing the hardware in between, I am not sure about the mechanism.

But such an option might help improving the debug time :)

[Susheel Nuguru]

With older version of nRF52 and also with nRF51, they did not have the extra layer of security in the APPROTECT to shield the chip from unwanted debug access. nRF53 does not allow erase and writing to protected flash pages unless a recover is performed. This is the change in the hardware behavior and not just in the IDE.