Forum Replies Created
-
Posts
-
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.
Hi,
In order to use semihosting or serial output, it needs to be properly supported by the debugged program. I.e. the call to _write() should be routed to the code that outputs the data to either semihosting interface, or the serial port.
The semihosting-specific implementation of _write() is usually provided by the toolchain and can be used for regular embedded projects, however as Arduino uses its own build system, it won’t work there out-of-the-box. Our best advice would be to first get semihosting working on a regular embedded project for the same target, understand the involved compiler options (e.g. by comparing the .rsp files) and then try patching the Arduino build scripts to replicate them. That said, this will require non-trivial troubleshooting and may not work at all.
It could also be worthwhile to check whether the Arduino core for your device provides an existing setting that would enable this functionality.
