Forum Replies Created
-
Posts
-
Hi,
No problem, you can change the default location of the base folder for BSPs and other components via Tools->VisualGDB->Manage VisualGDB Packages->Change the default BSP folder (requires VisualGDB 5.5).
The Ubuntu toolchain indeed will not work for the STM32MP1 target.
That said, the regular STM32MP1 toolchain should work out-of-the-box. We have also rechecked it with the hardware and it did work as expected (the STM32MP1 build scripts indeed set the default sysroot location to /not/exist, however the definition in toolchain.xml overrides it).
Please try updating to VisualGDB 5.5 RC1, then completely delete and reinstall the STM32MP1 toolchain. If it still doesn’t work, please share the screenshots of the wizard, showing how you create the project and how exactly you try to synchronize sysroot, and we will investigate this further.
Hi,
Sorry for the delay. This is already supported by selecting the “Import Existing Project” mode in the VisualGDB Embedded Project Wizard. We have just published a detailed tutorial showing this scenario: https://visualgdb.com/tutorials/arm/cmake/import/
Please also feel free to try the following build: VisualGDB-5.5.100.3843.msi. It contains various optimizations to the importing process (e.g. the wizard will now use relative paths and will allow skipping toolchain file generation).
Let us know if you encounter any issues with this workflow and we will be happy to make VisualGDB better.
No problem. That said, incorrect concatenation should normally not happen. Please try checking the VisualGDB Build window for the mbed-cli command line (it will be shown in cyan). You can right-click on it and select “Dump command line to a batch file” to save the exact command line (including the working directory and all environment) to an editable .bat file.
You can then try playing around with the .bat file (e.g. replacing forward slashes with backward slashes, or using relative paths instead of absolute paths) to see if there is any workaround to the broken mbed-cli behavior. If you can find a specific parameter that triggers the issue, we will be happy to update VisualGDB to work around it.
This report uses the same data source as the Embedded Memory Explorer. Please try searching for “stack” and “heap” in the memory explorer documentation for an explanation how they are handled.
No worries. We have added support for custom Mbed targets to the following build: VisualGDB-5.5.100.3839.msi. You can now right-click on the project and select “Target a Custom Board“. Custom targets will now also appear in the Mbed platform list.
The test configurations will have the MBED_TEST_MODE macro defined, so you can check it in a commonly included header to define extra macros.
The building of mbed projects is handled directly by mbed-cli, so VisualGDB is not able to work around the path length limitations. The best workaround would be to check out the project to a shorter location (or to symlink c:\prj to an existing checkout).
We have added variable expansion to Raw Terminal settings to build linked above.
Hi,
It looks like you have hardcoded an invalid sysroot directory (/not/exist) somewhere in the settings. Please try creating a new project from scratch and make sure you don’t accidentally specify the invalid sysroot directory.
Thanks for the update, this makes sense. You might be able to work around the inaccessible DHCSR register by creating a global variable (e.g. g_DebuggerAttached) and checking it from the custom CanInvokeSemihostingCalls() implementation. Then you can use gdb scripting to set a breakpoint in some of the functions executed at startup (VisualGDB already sets a breakpoint in main()) and set this variable to 1, once the breakpoint is reached. This would require some non-trivial scripting, but should achieve the same effect as the DHCSR register.
This would make sense if the device did not properly implement the C_DEBUGEN bit in the DHCSR register. You can try double-checking it via the datasheet or the Hardware Registers window (it may not be listed there if the original header files did not mention it).
If it’s not supported, please consider working around it by adding a custom implementation of CanInvokeSemihostingCalls().
Sorry, this is not supported yet. We may add this functionality in the future, together with Arduino -> CMake conversions, but it is not yet on the radar.
The vgagent.exe process is responsible for sending Ctrl-C and Ctrl-Break events to the gdb debugger (you can view the description in File Properties). Unfortunately, this often triggers false positives with low-quality antivirus software.
If your antivirus reports vgagent as a potential threat, please consider submitting a false positive report to your antivirus vendor.
Advanced CMake-based projects were introduced in the latest v5.5 release specifically to address the shortcomings of MSBuild-based projects. We are working on more tutorials/documentation, but you can find some information in our announcement and tutorials.
Hi,
Please consider using the new Advanced CMake Embedded project type introduced in VisualGDB 5.5. It provides much better view in Solution Explorer, supports multiple targets and includes various usability improvements.
For VC++-based projects the “Device-Specific Files” folder name/location is fixed due to the way VisualGDB internally organizes them.
