[support]

Hi,

FTDI JTAG uses the JTAG interface to program the SPI FLASH. Normally you only need the set the driver to either WinUSB or LibUSB (both refer to the same driver, but sometimes one of them fails to install). Note that OpenOCD will try using both interfaces of the USB device that will result in an ACCESS_DENIED or a similar error even if the settings are correct and the second interface can be opened successfully. Although it should not affect programming/debugging, it could be misleading.

If you still cannot get debugging to work, feel free to post your OpenOCD log here and we will check it for common issues.

[support]

Hi,

Please try using our UsbDriverTool to change the driver type. It supports changing the drivers for each interface individually.

[support]

Hi,

Sorry, we are not aware of anything similar. As this looks like a very minor issue, we would suggest simply ignoring it until you get a 100% repro that will make it easy to understand what is causing this.

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

[Author]

Posts