[support]

Hi,

The “JTAG scan chain interrogation failed: all ones” error usually indicates a wiring issue (some of the JTAG pins are not connected properly). We would recommend starting with the ESP32 board from Sparkfun that we officially support and once you get it to work reliably, moving on to a different one.

[support]

Hi,

It is not directly supported yet. The mechanism used by our BSP generator does not report it as a separate framework, so VisualGDB does not show it in the list. We may fix this in the next release, although currently the easiest way to get it to work is simply add the sources to the project manually.

[support]

Hi,

According to the log, it looks like a hardware wiring problem. Please double-check all your wiring and use a logic analyzer to see if the JTAG signals are going through.

Another advice would be to get a board directly tested by us (e.g. Sparkfun ESP32-Thing ), get the debugging to work with it first and then switch over to ESP32-WROVER.

[support]

Hi,

GCC should actually support #pragma once when compiling .c files as well, so normally you won’t need this.

[support]

Hi,

Not sure what you mean by the “standard template”. Could you please provide an example?

[support]

Hi,

Our AVR support is not as good as ARM as AVR devices are generally less popular and the underlying tools VisualGDB uses to do the low-level communication are somewhat more buggy. Can you confirm that programming FLASH on the same device while debugging works, but the program without debugging doesn’t? Or are both options broken?

[support]

Hi,

Looks like there might be a slight confusion. The Live Variables window allows tracking how the value of a single variable changes over time and saving this history (you need to enable plotting for the variables you want to save as otherwise VisualGDB won’t record any history).

If you want to plot a value of a large array at a single point in time, please use the Visual Watch instead of Live Variables.

Another option would be to use the advanced memory window. It can highlight variable boundaries and save selected ranges to binary files.

If this does not help, please let us know what are exactly you trying to accomplish and we will suggest the best way to do it.

[support]

Hi,

The easiest way would be to add another .cpp file and rename it to .c.

[support]

Hi,

Please try right-clicking in the “registers” window to enable the non-default register groups like “FP registers”.

[support]

Hi,

Please find the answers to your questions below:

1. You can copy the HAL to your project folder by converting the project to a stand-alone one (requires Custom edition).
2. You can create project templates with custom folder structures via the template mechanism
3. VS IntelliSense is not designed to handle the GCC-specific language extensions, so it works less reliable than the Clang IntelliSense that is designed specifically for this purpose. You could try locating the parts of the code that are causing the errors (e.g. unrecognized special keywords) and adding workaround definitions (like #define <unrecognized keyword> <empty string>) there, but normally we advise using the Clang IntelliSense as it solves this type of problems by design.

With dark theme, we are gradually switching the VisualGDB GUI to the new WPF framework that handles the VisualGDB theme colors automatically. Currently all the tool windows are following the dark theme colors, although most of the popup windows don’t do that yet.

[support]

Hi,

We have recently fixed a similar problem in our development branch. Please try this build to see if it solves the problem: http://sysprogs.com/files/tmp/VisualGDB-5.3.1.1554.msi

If not, please let us know what type is shown for those variables in the Watch window (VisualGDB uses it to determine the correct format).

[support]

Hi,

When using quick debug, are you running gdb on the device? If yes, this could be a compatibility issue between the gdb and gdbserver. Please try using gdbserver from the original Beaglebone image or building a cross-gdb for Windows based on the same sources that were used to build gdbserver in your image.

[support]

Hi,

The GCC’s STL implementation is indeed not very well optimized, so printf() is a good alternative.

BTW, you can use the dependency view in the embedded memory explorer to quickly see what pulls the large functions in: https://visualgdb.com/tutorials/arm/dependencies/

[support]

Hi,

Thanks, this actually looks like our bug. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.1.1554.msi

[support]

Hi,

This could be caused by power or connectivity issues. Can you reproduce the same behavior with the “Blinking LED” project created by VisualGDB?

[Author]

Posts