[support]

Hi,

This looks like a generic ESP-IDF issue and not something specific to VisualGDB. Please feel free to ask on the Espressif forum.

If you get specific low-level instructions and need help translating them to VisualGDB-level settings, please let us know and we will help.

[support]

Hi,

Sorry, unfortunately the ST’s SVD files (files with register definitions) do not include much details, so our BSP building logic uses some heuristics to extract this information from ST’s header files. This process is not perfect and it may skip some definitions, but unfortunately there is no better source for subregister information.

Our best advice would be to locate and patch the corresponding definition file in %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\<family>\DeviceDefinitions (you can keep the unzipped file in place and it will override the .xml.gz file automatically).

[support]

Hi,

The different device IDs happen due to the specifics of Windows driver matching (the HID\<..> is a high-level device node created on top of the USB\<…> device node, letting the USB controller, USB HID and HID class-specific drivers work together in a layered fashion). It should not affect any functionality on the VisualGDB level.

Either way, we have updated VisualGDB to automatically eliminate redundant USB device entries that correspond to the same physical device. It should completely resolve the problem.

Please try this build: VisualGDB-5.5.1.3285.msi

If it still doesn’t work, please share an updated screenshot of the VisualGDB device list with the instance ID display turned on.

[support]

Sorry about that. We have fixed the package cleanup GUI in the following build: VisualGDB-5.5.1.3285.msi

Unfortunately, we could not reproduce the problem with the AVR boards missing. Please check if it is resolved in the latest build. If not, please share a screenshot of the “Installed -> Arduino Platforms” view so that we could see what is going on.

[support]

If we completely hide it from the regular wizard, it may cause more confusion, making it look like the ESP32 toolchain is not installed.

So currently VisualGDB shows the ESP32 toolchain in the regular embedded wizard, but displays a tip suggesting to use the advanced ESP-IDF project wizard.

 

[support]

Hi,

Most likely you are cloning a project sample that was not tested in C++ mode and can be only created as a C project.
Please consider changing the main file extension to .cpp, although you may need to adjust the sample code accordingly.

[support]

Hi,

Sorry for the delay. We have received a few reports of broken compatibility with recent tool updates and wanted to resolve them first.

We have added a special diagnostic mode that shows USB instance IDs for USB-based debuggers to the following build: VisualGDB-5.5.1.3284.msi

Please try enabling USB device diagnostics as shown below:

Then VisualGDB will show the instance IDs each time you are selecting a device:

 

Please share a screenshot of the VisualGDB’s device list showing the IDs and also the full instance ID of the “debug” device in the Windows Device Manager (Properties -> Details -> Device Instance Path) and we should be able to adjust VisualGDB to filter it correctly. If you cannot locate the correct device in Device Manager, please locate any of the virtual devices provided by the debug probe (e.g. the virtual COM port), switch to “Devices by connection” and look for nearby devices.

Attachments:

You must be logged in to view attached files.

[support]

Thanks for reporting this and sorry for not catching this earlier. The development branch of VisualGDB has been recently updated to support the new CMake file API and as a side effect it indeed broke ESP32 FLASH memory programming. We have fixed the issue in the following build: VisualGDB-5.5.1.3283.msi

[support]

Thanks for confirming your support status.

We have investigated the problem and confirmed that having multiple versions of the same Arduino tools installed may break some Arduino platforms despite VisualGDB specifically referencing the correct versions of the tools.

We have updated VisualGDB to detect the incompatible package versions and suggest automatically cleaning them up. Please try this build: VisualGDB-5.5.1.3282.msi

Once you open any source file of the Arduino project that doesn’t load due to conflicting packages, VisualGDB will show a yellow bar on top of the editor suggesting a cleanup of the packages. Please proceed with the cleanup and you will be able to build the project again.

[support]

Hi,

Most likely you are using a slightly older build of VisualGDB (the latest stable v5.4R12 build supports checking out the Arduino core). If you are using the R12, feel free to post the screenshot of the menu with the missing item and we will try to suggest the possible cause.

You can also clone the repository manually by running the following command in the “components” folder of your project:

git clone --recursive https://github.com/espressif/arduino-esp32.git arduino

This will have exactly the same effect as using the command from the menu.

[support]

Thanks for reporting this, it looks like a bug introduced by a recent refactoring in our development branch. Please try this build: VisualGDB-5.5.1.3277.msi

[support]

Thanks for clarifying this. It could be that the old toolchain you are using does not come with dummy syscall implementations that would not trigger the semihosting calls.

We could recommend 3 ways of solving it:

1. Run the program without debugging, reproduce the crash, attach to it and examine the call stack. You will likely see a call to printf() somewhere that triggered the semihosting call. Simply comment it out, or make it conditional in order to remove it.
2. Do not specify the –specs=nosys.specs at all and try building the project. Once it complains about missing _write() and other similar syscalls, provide your own implementations for them that will simply discard the data passed to them.
3. Try using our Advanced Semihosting and Profiler framework and select the option to ignore semihosting calls when the debugger is not attached.

[support]

Thanks for confirming your license key. Specifying –specs=nosys.specs manually should normally work.

If it doesn’t, please let us know:

1. What exactly you are trying to achieve? I.e. why simply not calling printf() is not an option?
2. What is the expected/observed behavior when you use the settings on the screenshot (e.g. expect the project to build, got a specific error)?

This should help us understand what is going on.

[support]

Hi,

It looks like you are using an old toolchain that doesn’t provide fine-grain control over semihosting calls. Please try unchecking the “Provide default stubs for system calls” checkbox (bottom of the 1st screenshot) and then either manually provide dummy syscall implementations, or manually specify “–specs=nosys.specs” via VS Project Properties (not VisualGDB Project Properties) -> Linker -> Command Line.

[support]

Hi,

Sorry, unfortunately the recent versions of STM32CubeMX are somewhat buggy and often include incorrect paths in the generated GPDSC files.

VisualGDB works around the known instances of this, but it looks like you have discovered another one. If you could reproduce it on a freshly created STM32CubeMX project and share it with us (along with the generated GPDSC file), we should be able to add a workaround rule.

If the problem is specific to a project that cannot be shared, please consider cloning our STM32CubeMX importing plugin from Github and adding logic similar to the ApplyFreeRTOSFixes() method that works around known STM32CubeMX bugs.

[Author]

Posts