[support]

Hi,

Sorry for the confusion. Could you please confirm whether the method disappeared for ESP8266/ESP32 devices or for ARM devices?

The ESP8266/ESP32 devices are not supported by the Segger J-Link GDB Stub, so the only way to use Segger J-Link with them is via OpenOCD (VisualGDB supports it). You can use this mode by selecting OpenOCD as the debug method and then picking J-Link as the interface (or switching to the “USB Devices” view and letting VisualGDB handle the debug method selection automatically).

[support]

Hi,

Thanks for renewing your license. There are a few different ways in which VisualGDB can handle X11-based applications, so please let us know the following:

• Are you building the code on the device, or using a cross-compiler (that involves gdbserver)?
• Are you redirecting X11 windows to the Windows machine, or showing them on the target device (via VisualGDB Project Properties -> Debug Settings)?

Also do the regular X11-based tools (e.g. xterm) work when launched over SSH with SmarTTY or when launched directly using the keyboard/video output on the board?

[support]

Hi,

No problem. Feel free to ping us once your license gets renewed and we can share some tricks on diagnosing this.

[support]

Hi,

Thanks for the update and sorry for the confusion. The original code looked like a Linux application, where the C library is completely outside VisualGDB’s control. For embedded projects there are indeed several versions of the syscall implementations for different scenarios (e.g. with/without semihosting). VisualGDB should also be able to automatically download symbols and sources for those libraries and let you step into the syscalls, helping quickly understand which version is being used.

[support]

Hi,

First of all, please try adding the sources from the root directory of your library via Add->Existing item. VisualGDB will automatically add the correct relative path to the COMPONENT_SRCDIRS statement in component.mk, e.g.:

COMPONENT_SRCDIRS += ../../../../library

Then you can modify it to include all necessary subdirectories, e.g.:

COMPONENT_SRCDIRS += ../../../../library \
../../../../library/subdir1 \
../../../../library/subdir2

[support]

Hi,

Sorry, this doesn’t look like a VisualGDB-related issue, so we are not able to provide much help with this. The best advice we could give would be to look through the source code of your C library or asking on StackOverflow.

[support]

Hi,

According to our records, your technical support period has expired. In order to keep on receiving technical support, please renew your license.

[support]

Hi,

Thanks for letting us know. We are currently testing the new BSP based on the SDK 15.0 and might be able to fix this before releasing it.

[support]

Hi,

Sorry, the new ESP-IDF project subsystem is relatively new and is indeed missing support for some advanced use cases. We are working on improving it though.

Editing component.mk will be a reasonable workaround. Simply reload the project afterwards and VisualGDB will automatically update Solution Explorer.

[support]

Hi,

Thanks for confirming this. We have published a detailed tutorial demonstrating the apptrace mechanism (debug output from ESP32 projects) here: https://visualgdb.com/tutorials/esp32/apptrace/

Let us know if you have any questions/suggestions.

[support]

Hi,

You might be able to control the initializer list formatting using the ConstructorInitializerIndentWidth parameter (see clang-format reference). If this doesn’t help, please consider checking with the clang community. Since the clang-format logic is a part of clang, we are not able to tweak it more than clang itself allows, however we should be able to integrate new versions of the formatter into our engine as they come out.

If the formatting commands don’t work, please try checking the View->Clang IntelliSense Diagnostics Console for error messages. If nothing helps, please let us know if there is a specific sequence of steps that could reproduce this issue.

With the highlighting colors, VisualGDB has to use a relatively complex workaround in order to synchronize its color settings with the regular VC++ color settings and sometimes the VS color cache gets corrupt, preventing proper synchronization. Normally changing the corresponding color via Tools->Options manually fixes the problem.

If it doesn’t help, please attach a screenshot of the incorrectly colored code (the entire VS window including the navigation bar so we could check for other possible clues) and a screenshot of the corresponding color setting.

[support]

Hi,

This might be an OpenOCD or gdb bug (unfortunately the ESP32 debugging tools are not as mature as the ARM tools). If you could reproduce this on a basic “blink” project and let us know the exact steps to reproduce it on our side, we could check if there is an easy workaround.

[support]

No problem and thanks for confirming your license.

The ESP-IDF projects use a different structure than the regular VC++ projects (ESP-IDF maintains a list of source folders and will automatically include all sources from each source folder).

If you want to add an existing folder with multiple files to VisualGDB, there are 2 ways to do so:

1. Simply right-click on the project in Solution Explorer and click “Add -> Existing Item”. Then select multiple source files at once. This will add the current directory with the files to the list of ESP-IDF source directories. They will be compiled with your project, but will physically reside in the original folder.
2. Alternatively, right-click at the Source Files folder (or any subfolder) and select “Add -> New Folder”. This will create a new physical subfolder (you can see its full path via the VS Properties window). Copy the external source files to that subfolder using Windows Explorer and add them to the project via Add->Existing Item. This will automatically update the related ESP-IDF properties and add the files into the project. We will add a command for automatically copying files from an external directory to an existing folder to one of the next VisualGDB releases.

[support]

Hi,

It looks like you are not calling the InitializeInstrumentingProfiler() function from your main() function.

Please ensure you call it, so all the related logic gets initialized properly. If you are not sure, please try creating a basic “Blinking LED” project for an STM32 device and then start a profiling session. This will automatically insert the initialization code to the main source file, so you could compare it with your current project.

[support]

Hi,

Thanks for clarifying this. The OpenOCD version bundled with VisualKernel does support aarch64 targets, although we have indeed tested it with a 32-bit Raspbian distro (we used the raspberrypi3.cfg file).

If you could post the error you are getting with raspberrypi3.cfg, we might be able to help you resolve it, however as we have not explicitly tested the 64-bit mode, it might be failing due to an OpenOCD bug. We should be able to provide more details once we see the error message.

[Author]

Posts