[support]

Hi,

Good to know it works.

Passing variables from VisualGDB.exe command line to the build logic would be rather tricky due to the sheer number of different project types supported by VisualGDB, so there is no special option for this. That said, it’s extremely easy to work around: simply create a batch file that will first set the necessary environment, and then invoke VisualGDB.exe. As long as both commands reside in the same batch file, the environment will be carried over correctly.

[support]

Thanks for renewing your support.

VisualGDB loads the ESP32 device list by reading the <sysgcc>\esp32\esp32-bsp\BSP.xml file (you can search for ESP32S3 for a quick example), and then simply passes it to ESP-IDF via the IDF_TARGET parameter.

Hence, if you would like to switch it from esp32s3 to esp32s3(beta2), you can simply patch the BSP.XML file and restart Visual Studio.

You can also try installing ESP-IDF 4.4 on top of our latest toolchain, although we have not finished fully testing this toolchain/ESP-IDF combination. We will run some tests on ESP-IDF 4.4 in the next few days, and will release an updated toolchain that will include it out-of-the-box.

[support]

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey​

[support]

Hi,

The VisualGDB.exe /rebuild command should normally work just fine, as long as the platform and configuration are specified properly.

The issue you discovered was actually a rather obscure bug: VisualGDB was passing the TOOLCHAIN_ROOT variable to CMake (backward compatibility with other project types), that ended up overriding some internal Zephyr variables, and ultimately breaking the build. Loading the project from Visual Studio would use a slightly different logic that already contained a workaround for it, so the problem was limited to using the VisualGDB.exe /(re)build command line.

We have fixed the issue in the following build: VisualGDB-5.6.104.4542.msi

[support]

No problem and good to know it works.

[support]

Thanks for confirming your support status.

The ESP32 devices come with their own highly specialized SDK (ESP-IDF). The SDK enforces splitting the project into multiple components referenced by one or more applications, and allows creating special unit test targets for the components. This layout is considerably different from the regular embedded projects, hence, instead of porting TinyEmbeddedTest to it, VisualGDB reuses the regular ESP-IDF testing functionality, extending it to report the test results directly via JTAG.

You can find a detailed tutorial explaining the ESP32 unit tests here: https://visualgdb.com/tutorials/esp32/tests/

 

[support]

Hi,

The main reason it is not done automatically is because the regular STM32 BSP is completely separate from the STM32CubeMX logic, with numerous edge cases.

E.g. it can have slightly different device names, there could be multiple versions of the BSP with different definition files, etc. So instead of trying to guess which file should be imported automatically, we simply made it easy and intuitive to locate the missing file manually via the link in the Hardware Registers window, so our users can choose the exact file they would want to use.

If ST decides to ship the SVD files with the STM32CubeMX SDKs/device definitions, we will definitely update VisualGDB to import them automatically, but for now we would advise simply picking the definition file manually on first run.

[support]

Hi,

Setting CMAKE_C_FLAGS_RELEASE from CMakeLists.txt should work just fine, as long as:

1. It is done after the project() line
2. It does not specify any extra attributes (e.g. CACHE)

If it doesn’t work, please share your CMakeLists.txt file and a sample gcc command line (you can force ninja to print the failed command line by adding an #error directive in the source file) and we will investigate it further.

[support]

Hi,

Good to know it works and thanks for the kind words.

[support]

Hi,

No problem, this can be easily configured via VS properties (not VisualGDB Project Properties) for the top-level project node in Solution Explorer (with the triangle icon).

You can simply set the Sorting/Grouping -> Groups Sources By Types to False, and the source/header files filters will disappear throughout the project.

The STM32CubeMX files item is a special case though – it internally counts as a BSP item (like the one with the chip icon), but is displayed underneath the main executable to improve usability.

You can try creating a virtual target folder via context menu of the top-level project node and moving it there. Currently, this triggers a bug where the folder will appear in both places, but if using target folders for the STM32CubeMX files folder works for you, we can easily fix it.

[support]

It generally depends on your project type. Normally, if you have VisualGDB and the toolchains/BSPs installed on the build server (same user account as used by Jenkins), you do not need to specify them manually.

You can find several tutorials showing how to use VisualGDB with CI/CD systems here: https://visualgdb.com/w/tutorials/tag/tfs/

[support]

Sorry for the confusion. The NRFConnect projects are not based on MSBuild. They use a completely different mechanism for loading and building, so the MSBuild executable will not recognize them. You can still build them by running devenv.exe /build if you prefer to use the same mechanism for all project types.

That said, if you have VisualGDB installed on that machine, it is easier to build the projects by running VisualGDB directly:

VisualGDB.exe /build <file.vgdbproj>

 

[support]

Thanks for confirming this. Please try the following build, it uses forward slashes for DTC_OVERLAY_FILE: VisualGDB-5.6.104.4539.msi

[support]

Hi,

This happens because the build system does not have VisualGDB installed, so it cannot load the .vgdbproj files.

That said, NRFConnect projects are built directly by CMake with the NRFConnect build scripts. VisualGDB simply runs the build tools and interprets the results. Hence, you can build the project on your build server by manually running CMake and Ninja with the same command lines as used by VisualGDB (you may need to adjust some absolute paths).

Please refer to the following page for a detailed explanation how to CMake-based build projects outside VisualGDB: https://visualgdb.com/documentation/projects/cmake/#troubleshooting

[support]

The first option should work. You can switch the filter from gdb.exe to toolchain.xml in the bottom right corner of the “open file” dialog.

[Author]

Posts