Forum Replies Created
-
Posts
-
Hi,
Please find the answers to your questions below:
- VisualGDB reuses the regular Visual Studio GUI for adding sources/headers to projects. If you are new to Visual Studio, please consider following a few generic Visual Studio tutorials first in order to get familiar with the basics. Our tutorials indeed focus on the functionality introduced by VisualGDB, and assume basic knowledge of common Visual Studio features.
- VisualGDB does not change the way the program would read text files. If your program is crashing with a seg fault, it likely does something incorrectly. If you suspect that the issue is introduced by VisualGDB, please consider debugging the program manually via gdb. If you can confirm that it works when launched manually and doesn’t work with VisualGDB, we can help you configure VisualGDB to replicate the manual debugging results.
Hi,
This looks like something specific to GoogleTest, rather than VisualGDB. Please consider asking around on the GoogleTest github repository on Github, or simply inspecting the GoogleTest source code.
This looks like something specific to the ESP-IDF (e.g. a bug or a toolchain compatibility issue).
Our best advice would be to export the CMake command line used by VisualGDB to a batch file as shown here. This will help you reproduce the problem outside VisualGDB and use the ESP-IDF documentation to address it.
Once you get the build outside VisualGDB working, feel free to share both original and adjusted command line, and we will help you configure VisualGDB to replicate the correct one.
Sorry, auto-discovered paths within the toolchain directory is usually somewhat rare (ESP-IDF is indeed an exception), so the include path discovery doesn’t have any special logic for this case.
That said, since the settings are stored in CMakeLists.txt files, it’s extremely easy to adjust them by selecting the relevant block and doing a find-and-replace.
Hi,
No problem, this function layout indeed triggered a bug in the Outline view, preventing other IntelliSense functionality from working. We have fixed it in this build: VisualGDB-5.6.104.4543.msi
Indeed, VisualGDB will set the IDF_TARGET to just esp32s3 per the XML file. You can verify it by dumping the CMake configuration command to a batch file and rechecking/tweaking it. We suggested editing BSP.XML because the ESP-IDF might have expected IDF_TARGET to be esp32s3(beta2).
Either way, it’s good to know it works with ESP-IDF 4.4. We will also keep an eye for feedback on the OpenOCD issues, and will consider switching the drivers installed by VisualGDB to libusbK.
Hi,
First of all, we have released an updated ESP32 toolchain that includes ESP-IDF 4.4 (https://gnutoolchains.com/esp32/). Please note that it completely supersedes r7, as it includes both ESP-IDF 4.3.2 and 4.4, and the same versions of all other tools as the r7 toolchain.
Regarding the other issue, VisualGDB passes the chip type to ESP-IDF by specifying “-DIDF_TARGET=<…>” in CMake command line. The value of IDF_TARGET gets taken from BSP.XML. Hence, editing BSP.XML will allow changing the value of IDF_TARGET passed to ESP-IDF. If you would like to get it working with IDF 4.3.2, please consider dumping the commands used by VisualGDB as shown here, and adjusting it so that the build works. We can then help you configure VisualGDB to issue the adjusted command line.
The debug error looks like a bug in the OpenOCD or the device. Please try using the OpenOCD binaries from Espressif. If they work differently, we can investigate it further. If not, please consider reporting it as a bug to Espressif.
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.
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.
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
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
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/
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.
Hi,
Setting CMAKE_C_FLAGS_RELEASE from CMakeLists.txt should work just fine, as long as:
- It is done after the project() line
- 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.
