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]

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.

[Burt]

I think I have a bit more insight but not all the answers. So, the warnings shown do not depend upon the warning flags used in the build. Instead, some warnings are enabled by default. To disable them, you can mouse over to the warning underline and then mouse on Quick Fix... in the pop up window then select Disable all clang-diagnostic-<warning> for example clang-diagnostic-pointer-sign. That will put json 

"C_Cpp.codeAnalysis.clangTidy.checks.disabled": ["clang-diagnostic-pointer-sign"]

into the workspace settings.json. You can change that disabled to enabled to restore the warning or remove "clang-diagnostic-pointer-sign" to go back to the default enabled state.

I can create a simple .c file in some Windows directory outside of my nRF work, for example

int
maint()
{
    unsigned char *b;
    char a[10];

    a[10] = 0;
    b=a;
    b[10] = 0;
    return 0;
}

which will show the pointer-sign warning and also clang-diagnostic-array-bounds. Disabling it adds this to my settings.json:

"C_Cpp.codeAnalysis.clangTidy.checks.disabled": ["clang-diagnostic-array-bounds"],

The problem we have is that when using nrf-connect as a configuration provider, on Windows, the checks are always disabled. Linux and Mac behave--we can enable and disable the warnings.

The question is why Windows misbehaves.

[Burt]

Any updates, Michal? I have been hoping that you get the super experts involved, as the problem(s) are difficult ones. Also, it pays to change Wno-pointer-sign to Wpointer-sign so that you increase the chances of creating warnings (that fail to show up like they should).

Burt