nRF Connect for Visual Studio Code Debugger does not show memory locations of variables / wrong peripheral names / randomly stale build configurations

[puz_md]

Hi, when I debug my software (nrf5340 cpuapp) from the nRF Connect plugin in VS Code, when I hover over variables and buffers, only the content of the variables is shown, but not their memory location. Also, if I add a variable or array to watch, I still cannot see its memory location. This is pretty inconvenient. Could this be fixed in a future update?

When I click on some strange symbols next to a buffer/array content, a hex browser opens. (It seems to be another plugin.) But the data shown does not match the buffer/array content shown inside the debugger. This is also very confusing.

Further, when I try to check the contents of peripheral registers, (almost) all peripherals are named *_NS in the debugger view, even though I do not use TF-M. I use the standard nRF5340DK cpuapp build target without _ns. Is this a bug? It is a bit confusing because the _NS modules are located at different memory locations than the ones used in my code...

Just leaving you some feedback here, maybe you want to fix these things some time in the future. It would make debugging much simpler and more intuitive. If I overlooked something important, please let me know.

Update: I have one more issue: The nRF Connect plugin for VS code tells me all the time that my code is stale and needs a pristine build. Even when I didn't change a single thing in the configuration. Any idea what could be the reason?

Best regards,
Michael

[Priyanka]

Hi Michael,

when I debug my software (nrf5340 cpuapp) from the nRF Connect plugin in VS Code, when I hover over variables and buffers, only the content of the variables is shown, but not their memory location. Also, if I add a variable or array to watch, I still cannot see its memory location. This is pretty inconvenient.

In the extension, you have some features in the debugging like a memory explorer. To get this information you need to enable the debug symbol when building. There is also the memory explorer tooltips and also the peripherals view. 

Further, when I try to check the contents of peripheral registers, (almost) all peripherals are named *_NS in the debugger view, even though I do not use TF-M. I use the standard nRF5340DK cpuapp build target without _ns. Is this a bug?

I will check this internally with the team and get back to you soon.

The nRF Connect plugin for VS code tells me all the time that my code is stale and needs a pristine build. Even when I didn't change a single thing in the configuration. Any idea what could be the reason?

A build configuration can become stale if it has been built with SDK or Toolchain settings different than the currently selected ones. Then this can happen even if you haven't made any changes to your code. To update a stale build configuration, you can run the Pristine Build option from the Actions View. 

But yes, there was also a similar problem where even after pristine build the stale state warning continued, but this was for a previous version of the VSCode extension. Which is the version that you are working on? I would suggest you to try updating it to the latest version if you have not done it yet.

Regards,

Priyanka

[GioNor]

Hi,

in the "debugger view" try to add a watch like this:

(NRF_CLOCK_Type *)0x50005000

So you can bypass the _NS issue and access directly to registers addresses you need.

Of course, cast the address with the right structure.

Check the Product Specification for addresses.

[remtec]

I agree, it's inconvenient not to see the memory location of variables entered in the control window.
Sometimes it is useful to understand if the variables have been defined correctly!
Even with the debug symbol active, nothing changes for me.
However, if you enter the variable with the & symbol in front you will be able to see the address and then go and check on the memory map.