Forum Replies Created
-
Posts
-
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.
Hi,
Most likely, you have picked an incompatible combination of the STM32 BSP, USB library and project-specific files. If you would like to manually combine components from different sources, please make sure you understand the STM32 project structure per our documentation.
Alternatively, please consider cloning one of the USB-specific STM32Cube samples via VisualGDB Project Wizard. They are automatically tested before release and should build without any errors.
You can also try using the new STM32CubeMX project wizard added in VisualGDB 5.5 RC1. It provides the best out-of-the-box integration with STM32CubeMX and automatically avoids conflicts between different components.
Thanks for confirming this. It looked like an issue that was recently fixed, so we wanted to double-check that it is not caused by using an old build. We also moved this into a separate forum thread, as the issue appears different from the one discussed in the original thread.
Either way, this looks like the connection between VisualGDB and the floating license server gets lost, and the floating license state is not updated properly. If you could create a ticket for this via our support form, we can send you a private link to a special diagnostic build that should help narrow it down. Please do let us know what version of Visual Studio you are using so that we can double-check it on our side first.
Thanks for the log. Just to double-check, could you please confirm the build number from the Help->About VisualGDB window?
No problem, we have published detailed documentation on the Memory Explorer window here: https://visualgdb.com/documentation/embedded/memoryexplorer/. It also explains where VisualGDB takes the list of symbols, memories, and how stack/heap are typically placed.
Note that the nRF5x linker scripts (that control the stack/heap placement) come directly from the Nordic SDK, so please refer to its documentation for details specific to Nordic devices.
No problem. Please try enabling diagnostic logging via View->Other Windows->VisualGDB Diagnostics Console. Then please try reproducing the problem and attach the full log from the diagnostics console here.
No problem. Indeed, unlike other SDK generators, the Atmel START generator exports the entire project as a single atomic component, so VisualGDB follows its structure and does not allow the selection of individual sub-components.
That said, you can mark individual files from the Atmel START SDK with the “excluded from build” flag and then copy them to the project directory and include them into the project manually. This will allow referencing the existing SDK, while keeping project-specific customizations.
