[support]

Hi,

Zephyr OS i a rather niche OS compared to mainstream RTOSes like FreeRTOS or mbed+RTX, and involves non-trivial setup steps that differ from target to target and from version to version. Hence, we will not be supporting it directly besides the NRFConnect integration.

If you can get all the device-specific setup done and get your project to build manually, you can simply import it into VisualGDB as an existing CMake project and make sure the CMake environment used by VisualGDB matches the environment used by Zephyr (see this page). You will be able to build and debug the project just fine once it is imported.

If the thread layout of your Zephyr configuration is compatible with the one used by NRFConnect, VisualGDB will display them automatically. If not, you can patch our Zephyr thread plugin to handle the changes. Again, as the specifics differ from target to target, we will only officially support it as a part of the NRFConnect SDK integration.

[support]

Hi,

You can achieve this by setting Tools->Options->Text Editor->C/C++(VisualGDB)->Other->Max. change-driven tags to 0. See this page for a comprehensive list of VisualGDB settings.

[support]

Hi,

Good to know it works. Overriding environment variables used by VS could indeed lead to strange behavior, so restoring the default values is always a good idea.

[support]

No problem, we can walk you through the various settings and try to suggest a few workarounds, however we would kindly ask you renew your technical support first, as it has expired a while ago.

[support]

Hi,

The VisualGDB’s IntelliSense engine internally uses Clang 6.0. Hence if you are relying on a setting that was added in a newer version, it will not work. We will update the Clang version used by our engine in one of the next VisualGDB releases.

[support]

Please make sure you can build the project outside VisualGDB first. Once you get it to build outside VisualGDB, please try comparing the command line that results in a successful build with the command line used by VisualGDB (you can find it out in the VisualGDB Build window as shown here).

If you need help locating the settings that will adjust the VisualGDB command line to match the manual build command line, please let us know more details about both command lines and we will be happy to point out the relevant settings.

[support]

Hi,

If the imported project doesn’t compile, we would advise first getting it to successfully build outside VisualGDB, and then proceeding with import.

If you are able to build a project outside VisualGDB, but it doesn’t build with VisualGDB, we can help you configure VisualGDB to replicate the manual build results. If the project doesn’t build outside of VisualGDB either, importing it into VisualGDB will not automatically solve the build problems.

[support]

Hi,

Good to know it works. It is always good idea to install the latest VisualGDB updates, toolchains and packages.

[support]

Hi,

Sorry, we don’t have a ready-to-use visualizer of unordered_map yet. It is on the roadmap, however it’s hard to give any time estimates now. As a workaround, please consider creating one manually as shown in this tutorial.

[support]

Hi,

It looks like you are using a toolchain that outputs dependency files in a format incompatible with Ninja. Please try using our latest ARM toolchain instead and it will work out-of-the-box.

[support]

Hi,

We have rechecked the logic for detecting toolchain settings on the latest GNU ARM toolchain v10.2.1 and it worked as expected. It is hard to say what is causing the behavior your described, however it replacing the file manually works, we would simply advise doing so until we release a fully tested pre-packaged toolchain based on the latest GCC.

[support]

Hi,

You can simply move the directory manually and then import it into VisualGDB by clicking “Install Raspberry Pi Pico SDK” in the SDK selector (in the wizard or VisualGDB Project Properties) and pointing VisualGDB to the new location of the SDK.

[support]

Hi,

We may do it in the future, but since VisualGDB allows importing existing projects very easily, you can simply use the import mode of the wizard to import any examples you prefer.

[support]

Hi,

Yes, please try checking with the Espressif support. The OpenOCD fork is maintained by them, so they might have a better insight into it.

[support]

Hi,

You can simply override the path to the main executable via VisualGDB Project Properties -> Debug Settings so that VisualGDB will launch the .Net runtime with the correct parameters. As long as the library is loaded into the same address space, you should be able to debug it.

[Author]

Posts