[support]

Thanks for confirming your support status.

Normally, VisualGDB would display the sources of each component under a corresponding entry in the “Components” view except for the component called “main”. The contents of “main” is shown directly under the project item for convenience.

Based on the screenshots it looks like VisualGDB could not find the main component anymore, so picked up the first component reported by ESP-IDF and merged its contents directly underneath the project view instead.

Normally, we would advise keeping the “main” component name if you decide to move it into a different folder, as it clearly indicates which of the component contains the startup code and makes the project structure easy to read. We could also add an setting that would allow overriding the main component name by editing the XML contents of the .vgdbcmake file, although we would generally advise keeping the main name for readability.

[support]

Good to know the USB device display works. The “unable to find CMSIS-DAP device” issue is a bit trickier. Generally, when VisualGDB detects multiple instances of the same debugging interface, it issues a special command to OpenOCD (cmsis_dap_serial for CMSIS-DAP devices) in order to pick a specific one.

If this doesn’t work, either VisualGDB determined the serial number incorrectly, or OpenOCD fails to handle it.

In order to fully track this down, you would need to build OpenOCD from source (see this tutorial), configure it to run the “cmsis_dap_serial” command and step into the logic responsible for handling it and filtering devices by serial numbers. If it turns out VisualGDB is passing the serial number incorrectly, please let us know more details and we should be able to fix it.

If the problem is on the OpenOCD side (e.g. it tries to query the serial number from the HID-level device instead of the USB-level device), feel free to submit a merge request with the fix to our OpenOCD repository and we will include it in the version we ship with VisualGDB.

We can also do all the investigation and OpenOCD fixing for you, however as it involves troubleshooting external tools and hardware, this would be a subject to a customization fee. Please feel free to contact our sales to get a quote if you would like us to handle this for you.

[support]

Thank you for your inquiry. Unfortunately, the description you provided does not sufficient details for us to reproduce the problem or pinpoint its location. Please describe the issue using the 3-step format shown here.

Please use accurate and precise descriptions for all the settings you change in the wizards and property pages, and also make sure describe the exact modifications you do to any configuration files.

Once we have a clear sequence of steps that allows reproducing the problem on our side, we are usually able to release a hotfix or advise a workaround promptly.

[support]

No worries. The logic we added for elimination of the duplicate entries does compare the serial numbers, so normally having 2 different physical devices should show them correctly.

Please try this build: VisualGDB-5.5.1.3287.msi

Please try enabling View->Other Windows->VisualGDB Diagnostics Console, then open the device list, confirm that there is just 1 device instance, while 2 physical devices are plugged in  and click on the “copy to clipboard” link on the device entry. This will produce a detailed log of enumerating the USB devices and eliminating the duplicates to the VisualGDB Diagnostics Console. Please share the output from that window and we should be able to understand what is going on and fix it further.

[support]

Hi,

This is normally something managed by the OpenOCD tool. As its support for ST-Link is maintained by ST’s engineers, they may eventually merge this into the mainline OpenOCD repository and then VisualGDB will display this warning as well once it picks it up from OpenOCD.

[support]

Strange. Please try installing an older version of the package, locate the directory where VisualGDB installs it (it will appear in the “installed” list) and remove the entire parent directory (that contains both package versions). Then delete the %LOCALAPPDATA%\VisualGDB\ArduinoPackageCache directory and reinstall the latest package. This should clear any incorrectly cached data and get the package to appear again.

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

[Author]

Posts