Forum Replies Created
-
Posts
-
Hi,
This looks like a known OpenOCD issue – some combination of section sizes and alignment causes it to fail the FLASH programming on STM32L4 devices. Please try checking the section sizes/alignments in Embedded Memory Explorer and see if increasing the alignment via the linker script (e.g. aligning every section to 16 or 64 bytes) solves the problem.
Another option would be to use Segger J-Link instead of OpenOCD. The J-Link comes with its own highly optimized gdb stub that handles memory programming better than OpenOCD, works faster and supports software breakpoints in FLASH memory.
Hi,
This might be caused by VisualGDB not determining the variable address correctly, or by the target simply not supporting memory breakpoints.
Please try running the gdb’s watch command manually via the GDB Session window. If it doesn’t work either, your target may not support it. Feel free to let us know the target type (Embedded/Linux/Android) and the debugger configuration (direct/gdbserver) you are using so we could suggest a few other things to try.
If watchpoints work when created manually, but don’t when created with VisualGDB, please try setting them using both ways and send us a diagnostic GDB log showing both the commands entered manually (that work) and the commands issued by VisualGDB (that don’t) so we could see what could be causing the difference.
Hi,
This is likely caused by a missing setting, or an incompletely imported project. We can help you get it to work if you could share the details we requested.
Hi,
This is likely caused by a missing setting, or an incompletely imported project. We can help you get it to work if you could share the details we requested.
Hi,
It looks like you are using the “Cortex-M7 with MPU (memory protection unit)” port of FreeRTOS. If this is intended, you would need to provide implementations for MPU-related functions and linker-level symbols setting boundaries between protected and unprotected regions (VisualGDB doesn’t provide any default implementation for this, so the best starting point would be the STM32 examples).
If this is not intended, please simply select the regular M7 (not M7 with MPU) port via VisualGDB Project Properties -> Embedded Frameworks.
Hi,
It looks like valgrind is running the memory leak detector instead of the profiling module. Could you please recheck whether valgrind works on a clean project? If yes, please try checking the differences between the VisualGDB settings for the 2 projects.
Hi,
The ESP32 app trace feature is already supported out-of-the-box. As long as you are using OpenOCD and enable it on the Embedded Debug Tweaking page, VisualGDB will display the output from the ESP32 apptrace inside Visual Studio.
Hi,
Good to know it works and sorry for the delay: this got triaged as an issue requiring a complex repro on our side, that results in slightly higher turnaround times as we need to recheck everything from scratch. Normally if you are actively working on a solution, please consider sharing more details on your setup and specific problems you encounter and we should be able to answer much faster as we will have more context on the problem.
The configuration shown on your screenshots should be normally supported out-of-the-box.
Could you please share the exact settings that contain hardcoded paths (either the .vgdbproj file, or a screenshot) and also describe what exactly happens if you remove the settings with those paths?
Thanks for your feedback. We will try to clarify the reasoning behind various supported device families below.
VisualGDB comes with out-of-the-box support for many popular devices and also device families that are getting increased traction. This effectively splits the cost of maintaining support for those device families between many users, helping us offer high product quality at a competitive price.
Unfortunately this also means that we cannot offer support for less popular device families like LPC24xx as a part of our regular products without considerably raising the prices, hence we offer several workarounds:
- First of all, you can easily create a project manually by following the legacy device tutorial: https://visualgdb.com/tutorials/arm/legacy/.
- Second of all we publish sources for our tools responsible for generating BSPs for supported devices, so you can create your own BSP generator based on them.
- Finally, we could do if for you as a part of our paid consulting services. Feel free to write an email to our sales to get a quote.
Hi,
The error message looks like something shown by Visual Studio itself, not VisualGDB. It might indicate that IntelliSense is not properly initialized for the source file you are editing.
Are you using the Clang IntelliSense? If not, does the problem get solved if you enable it? If yes, please share a screenshot of the entire VS window showing the source file you opened (including any navigation bars on top) so we could check which IntelliSense engine is handling it.
Hi,
No problem. Please let us know the exact message you get now (after installing pkg-config and resyncing the sysroot). Please also double-check that you have set environment variables mentioned in step #7.
Hi,
Strange. Could you please try locating the <vector> file manually (both on remote machine and locally in %LOCALAPPDATA%\VisualGDB) and check if the corresponding directory is listed on the IntelliSense Directories page?
Hi,
Normally you don’t need custom path mappings for ESP32 projects, as long as the general path style is set to “Cygwin” (the new wizard should set it automatically, but it the project was created with an earlier preview build, it could be set incorrectly).
If you cannot get the project to work without the custom mappings, please let us know more details (your .vgdbproj file, the exact mapping VisualGDB suggests and more context on where it happens) and we should be able to fix it.
Hi,
The local MSBuild projects are built directly without the use of GNU Make (for remote projects VisualGDB generates a temporary Makefile with a different structure than the regular Makefiles), so specifying TARGETTYPE won’t have any effect.
Instead please use the VS project properties (not VisualGDB Project Properties) -> Configuration Properties -> General -> Configuration Type.
