[support]

Hi,

If you believe the VisualGDB-based project is still working differently from the project built directly with Keil, please attach the updated projects (including the relevant AXF/ELF files) and we will help you compare them.

[support]

Good to know it works. Most likely, the breakpoints worked with a different configuration (e.g. when running gdb on the target where the paths would be different).

Either way, VisualGDB should normally show a warning about spaces in paths. If not, feel free to let us know more about how you created the project and we will double-check why the warning was not displayed.

[support]

Hi,

Please refer to the following tutorial (step 9) for the list of files that we recommend excluding from the source control: https://visualgdb.com/tutorials/arm/multiuser/

[support]

Sorry, our support only covers Sysprogs products. It is not possible for us to provide support for issues in 3rd-party tools and libraries, even if you are using VisualGDB to build them. Those libraries are not tested/maintained by us and hence are outside of our control.

[support]

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.

[support]

Hi,

The only officially supported way to do so is to use the Custom edition or higher.

[support]

Hi,

This looks like something specific to Qt and not VisualGDB. Please consider asking Qt support.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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

 

[support]

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).

[support]

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.

[support]

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.

[Author]

Posts