Forum Replies Created
-
Posts
-
Hi,
You can override the remote console shown by VisualGDB when debugging your project via VisualGDB Project Properties -> Custom Debug Steps -> Remote Console.
This will launch an arbitrary command (e.g. tail -f /var/log/syslog) that will completely replace the regular program output (when running gdb directly) or add an extra output window with the output from the command (when using gdbserver).
Sorry, as this setup is relatively fragile and error-prone, we do not support it officially and cannot suggest an OpenOCD command line that will just work.
If you are able to get a meaningful debug session when running gdb and OpenOCD from command line (and could share the command lines and manual setup commands), we can help you configure VisualGDB to achieve equivalent results.
Good to know it works. In our tests, hardware breakpoints do work when using the latest OpenOCD (2019-10-24), however each subsequent breakpoint reduces the overall debugging performance and may indeed cause weird errors for large projects. You might be able to work around of some issues by adding the “set breakpoint always-inserted 1” command to the gdb startup commands to reduce the amount of times gdb sets the breakpoints.
Also if you can reliably reproduce ESP-IDF crashing when using software breakpoints outside VisualGDB, feel free to report it to Espressif. They might be able to fix it eventually.
Hi,
Most likely, the old project file hardcodes the incorrect path somewhere in the settings. VisualGDB stores its ESP-IDF project settings in XML-based .vgdbcmake/.vgdbproj files, so you should be able to find out the difference by simply comparing a working and a broken project file side-by-side.
Also doing a full rebuild (Rebuild All, not Build All) might help, as it will reset the CMake-specific cache that may also contain some invalid paths.
The VSIX installer is likely using a different API than the VisualGDB installer. We do not use the VSIX installer because VisualGDB needs to install several components (e.g. MSBuild platform) that are shared between multiple VS instances and would not be handled correctly by the VSIX installer.
Yes, please consider following our BSP relocation tutorial.
No problem, we have compared the 2 projects and found the following differences:
- The VisualGDB project did not specify the scatter file and was using the default one.
- The VisualGDB project used the regular C library, while the Keil project used microlib.
After updating both settings and building the release configuration, the output produced by both projects appears identical (when using the release configuration).
Please try re-importing the project using the following VisualGDB build: VisualGDB-5.5.3.3493.msi .
It will automatically import the scatter file setting from the Keil project and will also hide the GCC toolchains when selecting the Keil toolchain on the first wizard page and vice versa.
The microlib setting needs to be configured manually as shown in the attached file (please use the Keil Settings page, as the setting affects both compiler and linker).
If the file produced by VisualGDB still doesn’t work, please confirm that you are using the Release configuration (the project you attached had the Debug configuration built) and try replacing the VisualGDB’s ELF file (VisualGDB\Release\<Project Name>) with the axf file produced by Keil (ensure you disable automatic project rebuilding via Tools->Options->Projects and Solutions->Build and Run). This should help understand whether the problem is still triggered by some differences between the ELF files, or by debugger settings.
Hi,
We would normally advise to use the regular BSP mechanism and then explicitly set the “Excluded from build” flag (not “Exclude from Project”) for the BSP-specific files in the native configuration.
The “Excluded from Build” flag is set for each platform/configuration independently, so it will only affect the configurations where you set it. VisualGDB will not overwrite this flag when regenerating BSP-specific files, so the VisualGDB-specific configurations will also work as intended.
You can read more about combining multiple platforms and configurations in the same project here: https://visualgdb.com/tutorials/porting/multiplatform/
Yes, please try the following build: VisualGDB-5.5.3.3491.msi
It includes a redesigned Hardware Registers window with live mode, previous value history and other usability improvements.
Hi,
Looks like you are using the regular Embedded Project Wizard that is no longer recommended for the ESP32 devices.
Please try using the Advanced ESP-IDF Project Wizard instead as shown in this tutorial: https://visualgdb.com/tutorials/esp32/esp-idf/
Hi,
Please refer to the following page for details: http://visualgdb.com/support/oldpackages/
Sorry, the names shown in the VisualGDB installer come directly from the Visual Studio installer interfaces and it looks like the VS installer reports both versions the same way.
As this is a fairly rare scenario, our advice would be to find out experimentally which of the checkboxes corresponds to the instance you need. Once you select it, VisualGDB will remember it when installing updates, so you won’t need to do it again.
Hi,
Thanks for providing the repro files. It looks like the imported project is missing a reference to the startup file (startup_stm32f429xx.s), hence it indeed won’t work.
Most likely, this happened because you did not select to use the Keil compiler when importing the project (see below). Please double-check both first and the second pages of the wizard have the Keil compiler selected (sorry, those settings are currently separate due to backward compatibility):
Another difference between the projects is that the Keil project is built with full optimization, while VisualGDB project has the Debug configuration selected. It should normally not cause any problems, but some project-specific bugs can only be triggered in one of configurations, but not the other one. Hence if adding the startup file doesn’t solve the problem, please try checking whether the Release configuration of the VisualGDB project works as expected.
No problem. We have rechecked everything and found the root cause. Turns out, that the logic responsible for automatically locating missing packages was not always updating the package definitions, hence it would not find the very recently released packages. We have fixed the issue in our development branch and will include the fix in the next Preview release of v5.5.
