[supportKeymaster]

Hi,

Most likely your key is not valid for the latest VisualGDB version. Please use the following page to find out the latest version compatible with your key or to renew it: https://sysprogs.com/splm/mykey

[supportKeymaster]

Thanks for the clarification. You can easily configure VisualGDB to maintain multiple simultaneous versions of the BSP via a checkbox under Tools->VisualGDB->Manage VisualGDB Packages->BSPs. After the multi-version mode is enabled, you can relocate each BSP version to a specific location in your source tree. Would that work for you?

[supportKeymaster]

Sorry, VisualGDB does not support Windows IoT.

[supportKeymaster]

Hi,

Thanks for pointing this out. VisualGDB was indeed only checking the BSP version during project load and not downloading the debug packages or frameworks such as profiler.

We have improved this logic in the following build to automatically download missing debug and framework packages as well: VisualGDB-5.5.1.3258.msi

[supportKeymaster]

Hi,

This looks like some properties defined in the Semihosting/Profiler framework did not get expanded correctly. Normally, opening VisualGDB Project Properties and clicking “regenerate MCU files” should automatically fix this (it might be caused by missing packages that you mentioned in the other thread). Removing the definitions manually is generally not recommended, as it may confuse the framework sources (in case the references to them were not removed from the project), however regenerating the settings via VisualGDB Project Properties will overwrite any changes to stm32.props anyway.

[supportKeymaster]

Hi,

Yes, VisualGDB allows relocating the BSP to an arbitrary location under your source control (see this tutorial).

Once the BSP is relocated, VisualGDB will remember its location on that machine and will automatically configure BSP_ROOT for all related projects to point to it.

[supportKeymaster]

Sorry, unfortunately we are not able to review specific projects and locate the settings that have been configured incorrectly as a part of our regular support. If the semihosting works for a newly created project, the issue is specific to a particular project instance and the only way to get it to work again would be by comparing the 2 projects and eliminating the differences between them.

[supportKeymaster]

Sorry, it looks like something about libOpenCM3 might be interfering with semihosting. As it is a 3rd-party component that does not come from VisualGDB, it is hard to suggest anything specific.

Our best advice would be to create a project as similar as possible to the one that works and then try comparing various settings of the projects that behave differently to find a setting that is causing the incorrect behavior.

[supportKeymaster]

Please try following the tutorial EXACTLY and ensure it works as described. Then try comparing your setup with the tutorial to understand which of the differences could be causing the issue.

[supportKeymaster]

Hi,

Please follow our Semihosting tutorial to get familiar with the related settings and mechanisms.

BTW, we have over 300 different tutorials showing various aspects of VisualGDB and the supported targets, so if you don’t feel comfortable with some VisualGDB features or settings, feel free to search and follow other relevant tutorials to get back on track.

[supportKeymaster]

Hi,

Please try switching the GDB Session window to the “All GDB Interaction” mode and then enable the timing view (clock icon). It will show how much time each gdb command took. Please try locating the command responsible for the delay and let us know if you need help understanding its role.

You can also configure VisualGDB to create a diagnostic log of all commands (including their timing) as shown here: http://visualgdb.com/support/logsubmit

 

[supportKeymaster]

The older versions of VisualGDB would indeed only show updates to packages (e.g. OpenOCD), but not the updates to VisualGDB itself. Either way, downloading and installing VisualGDB 5.4 manually should work perfectly fine (there is no need to uninstall the previous version – the installer will update it automatically).

[supportKeymaster]

Hi,

The reset button would normally issue a reset command to the device, but if it was stopped in a debugger before, it would not take effect until the debug session is resumed by pressing F5.

Please try this build: VisualGDB-5.5.1.3257.msi

We have added an option that allows resuming the session automatically after issuing a reset: Tools->VisualGDB->Embedded->Other->Resume Target After ManualReset.

[supportKeymaster]

Hi,

Please ensure you are using the VisualGDB Project Properties -> External Memories page for defining the external memories. This mechanism automatically updates the memory layout definition used by the Embedded Memory Explorer.

We are also working on experimental support for parsing the linker scripts and detecting custom modifications to the memory list, however it will take a few weeks before we release a preview build with this functionality.

[supportKeymaster]

Thanks for checking this. It looks like the low-level Arduino tools fail to build the project due to some missing components, and hence VisualGDB fails to load the code model (leading to the missing Arduino.h).

We have just rechecked everything on a clean machine (re-downloading Arduino ESP32 package 1.0.1) and the build had succeeded, so the issue is caused by some broken component on your computer. Please consider temporarily moving out the Arduino directory (and removing all directories mentioned in the command line from the output window) to fully reset the Arduino-related state.

If nothing helps, please ensure you can build a newly created sketch with Arduino IDE. If this is the case, please follow the steps below to pinpoint the difference between the 2 IDEs causing the issue:

1. Please try running the build command line shown in the output window manually (from the Command Prompt window) and confirm that the problem still exists.
2. Then try creating/building a basic sketch using the Arduino IDE and check the command line used by it (you can capture it using Process Monitor).
3. Try running the working command line from the same command prompt window and ensure it results in a successful build.
4. Adjust the successful command line to use VisualGDB’s version of the arduino-builder.exe and ensure it works.
5. Try comparing the 2 command lines and running combinations of them to pinpoint a specific argument that causes the problem.

If it still doesn’t help, please share your findings (e.g. the exact command lines and their outcomes) and we will advise you further.

[Author]

Posts