Forum Replies Created
-
Posts
-
Thanks for the update. We have rechecked everything and it looks like the Arduino tools indeed don’t work as expected when having both 1.0.1 and 1.0.3 packages installed.
We have updated our package lists to show the latest 1.0.3 package. Please install it via Tools->VisualGDB->Manage VisualGDB Packages and then remove the older 1.0.1 package via the same window and you should be able to build the projects as expected.
No problem, please try this build: VisualGDB-5.5.1.3261.msi
It will display “[Paused]” in the ARM semihosting console title when the console is paused.
Normally, deleting those files should not be necessary. Generally, the easiest way to troubleshoot it would be to clone our bootloader example from Github, ensure that it works as expected and compare your project to it.
Another way would be to try tracing the MSBuild tasks involved in the building by turning on verbose MSBuild logging (Tools->Options->Projects and Solutions->Build and Run):
- The BuildBootloaderLinkerInputs should run before the Link task
- The <path>.bootldr-o file should be added as an input to the Link task (see step 14 of the tutorial)
- The .link.rsp file for the main application should include the .bootldr-o file and the .bootldr-o file should not be empty (you can check its contents using the arm-eabi-objdump tool).
This looks like some headers or configuration parameters might be missing in the project.
Generally, the best way to get started would be to select “STM32CubeMX Samples” when creating a new project (see this announcement) and let VisualGDB automatically clone one of the numerous examples that come with the STM32 SDKs, so you won’t need to configure anything manually. We do check that each of those examples compiles out-of-the-box without any errors as a part of the automated pre-release tests, so there should not be any complications along the way.
We can also help you understand various VisualGDB settings and their relation to the underlying C/C++ parameters, however unfortunately we are not able to provide help for generic C/C++ issues, or project-specific issues within our regular support (we do offer a paid consulting service with hourly billing in case you prefer personalized help).
Regarding the STM32CubeMX, please see the following detailed tutorial: https://visualgdb.com/tutorials/arm/stm32/cube/
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.
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.
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.
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
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?
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
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.
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.
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.
