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

[support]

Hi,

This could happen if you press Shift-F5 while VisualGDB is still initializing the debug session. Unfortunately this is a VS limitation that cannot be easily addressed. We may add a workaround to this in the future versions, but it will involve unreliable hooks into VS internals. As a workaround, please press the “Cancel” button in the GDB Session window instead of Shift-F5 if you want to abort a debug session before it has initialized.

[support]

Hi,

Thanks for the explanation. If you want to delete a file written by OpenOCD, please add a command for deleting it to pre-debug actions instead of doing it from the remote console program.

Regarding the output freezing, when you click “freeze”, VisualGDB will buffer the new text and will append it to the console once you unfreeze the output. If you believe some text is lost, we would appreciate the repro steps and would gladly fix this.

[support]

Hi,

Normally you should be able to use the regular os_printf()-like functions and the gdb stub will wrap that output so that gdb (and VisualGDB) will recognize it properly.

However, as many other things on ESP8266 and ESP32, this may not always work.

[support]

Hi,

Sure, please let us know the error messages you get and we will advise you how to fix them.

[support]

Hi,

This looks like some sort of a race condition that occurs very rarely. As the workaround is very simple (just close the window), we don’t prioritize fixing it unless someone reports a 100% repro scenario.

It is hard to say why your program cannot delete the specific file. We would recommend displaying a message box from your program before and after deleting the file and then using Process Explorer to check for open handles to that file and Process Monitor to check why delete fails.

You can disable the scrolling in the remote console window by right-clicking and selecting “Freeze contents”.

[Author]

Posts