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

[support]

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.

[support]

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.

[Author]

Posts