Forum Replies Created
-
Posts
-
No problem, we have updated the step 6 of the tutorial.
We absolutely did not mind your post. You provided a very accurate description of the issue, and sufficient information for us to fix issues within our control, making VisualGDB better for every other user interested in ITM.
For context, at the time the tutorial was made, there was not much documentation on the “SWO EnableTarget 0 0 1 0” command on the Segger side, so we suggested using it as is. Over time, a couple of users reported issues with ITM, so we redirected them to Segger support (since the ITM handling is implemented inside the J-Link software) that helped them resolve the issue. Turns out, Segger updated the documentation on their side, and was likely directing the users to it. Now that we have updated the tutorial to point to the new documentation, it should make things easier for everyone.
Hi,
This looks like an issue of a specific demo project, and not a VisualGDB bug. Please note that if the project doesn’t build from command line, importing it into VisualGDB will not automatically fix the build errors, since VisualGDB would be using exactly the same command line producing the same result.
Thanks for narrowing it down. Indeed, the directory would usually be created by other MSBuild targets, so InitializeBuiltProjectContext did not need to do it. It is hard to say why this project is different, but we have simply added an extra check for creating the directory if it was missing. Please feel free to try this build: VisualGDB-5.6.104.4545.msi
Hi,
Thanks very much for the very detailed description. Indeed, the Wiki page you linked is newer than the one we used when writing the tutorial and explains the SWO EnableTarget command much better. We have added a new step to the tutorial (#13) explaining how to specify the frequency manually and linking it to the new Wiki page. We have also added a note about the VisualGDB Output window used in the newer VisualGDB versions.
Hi,
This looks like a rather complex setup that contains some rare combination of settings triggering unexpected behavior. The best way of troubleshooting it would be to reproduce it on a clean project from scratch and document the exact steps it takes to trigger the issue. Most likely, the issue will start happening after you change some specific setting.
If you can describe the setting that triggers the issue (or the entire repro steps with the relevant screenshots), we should be able to suggest a fix/workaround.
Hi,
The ESP32 semihosting (apptrace) is implemented by the Espressif’s OpenOCD fork. Last time we checked, it only supported device-to-host transfers (i.e. saving the output generated by the device to a text file via the esp32 apptrace start command).
Feel free to double-check this with Espressif – if there is a reliable way to send the data to the device via the same mechanism, we can gladly add support to it on the VisualGDB side.
Sure, you can always download the packages manually via this page and install them via the VisualGDB Package Manager.
If you want to see all package versions, you can always use the following link to download the package catalog file manually: https://visualgdb.com/hwsupport/catalog?version=latest
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.
