[support]

Hi,

Sorry, this is a known limitation of the Live Variables view. We should be able to address it in the future WPF-based redesign of this window, however unfortunately it won’t make it into v5.4.

[support]

Hi,

Please try installing VisualGDB 5.4 Preview 8. It contains fixed to many bugs of v5.3 and might resolve this as well.

Please also consider generating projects based on MSBuild, not GNU Make. Unless you specifically need to use GNU Make, they should provide easier experience.

[support]

Hi,

Sorry, VisualGDB does inherit many of Visual Studio’s formatting settings, however due to the internal VS architecture, the indentation must be set independently.

Please try using the Tools->Options->Text Editor->C/C++ (VisualGDB) to configure VisualGDB-specific indentation.

 

[support]

Hi,

Sorry about that. Please download v5.4 Preview 8. It includes all the fixes from all previous builds.

[support]

Hi,

This looks like a verbose MSBuild log from a non-MSBuild project that only shows that MSBuild is launching visualgdb.exe to do the actual build.

Please try turning off MSBuild verbose logging or running the VisualGDB.exe command line manually and check the output from it. It should contain a more informative error message.

[support]

Hi,

Thanks for contacting us. According to our records, it looks like your technical support period has expired. In order to keep on receiving support, please renew your key, or let us know the email associated with the new key if you have renewed already.

[support]

 

 

Yes, the WROVER kit with the on-board JTAG should be indeed more reliable (don’t forget to enable JTAG via jumpers).

[support]

Hi,

Sorry, not currently. VisualGDB is based on a technology (WPF) that allows building complex and easy-to use graphical interfaces, so unless it becomes available on MacOS (or we get sufficient interest from MacOS users to justify creating an abstraction layer on our side), VisualGDB will only run on Windows.

[support]

Hi,

Normally it should not cause any issues. Most FT2232-based JTAG debuggers provide 2 interfaces internally: one for the COM port and another one for the JTAG functionality.

On the high level, they are treated as 2 independent USB devices (similar to having 2 separate devices plugged into a USB hub), so they should not interfere with each other.

[support]

Hi,

It looks like OpenOCD fails to read some of the internal ESP32 registers:

Error: Exception reading icountlevel!

It might be caused by wiring issues, incompatible script or broken hardware.

Generally, given how fragile the ESP32 setup is, we would advise starting with a board that is directly mentioned in our tutorials (e.g. ESP32-WROVER with a built-in JTAG), getting it to work and then moving on to the custom hardware.

[support]

Hi,

We have received feedback from other customers being able to develop large mbed projects with VisualGDB, although they mostly use our mbed BSP (repackaged version of mbed that passed our internal tests).

We are also happy to provide support for any issues you encounter along the way – simply let us know the exact errors you encounter and we will explain the underlying mechanisms and help you resolve them.

[support]

Hi,

No worries, small details like this one are very easy to miss.

[support]

Hi,

It looks like you have removed the startup file from the project (file containing the entry point and the interrupt vectors), so the binary you build ends up completely empty (as all the functions in the project are deemed unused). Note the zero memory usage on the build screenshot.

In order to get a minimal working project, you would need to have an interrupt vector table, a reset handler invoking your main() function and a linker script placing them to correct locations.

If you are not familiar with the details of the GCC-based project initialization, please consider copying BSP-related files instead of removing them, and then removing the unnecessary files and settings from project in several steps, rechecking that the project still builds between them. This should be easier than re-creating the necessary parts of the program from a completely empty project.

[support]

Hi,

Just wanted to let you know that we have updated VisualGDB to run the Cygwin build of CMake using an alternate mechanism that does not trigger the problem. Please use this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.7.2524.msi

It also looks like as of v3.12, the Cygwin-based build of CMake would crash when trying to reload a project without restarting it:

assertion "0" failed: file "<...>/CMake/Utilities/cmlibuv/src/unix/core.c", line 185, function: uv_close
    0 [main] cmake 33156 cygwin_exception::open_stackdumpfile: Dumping stack trace to cmake.exe.stackdump

If you ever encounter that message, please right-click on the project in Solution Explorer and select “Reload CMake Project”. This will restart CMake and reload the project successfully.

[support]

Hi,

This might be caused by this bug. Please try patching your esptool script as shown in the bug thread.

[Author]

Posts