nRF Connect for VSCode unlimited number of issues

[Burt]

Hi, I have several issues just to start off with. One is when I generate support information, it does its thing, and then stops, and I have no idea where the support information was put. Based on instructions to another customer, that is not supposed to happen. It did not happen for them apparently, but it happened to me.

The next problem is when I start VS Code from the toolchain manager on Linux, v2.0.0, west is not found.

The next problem is when I start VS Code from the command line on Linux, cmake  --version gives an error in VS Code, although it is perfectly fine on the command line.

Basically I can do almost anything in a Linux terminal with regards to building and debugging nRF9160 projects, but on Linux I cannot build or debug, and on Windows I can build but not debug, when VS Code is involved.

I have never ever seen an IDE in many, many years that is quite so indecipherable. This is really crazy. Perhaps you can fix that or switch to another recommended IDE?

Thanks.

Burt

[Michal]

Hello Burt,

Sorry to hear about your issues.

My first question is which Linux distribution are you using, and what version? In general if you are having issues with the Toolchain Manager on Linux I would suggest a manual install, especially since Linux support in Toolchain Manager is quite recent. That is what I use personally.

As for the "generate support information" function, if it doesn't show automatically: on the bottom choose "Output" and then "nRF Connect". It should be there.

Please send the actual errors when reporting them, it is hard to help and/or try to fix possible bugs without that.

Best regards,

Michal

[Burt]

Hi Michal,

Perhaps I have a version issue with Linux--I had not read all the directions beforehand. I am running Ubuntu 22.04.1 LTS, and so is the problem there that I am running newer Ubuntu than 20.04? Oh, yeah, I see in Installing manually that I cannot get kitware-archive. Is that my show stopper? I found I was missing some other things in the dependencies shown after kitware-archive: adding them has not changed my inability to generate support information using the technique that you suggested.

I will give up on Linux but I will probably have questions for Windows and Mac, as I was able to build a sample zephyr hello world project and have correct results when trying to debug, but the application I am really trying to work with, asset_tracker_v2 modified by my colleague, and based on nrf v1.7.0 but where I am using a v2.0.2 toolchain has been miserable. I selected the v2.0.2 toolchain because there were messages about gdb being too old from v1.7.0(I think v8.x vs v9.x). And let me know if I am correct or if there is any workaround for Linux or ways to see the generated support information even without kitware-archive.

Regards,

Burt

[Burt]

Michal,

Debug seems to be working now on Windows (presumably Mac too), although there are some strange things. When I click the "Reset device" button, or the Restart button, the temporary breakpoint, when running my modified v1.7.0 asset_tracker_v2 built with the v2.0.2 toolchain, occurs at line 427 of nrf_wdt.h, which is (or maybe is not) pretty far after main() and c_main(). Wait a minute, I discovered a problem when I have CONFIG_DEBUG_OPTIMIZATIONS=y and CONFIG_DEBUG_THREAD_INFO=y. Then a Reset device or Restart sometimes kills the debug session and brings me back to Run and Debug. Another problem is I am having a terrible terrible bunch of results from Intellisense: you know how I have been confused with VSCode recently--Intellisense is even more confused than I am. Back to the Reset device/Restart problems, they seem to be caused by CONFIG_DEBUG_THREAD_INFO=y. And yet, when I have CONFIG_DEBUG_THREAD_INFO=n then that is when I get that confusing temporary breakpoint at line 427 of nrf_wdt.h.

One thing that either was causing me grief or else was just more complicated than necessary is that I had a launch.json file originally. But when I saw that my simpler applications were working without a launch.json file, I got rid of the complicated one I had in my main application. Do you think it caused me trouble, or was it just ugly?

Thanks, Michal.

Burt

{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: go.microsoft.com/.../ "version": "0.2.0",
"configurations": [
{
"cwd": "${workspaceFolder}",
"executable": "./build/zephyr/zephyr.elf",
"name": "Debug with JLink",
"request": "launch",
"type": "cortex-debug",
"device": "NRF9160_xxAA",
"runToEntryPoint": "main",
"showDevDebugOutput": "parsed",
"servertype": "jlink"
},
{
"name": "(gdb) Attach",
"type": "cppdbg",
"request": "attach",
"program": "${workspaceFolder}/build/zephyr/zephyr.elf",
"MIMode": "gdb",
"miDebuggerPath": "/c/tjmdnl/v1.05DL/toolchains/v2.0.2/opt/zephyr-sdk/arm-zephyr/eabi/bin/arm-zephyr-eabi-gdb.exe",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
},
{
"description": "Set Disassembly Flavor to Intel",
"text": "-gdb-set disassembly-flavor intel",
"ignoreFailures": true
}
]
},
{
"name": "Cortex Debug",
"cwd": "${workspaceFolder}",
"executable": "${workspaceFolder}/build/zephyr/zephyr.elf",
"request": "launch",
"type": "cortex-debug",
"runToEntryPoint": "main",
"device": "NRF9160_xxAA",
"showDevDebugOutput": "raw",
"servertype": "jlink"
}
]
}

[Michal]

Hello Burt,

Actually, Kitware archive is NOT required for 22.04, because that version has an up to date cmake version in the repository, so just skip that point.

If you are working with a 1.7.0 based application then you should be running 1.7.0 NCS yourself. There have been quite a few changes between versions, so they are not compatible.

I would recommend downloading 1.7.0 on the side, just make a folder called ncs_1.7.0 for example and then in this folder run

west init -m https://github.com/nrfconnect/sdk-nrf --mr v1.7.0
west update

as stated here.

Afterwards you should select that folder in your nRF Connect extension welcome page in VS Code

This should resolve at least most of your errors.

Best regards,

Michal

[Burt]

Hi Michal,

I made a lot of progress with Linux. The problem was not what you thought, because my Linux project was a simple one using off the shelf asset_tracker_v2 in v2.0.0. First thing I did was to restore any defaults to the nRF Connect for VS Code settings. That allowed me to both build successfully and see the generated support information (or some change I made allowed me to see that information). However, when I closed and reopened VSCode, my settings changed (or something caused them to change), and I could not build. The trick was to set nrf-connect.toolchain.path to PATH in my workspace settings.json (and maybe in the user settings.json, in any case, I used the settings editor GUI to make the changes).

I have a bugaboo about the difficulty of setting VERBOSE in VS Code, for west. I don't often want VERBOSE set, but once in a while I do. If I were working on the command line, it is ever so easy to either issue

$west build

OR

$ VERBOSE=1 west build

But with VS Code, assuming I want to use the GUI and not type out commands, even simple ones, I have to have something like this in my .bashrc

export VERBOSE=1
unset VERBOSE

and to get VERBOSE, I have to close VS Code, comment the unset VERBOSE line in my .bashrc, and restart VS Code. It may not take much longer than to do the equivalent operation in Eclipse, but in 3 months I will have forgotten what is needed in VS Code--this is just so terribly inferior to Eclipse. Will this be fixed?

I am having the same Unintellinonsense, I mean Intellisense, problems, in Linux that I have on Windows. What is the fix?

Thanks, Michal.

Burt