Forum Replies Created
-
Posts
-
Hi,
This looks like something coming from the gdb/gdbserver and not directly from VisualGDB, so our best advice would be to search the gdb sources for the “Detaching from process” string, find the line responsible for outputting this message, and check if there is an option that suppresses it. If not, consider patching gdb/gdbserver to remove this line and rebuilding it.
If you cannot find this line in the gdb codebase either, please try creating a minimal repro example and share all relevant screenshots and steps, and we will try to suggest what else could be outputting this line.
Usually, this type of error is caused by power (i.e. power not stable enough and the board keeps resetting), wiring (e.g. incomplete soldering or short-circuited pins) or the existing firmware disabling the JTAG pins (erasing the FLASH memory via esptool.py should take care of that).
If the reset is never issued, please try using both pins 3 and 15 (different debug probes use different reset pin by default). Also make sure the esp8266.cfg file has not been modified and still sets reset_config to trst_and_srst). If you are not sure, you can also delete and reload the ESP8266 OpenOCD package via VisualGDB Package Manager.
Sorry, this looks like an issue of the ESP-IDF itself and not anything specific to VisualGDB. Please consider asking on the ESP32 forum instead.
That said, if you can confirm that the project works as expected outside VisualGDB, but doesn’t work when built with VisualGDB, we can help you configure VisualGDB to match the manual build behavior.
No problem and thanks for confirming it. Most likely, the problem is caused by some differences between the VisualGDB toolchain and the manually imported toolchain. So our first advice would be to try downloading one of our older toolchains that has the same ESP-IDF version number.
If it doesn’t help, please try importing the toolchain that works into VisualGDB as shown below:
- Copy the toolchain.xml file from one of our toolchains into your toolchain directory and replace the revision number in it with 1000.
- Make sure the BinaryDirectory and Prefix elements in toolchain.xml makes sense (they should point to the toolchain’s binaries same way the do for our toolchain).
- Copy the entire esp32-bsp subdirectory from our toolchain into the imported toolchain
- Copy the IDFCheckouts.xml file from our toolchain and edit it to have the correct ESP-IDF version and the correct relative path to the directory where you have ESP-IDF. This will make sure VisualGDB sets the environment correctly. You can add “(manual)” to the ESP-IDF version to distinguish it in the VisualGDB GUI.
- Finally, open VisualGDB Project Properties for your project, locate the toolchain selector and click “Import a toolchain by locating its gdb” and point VisualGDB to the toolchain.xml of the manually imported toolchain.
- Make sure you have the correct ESP-IDF version selected as well. It should match the version specified at step 4.
If you still get different results from the manual build, please locate the command line in the VisualGDB build log (shown in cyan), right-click on it and dump it to a batch file. It will save the environment set by VisualGDB when launching the build command, so you can compare it side-by-side with your own batch file and produces correct results. Eliminating half differences at a time and checking if the results are still different should help find the root cause in just a few steps.
Let us know if you encounter any issues along the way. Helping you getting equivalent results to the manual build is fully covered by our support and we will be happy to help.
Hi,
The property sheets would still work with VisualGDB (as long as you are using MSBuild), however the VS GUI for editing them may indeed not work, as it appears to be specific to the regular MSBuild backend.
The easiest way to add meaningful settings to a property sheet would be to first set them on a specific project, and then copy the <ItemDefinitionGroup> items from the project to the property sheet (do not forget to remove the conditions).
For a quick example, please consider creating an embedded project (e.g. MSP432) and check the .props file created in the project directory. It will be a property sheet containing device-specific settings imported into the project.
Hi,
This looks like an issue specific to ESP-IDF and not something VisualGDB-specific. Please try building and programming the project via command line and check if the problem persists.
If yes, please contact Espressif for support. If not, please let us know more details (build logs and the output from the device when building manually vs. with VisualGDB) and we will help you configure VisualGDB to replicate the results of the manual build.
Hi,
No problem, we have reset your password manually and sent it to the email associated with your new account. You should be able to login now.
Hi,
Good to know that moving VisualGDBCache worked. We are planning to restructure the VisualGDB’s temporary directory paths similarly to what VS does (e.g. .visualgdb\cache, .visualgdb\CodeDB, etc.) in the final VisualGDB 5.5. Based on the current estimates, we will release a preview build using the new structure in the next 2-4 weeks.
It this won’t work, we can add a project-level setting that will allow moving the CodeDB directory by manually changing an element in the .vgdbpsettings/.vgbdproj file.
Hi,
Thanks for pointing this out. Indeed, the command used by OpenOCD to specify the frequency has recently changed and the projects created earlier would still use the old command.
We have released another update to OpenOCD that automatically substitutes the old command with the new one. Please feel free to update it via VisualGDB Package Manager and it will work out-of-the-box.
Hi,
Normally, VisualGDB would automatically pick up the deployed file paths, however some projects might be structured in a way that prevents CMake from reporting the correct .so file path to VisualGDB. Please also make sure you are using VisualGDB 5.5 Preview 4, since it includes special checks that normally find and deploy the .so.<version> files automatically.
You can double-check what exactly gets deployed via VisualGDB Project Properties -> Debug Settings -> Verify Deployment Settings.
If you are using the Custom edition or higher, you can use VisualGDB Project Properties -> Custom Debug Steps to deploy arbitrary files before debugging. For lower editions, we would advise experimenting with CMake definition of the libraspicam.so target (e.g. removing the version specifier) to make sure the library path reported by CMake (shown via Verify Deployment Settings) matches the name referenced by the main project.
Hi,
Please make sure you use the latest VisualGDB 5.5 Preview 4. It will install CMake automatically. If it doesn’t happen, please share a screenshot of the About VisualGDB window and the first page of the VisualGDB Project Properties window for your project and we will advise on the steps to get this working.
Hi,
This looks like the target might be configured to drop the SSH connections after some inactivity time. Normally, VisualGDB would automatically reconnect to the target, however for some types of custom actions that would not work. If this is the case, setting the keep-alive packet period to about 1 minute in Tools->VisualGDB->Manage SSH Connections should fully work around the problem.
Hi,
This looks like a bug in OpenOCD. Please consider building it from sources as shown in this tutorial and stepping through the FLASH programming logic to pinpoint the problem.
Alternatively, please try using Segger J-Link instead. It comes with its own GDB stub that is more reliable than OpenOCD and is fully supported by Segger.
Hi,
If you have accidentally deleted the file built by the project, please try building the project again using the regular Visual Studio’s Build All/Rebuild All command.
Thanks, looks like you are using an MSBuild-based project.
Please refer to the following tutorial for an example on enabling the map files: https://visualgdb.com/tutorials/arm/linkerscripts/
