Forum Replies Created
-
Posts
-
No problem. Please try capturing a diagnostic gdb log as shown here. It should explain what is going on. If it doesn’t help, please attach the log here and we will help you get it to work.
Sorry, the only supported way to use the VisualGDB-generated Makefile is by building it from VisualGDB. Given the flexibility of GNU Make, you should be able to tweak it to work in other environments, but this is something to do at your own risk, since it involves too many parameters that are outside VisualGDB’s control.
Hi,
Please try this build: VisualGDB-5.5.3.3512.msi
It will display more informative error messages when navigation to build errors fails.
The “requires whitespace after the macro name” error is likely caused by inconsistent target-specific profile. Please try regenerating the MCU-specific part of the project via the first page of VisualGDB Project Properties.
Hi,
Please try locating the command line (make.exe <…>) in the VisualGDB build window. It will have a different color than the rest of the log. Then right-click on it and select “Dump Command Line to a Batch File”.
This will create a batch file with the exact command line used by VisualGDB (including the environment variables). Running it should yield the same results as building the project with VisualGDB. You can then try simplifying the batch file (e.g. removing some environment variables) to see what causes the issue you observed.
Hi,
Please try the latest preview build: VisualGDB-5.5.3.3510.msi
It contains a redesigned Hardware Registers window that includes a “collapse all/expand all” button.
Hi,
Thanks for sharing the repro instructions. We have successfully reproduced and fixed the issue in the following build: VisualGDB-5.5.3.3506.msi
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.
