Cannot flash using VSCode in nRF54L15 dev kit

[FMistrorigo]

Hi,

I just finished to setup everything to start using nRF Connect for VSCode Extension. I followed the "nRF Connect SDK Fundamentals" course in the DevAcademy.

I installed nRF Command Line Tools, VSCode and the nRF Connect for VSCode extension pack. I then installed the latest toolchain and SDK. (all versions at the end)

After copying the Blinky example and changing the code to turn on also a second led, I was able to build the configuration and build the project, but once I tryied to flash it to the board nothing changed. (the board shows in the Connected Devices)

I then tryied different things to make it work and found out that using the nRF Connect for Desktop app everything works... using the programmer tool and passing my merged.hex file, it programmed successfully.

I then moved to VSCode and used the "Erase Board" command to be sure that the board was reachable; It worked and removed the firmware from the dev kit.

I really don't know if the problem is related to something I'm missing or if it's a problem of the command in the extension.

Please help me find out what is causing the problem.

Thanks,

Fabio

MORE INFO:

Command Line Tools (10.24.2)

VSCode version (1.95.3)

nRF Connect for VSCode extension pack (v2024.9.5) - so I'm now working with nRF Connect v2024.11.75.

Toolchain (v2.8.0)

SDK (v2.8.0)

running the command "nrfjprog --version" in powershell returns:
"nrfjprog version: 10.24.2 external"
"JLinkARM.dll version: 8.10h"

[FMistrorigo]

Hi,

This is the build log of the Blink example:

This is the log when I falsh using the Flash button of the VSCode Extension:

It seems like it was able to flash but it isn't actually doing that.

Could it be the antivirus that is used in our company? If yes, how is it possible that the erase works and also the flash using the Desktop app works?

PS: As tou can see the device is in the Connected Devices list, the toolchain and the SKD are fine to me, and the project is built using the edfault configuration selecting only the dev kit and the prj.conf

Thanks,

Fabio

[Vidar Berg]

Hi Fabio,

Thank you for including the screenshots. I haven't encountered any cases where a flash operation was blocked by the antivirus. However, if it were, I would expect nrfutil to return an error. According to the log, it successfully completed both the programming and verification steps. Could you try starting a debug session to see if it works? Alternatively, power cycle the board after flashing to check if it starts executing the new firmware.

[FMistrorigo]

I just did an "Erase and flash board" and the leds stopped blinking, it seems it did only the erase command.

This is the screen of VSCode once I start a debugging session:

And this is what I see once I start a debug session after flashing the merged.hex in the dev kit using the Desktop app:

[Vidar Berg]

The screenshot shows that an error was raised in TF-M before the program reached the main app. I suggest you try with the nrf54l15dk/nrf54l15/cpuapp build target (does not include TF-M) and see if that works to help narrow down the problem.

[FMistrorigo]

It probably throws the error because ther's no program in the board, the "Erase and flash board" only removed the firmware but did't flash it back.
I will try the other build as suggested.

PS. Does the nRF54L15 support the "Read" functionality in the Desktop app, It can be helpfull to understand what happens in the flash.
Now I'm getting this error: "Error: Failed with exit code 1. One or more batch tasks failed: - [Probe] The fw-read operation is not supported, code: Generic. Message: Batch task fw-read failed, [Probe] The fw-read operation is not supported."

[Vidar Berg]

Both TF-M and the main app will be included in the merged.hex file. It looks like the Programmer app has not been updated to support the nRF54L yet, but running the "Memory report" action will give a more accurate representation of the memory layout. Either way, it seems like there is an issue with the configuration of the TF-M image. A workaround for now if you wish to build with TF-M is to add CONFIG_TFM_PROFILE_TYPE_MINIMAL=y to your project configuration file.