[support]

Hi,

The problem you are describing might be caused by the bootloader.bin file being deleted during the clean of the second project (Visual Studio would then show a build error and building the projects again would resolve it). Please follow the instructions in this thread to update the project settings to work around this.

[support]

No problem. The ESP-IDF 4.0 introduced some internal changes to the structure of CMake statements used by it, so it took us some time to update VisualGDB so that it could automatically edit them.

Both ESP-IDF 3.3 and 4.0 are now supported by the following build:  VisualGDB-5.5.1.3259.msi

Once you install it, the Tools->Manage VisualGDB Packages window will show the new toolchains compatible with ESP-IDF 3.3 and 4.0.

The new build also introduces the new property editing engine that uses schema files instead of hardcoded logic in order to locate and edit framework-specific CMake statements, so we should be able to react faster next time Espressif changes the statement layout again.

[support]

Sorry, we have tried reproducing this with a few different setups, but the .filters file was updated correctly each time. Most likely, the problem is caused by some specific combination of settings in a project that was created with an older VisualGDB version and modified manually.

Either way, if the problem does not trigger for newly created projects and does not disrupt your workflow with the existing ones, we would simply advise ignoring it, as it should not have any noticeable effects.

[support]

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

[support]

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?

[support]

Sorry, VisualGDB does not support Windows IoT.

[support]

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

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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

 

[support]

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

[Author]

Posts