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

[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

[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

[Burt]

Oh, for crying out loud, no wonder I am having problems with "unintellinonsense." An important feature has been left out, although I would have to see how Eclipse behaves in a similar case:

I was going down the list of files one by one in the Explorer, opening up directories in the GUI to see the files. So for example, the first file I would see is aws_iot_codec.c. Now my CMakeLists.txt shows that file is not included for the configuration I am using. So why aren't the contents of the file grayed out and why is Intellisense not disabled for that file?

Also, I am having to add include header paths manually. Once I have done the configuration stage of a build, those should be determined automatically.

Here is another KConfig/Intellisense problem in main.c

int agps_wait_threshold_ms = CONFIG_APP_REQUEST_GNSS_WAIT_FOR_AGPS_THRESHOLD_SEC *

MSEC_PER_SEC;

And here is what I get when I hover

Number of seconds to wait for A-GPS data

Type: int

Value: 300

Number of seconds that the application module will wait for A-GPS data to be processed before requesting GNSS data. If set to -1, the application module will wait until A-GPS data has been processed.

Kconfig environment: asset_tracker_v2/build

identifier "CONFIG_APP_REQUEST_GNSS_WAIT_FOR_AGPS_THRESHOLD_SEC" is undefinedC/C++(20)

View Problem

Quick Fix... (Ctrl+.)

It is both defined (as 300) and undefined!!! What is going on here?

Thanks,

Burt

[Burt]

Michal,

I am making progress with Intellisense; however, only by manually adding include directories and an include file to the C/C++ Intellisense settings. According to https://nrfconnect.github.io/vscode-nrf-connect/connect/advanced_features.html everything should happen automatically. Why is it not working automatically? Also, I would editorially state that your project management should have known that in 2021 or 2022, some sort of Intellisense or equivalent is not an advanced feature in an IDE. Yes, the software engineer designing or implementing is probably more advanced than I am, but the feature is expected.

I found a bug in the file cloud_module.c using Intellisense. Forgive me, once I copy and paste from VSCode I can't get out of

#define BUILD_ASSERT(EXPR,MSG...) _Static_assert(EXPR, "" MSG)

Expands to:

_Static_assert(0 || 0 || 0 || 0, "" "A cloud transport service must be enabled")

static assertion failed with "A cloud transport service must be enabled"C/C++(1574)

View Problem

Quick Fix... (Ctrl+.)

Sorry I put the Intellisense error before the code (line 42-46 of cloud_module.c). The IS_ENABLED macro is looking for the CONFIG_xxx parameters to be 0 or 1, but they are instead y and n, so even though CONFIG_NRF_CLOUT_MQTT is y, we get an assert. Strange that I am able to do a build without triggering the assert.

I am also having some low level code issues with __UINT32_TYPE__ not being picked up from zephyr_stdint.h and __STATIC_INLINE definition not being picked up from modules/hal/cmsis/CMSIS/Core/Include/cmsis_armcc.h. In order to get rid of errors from macro LOG_MODULE_REGISTER I had to change "uint32_t" to "unsigned int" around line 434 of log.h. These issues only show up as Intellisense errors, not build errors.

BUILD_ASSERT(IS_ENABLED(CONFIG_NRF_CLOUD_MQTT) ||

IS_ENABLED(CONFIG_AWS_IOT) ||

IS_ENABLED(CONFIG_AZURE_IOT_HUB) ||

IS_ENABLED(CONFIG_LWM2M_INTEGRATION),

"A cloud transport service must be enabled");

---

[Burt]

Sorry, it looks like my text got wiped out above. I don't have a copy. Sh....

[Michal]

Hello Burt,
Sorry for the delay. I am unfortunately unable to elaborate on most of the VS Code issues, as it all should work automatically. I can only imagine that something may have gone wrong during the installation and configuration of some parts and for that I can only recommend a complete manual reinstall. You could maybe try that in a virtual machine, just to do it in a clean environment.

I did found out though that the earlier debugging issue is most likely due to gcc optimizing some things for you.

Best regards,

Michal

[Burt]

Hi Michal,

I think I am now very close to having things work with Intellisense. AFAICT, the trick is to have configurationProvider set to "nrf-connect" in c_cpp_properties.json, and to be careful not to add anything using C/C++ Configurations (Intellisense Configurations) command that will override it. However, there seems to be one exception. The build is done with -Wall -Wno-pointer-sign plus some additional warning flags (standard). But in asset_tracker_v2 (v2.0.0 is my level), in file cloud_module.c, I get a number of warnings for the situation below. Please see if you can recreate this one issue. Everything else seems to be okay at least for now. I may not be able to write anything once I paste from VS Code (my limitation probably) so I'll sign out now and wait for your response.

static void agps_data_handle(const uint8_t *buf, size_t len)

{

int err;

#if defined(CONFIG_NRF_CLOUD_AGPS)

err = nrf_cloud_agps_process(buf, len);

const uint8_t *buf

passing 'const uint8_t *' (aka 'const unsigned char *') to parameter of type 'const char *' converts between pointers to integer types where one is of the unique plain 'char' type and the other is notC/C++(clang-diagnostic-pointer-sign)

nrf_cloud_agps.h(56, 40): passing argument to parameter 'buf' here

Looks like I can type, after all, here. Oh, drats, there should be a yellow

squiggle under buf in the function call to nrf_cloud_agps_process but spellcheck got in the way. Thanks.

[Burt]

Michal,

I cannot replicate this issue with warnings on Windows. Only Linux. Is it guaranteed that I did something wrong? Or can there be a build platform dependency?

[Burt]

Actually, Mac and Linux behave the same and show the pointer-sign warnings. (Mac shows a couple of errors, too, but that appears to be some low level compiler stuff that may possibly be mentioned in the documentation.)

[Michal]

Hello Burt,

Sorry for the long response time, but this case is very uncommon and it's quite a bit to get into.

I have tested the asset tracker in NCS v2.0.0 on Linux (Ubuntu 20.04) and did not get any errors. I have tried both with and without the debug options and I have added your compiler flags into my CMakeLists.txt with zephyr_library_compile_options(-Wall -Wno-pointer-sign). It didn't show any of the pointer warnings you experienced.

Are you using the official Zephyr SDK toolchain or some other compiler? I wonder if it may be a case of NCS using a (partially) incompatible compiler in your case.

Best regards,

Michal

[Burt]

Hi Michal,

I am using the official Zephyr SDK toolchain, yes. Also, please note that -Wall -Wno-pointer-sign are used by default. I only highlighted them in my ticket because: with -Wall by itself you would expect to see the warnings, however, following it with -Wno-pointer-sign should turn off the warnings. An easy way to see the warning flags used is to issue the command line command "VERBOSE=1 west build" and let it get far enough to compile some .c files, and then look at any of the compile commands. So, I would recommend retrying without adding any flags. Most importantly, see my next paragraph, written in "real time."

Also, sometimes I may have had to right click in the cloud-module.c file and select Run Code Analysis on Active File. I am not certain if that is necessary simply to speed things up or if there is a different reason for that being necessary. Okay, now I see why I had to right click select Run Code Analysis on Active File, and hopefully when you do that you will get my results. This warning comes from C_Cpp.codeAnalysis.clangTidy and involves the configuration setting C_Cpp.codeAnalysis.clangTidy.enabled. The default setting is "false", in which case you need to do the right click selection to make clangTidy run. So, it is clangTidy that is giving the wrong warnings on Linux and Mac. I look forward to hearing back from you with your findings.