Sanity checking some issues faced while developing using NCS / bit of a rant

RE: Sanity checking some issues faced while developing using NCS / bit of a rant

Einar Thorsrud — Mon, 22 Sep 2025 10:39:34 GMT

Hi,

You can controll if firmware is flashed before every debug sessions with the "nrf-connect.debugging.flash" option (you can search for this in VS Code settings). But regarding RTT what you have seen is currently how things are (this should be possible to sovle on our end in tools and we are workign on it but I do not have any timeline for ir).

RE: Sanity checking some issues faced while developing using NCS / bit of a rant

Tom — Fri, 19 Sep 2025 13:33:20 GMT

I have also noticed that everytime I use the restart button, while debugging, the device is verified, which takes a number of seconds, making debugging quite slow - is it possible to bypass/disable this verification?

RE: Sanity checking some issues faced while developing using NCS / bit of a rant

Tom — Fri, 19 Sep 2025 08:40:57 GMT

Thank you for the candid response Einar. I'm hopeful if there's acknowledgement then it shows that effort is being put in to improve things.

I've uploaded a short video of what I'm seeing, regarding having to select the micro every time, just to check I'm not doing anything wrong: https://imgur.com/a/QvOQWDQ
I did uninstall all the previous versions of J-Link to see if that helped prior to my post.

I have another machine I tried on, that also has several J-Link verisons, 7.94i, 8.20 and 8.70 that is showing the same behaviour.

RE: Sanity checking some issues faced while developing using NCS / bit of a rant

Einar Thorsrud — Thu, 18 Sep 2025 14:04:07 GMT

Hi,

Thank you for the feedback.

[quote user=""]Do I have a configuration/setup issue? Surely this cannot be the expected behaviour?[/quote]

I must admitt that there are sometimes problems with not all tools being updated at the same time, but I am not able to reproduce this on my end. However I notice that when i test with J-Link 8.70 on my end, the target for nRF54L15 is called "nRF54L15_M33" and not "NRF54L15_XXAA", so I wonder if you have multiple versions of the J-Link driver pack installed and may be using an older one?

[quote user=""]

2. If I have RTT connected, fix an issue, build/flash. The RTT console does not remain connected. I have to select RTT again, go through the device selection. This then opens a new terminal but the connection is established in the first terminal.

3. If I try to start debugging, while RTT is connected, it appears to remain connected but seems to interfere with the start up and often I have to restart the micro to get it to run.

[/quote]

These are known problems. We are working on improving this, but for now you have to re-connect the RTT viewer after programming from VS Code or nrfutil.

[quote user=""]4. If using a DK to program another board - is there any way to identify whether it is programming the DK or the attached board? (I don't always have the J-Link to hand, or have left the adapter on another board)[/quote]

There is no specific feature for this, but what I normally do is check by reading out a unique register of the device, for instance FIRC.INFO.DEVICEID which is at 0x00FFC304 on the nRF54L15.

[quote user=""]

I've used vscode as an editor for a long time, often using it alongside SES. As much as SES has a lot of room from improvement, vscode, in terms of flashing/debugging, seems like a huge step back in terms of integration, speed and ease of use.

Is all this expected behaviour or am I seeing some set up issues?

[/quote]

We are working on improvign this, but you are right that in several ways the VS Code approach is more fragmented and less cohesive than traditional embedded IDEs like SES. We are continiously working on improving nRF Connect for VS Code, but all such feedback is welcome.