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

[Tom]

I have started developing a new application based on NCS (previous products still using nRF5 SDK), using the nRF54L15 and I'm struggling with what should be basic tasks. Can I sanity check if what I'm seeing is expected behaviour?

This is my first time with a project using NCS and vscode. I have run through the academy using the nRF52, now using our custom board based on the nRF54L15, as well as the nRF54-DK as a sanity check.

1. Using RTT for the console. Everytime I connect to the board I am faced with the J-Link Target device settings selection, it states "NRF54L15_XXAA" is unknown to this version.

I am running 8.70, currently the latest version. Checking the release notes, support was added in 8.10f, with the latest fix in 8.66.

Do I have a configuration/setup issue? Surely this cannot be the expected behaviour?

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.

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)

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?

[Einar Thorsrud]

Hi,

Thank you for the feedback.

Do I have a configuration/setup issue? Surely this cannot be the expected behaviour?

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?

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.

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.

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)

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.

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?

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.

[Tom]

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.

[Tom]

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?

[Einar Thorsrud]

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).