[support]

Hi,

We have not explicitly tested the Qt natvis files with VisualGDB. Hence our best advice would be to create a new .natvis file like described in this tutorial, ensure that it works and then add definitions from the Qt debug helpers one-by-one. If you can confirm that a specific construct from the Qt natvis file works with the regular VS but not with VisualGDB, let us know and we will release a hotfix.

[support]

This could be caused by excessive line endings in the printed lines. Our best advice would be to isolate the exact sequence of steps that causes it and then try removing the line endings (or replacing \r\n with \n).

[support]

Hi,

If the board does not come with a pre-compiled OpenCV, you would need to build it from scratch. This could be somewhat tricky as it’s a big library, but a good starting point would be our Raspberry Pi OpenCV tutorial: https://visualgdb.com/tutorials/raspberry/opencv/build/. It summarizes the build steps and describes the common issues, although the exact steps for Intel Edison may be slightly different.

[support]

Hi,

Sorry, troubleshooting issues specific to the open-source GNU tools unfortunately goes beyond the bounds of our product support. There are plenty of tutorials online though (e.g. this one) or we could guide you step-by-step as a part of our paid consulting services if you don’t want to spend time figuring it out yourself.

[support]

Hi,

Thanks for the update. It’s good to see that ESP32 is getting more documentation. VisualGDB supports the ESP32 OpenOCD as described in that document, but all the debug limitations mentioned in other threads and in our blog are unfortunately still present.

[support]

Hi,

The easiest workaround would be to build gdb from source directly on the Raspberry Pi and replace the original binary with the built one. Normally it should be as easy as unpacking the source package and running “./configure && make && sudo make install”.

[support]

Hi,

VisualGDB actually provides a special timing analysis mode that helps diagnose exactly this type of issues. Please try pressing the button with the timer icon in the GDB Session window and switching it to the “All GDB interaction” mode. It will show all gdb commands that VisualGDB sends to GDB and will display the exact time each command took to get processed. This should explain what causes the delays. If not, let us know your findings and we will suggest how to speed up your debugging experience.

[support]

Hi,

Thanks, yes, this limitation is specific to Clang. As the ‘\r’ line endings are not really used on any of the modern systems, it indeed does not support them properly. Both ‘\n’ and ‘\r\n’ endings are supported correctly though.

[support]

Hi,

The Clang IntelliSense expects all source files to have the UTF-8 encoding. If you are using a different encoding, please change it to UTF-8.

[support]

Hi,

Yes, reproduced the problem. Looks like one of the lines in the commented block uses ‘\r’ as the line ending (not ‘\n’ and not ‘\r\n’). This breaks synchronization between the line numbers as seen by Visual Studio and VisualGDB, so go-to-definition and other functionality starts using wrong line numbers and hence does not work.

Normally Visual Studio should warn you that the line endings in the file are out-of-sync and suggest normalizing them. Please proceed with the normalization and the problem will be resolved automatically.

[support]

VisualGDB takes the memory sizes from the linker script file included with mbed (<BSP>\mbed\targets\TARGET_NORDIC\TARGET_NRF5\TARGET_MCU_NRF52832\device\TOOLCHAIN_GCC_ARM\NRF52832.ld). They may not match the actual memory sizes if the script reserves some of the memory for other components.

Based on our knowledge, mbed support for nRF5x devices requires some extra build steps to combine the image with a bootloader and VisuaGDB does not do it automatically. As a workaround, please try creating a regular non-mbed project until we fully support targeting nRF5x with mbed.

[support]

Hi,

Thanks, looks like our beaglebone toolchain was missing the test.exe program used by Qt. We have updated our toolchain; please update it via Tools->VisualGDB Package Manager.

[support]

Hi,

Not fully sure what you are trying to do. Are you trying to add a Windows configuration to an existing Linux project?

[support]

Hi,

First of all, sorry, our AVR support is very basic as it’s much less popular than ARM-based devices.

The simulator is provided by the gdb debugger and does not always work with all the devices. For precise simulation we recommend using 3rd-party simulators.

Regarding the stand-alone mode, it’s only useful when supporting a device requires referencing some source files from the BSP (this is the case for many ARM devices). For AVR projects there are no such implicit dependencies, so the stand-alone mode is not needed and hence not fully supported.

[support]

Hi,

Thanks for the kind words. VisualGDB works with STM32 out-of-the-box because the underlying debug mechanisms are reliable and stable, so VisualGDB can build on top of them and extend them with usability features. ESP8266/ESP32 is much cheaper, but unfortunately it’s a very shaky foundation. Many basic things don’t work (e.g. see this list) and many other things keep changing between the SDK releases and devices. So until we see some stability in terms of basic functionality, our ESP8266/ESP32 support will be very very basic.

We will consider making a crowdfinding campaign to fix the common annoyances of the open-source ESP8266 debug tools (gdb/OpenOCD), but it’s hard to say if the hobbyist community (that are practically the only users of ESP8266/ESP32) will find it worth the price.

[Author]

Posts