nRF Connect for VSCode unlimited number of issues

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

Parents
  • 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,

    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"
    }
    ]
    }

Reply
  • 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"
    }
    ]
    }

Children
No Data
Related