Forum Replies Created
-
Posts
-
No worries. It’s usually hard to suggest anything meaningful based on just “framework X doesn’t work on device Y” because the problem space is just too huge, but now that you narrowed it down to
STLINK_SWD_AP_FAULT, we do have some advice:- If it’s a multi-core device, it should have 2 APs (one AP per core) and OpenOCD sometimes glitches out with one AP but not the other one. You can try hacking it around to forcibly switch between the APs. It could be theoretically doable with just the scripts, but you can do a quick test by hardcoding it in the C code in OpenOCD.
- There is another bug with some STM32 devices where frequently switching them between running/stopped, while trying to read memory, triggers some weird internal state where it starts throwing sticky errors until you restart it. We don’t know a good way to fix it per se, but if switching the plugin from asynchronous mode to synchronous one should mostly avoid triggering it.
Sorry, when we publish tutorials showing how to do something with external source code, we do it to demonstrate specific VisualGDB features, and provide general ideas of what can be done.
Please do not take it as a pledge to port the shown code to every conceivable device and investigate how it works together with other external code that we have never seen. We can always do the porting at our consulting rate, but if we included this work in our regular support, the backlog would be measured in years due to the sheer amount of different devices and libraries.
Hi,
This looks like a bug in VS itself. The trace shows that Visual GDB is sending a debug event (e.g. breakpoint updated) to Visual Studio, but Visual Studio never returns from it.
Please try disabling other extensions, and if it doesn’t help, completely uninstalling and reinstalling Visual Studio.
Hi,
This one is somewhat tricky. Live Watch has the go-to-definition command because the symbol files (where the variable list comes from) record the definitions of variables. So, the command works independently from the IntelliSense engine (and even for projects built outside VisualGDB). Finding all references requires properly parsing all source files, and this is done by a completely different part of VisualGDB.
That said, it’s still fairly straight-forward to achieve: you can go to the variable definition via Live Watch, right-click on it in code and select Find All References.
Hi,
There are a couple of debugging techniques to try here. You can try building a debug build of OpenOCD and setting breakpoints in FLASHPlugin.c to see what requests it gets from gdb, and what it passes to the plugin. You can then try modifying the plugin code to pass these values explicitly and hope to reproduce the problem in a debuggable context.
Another technique would be to reproduce the problem, terminate OpenOCD via Task Manager when it stops responding (it will leave the plugin loaded and running on the device), and do Debug->Attach to Running Program from another Visual Studio instance where you have the plugin project. This will let you see the state of the plugin and determine what it’s doing. You can also modify the plugin to keep some kind of a circular log in the RAM, that can be examined when you attach the debugger.
Thanks for renewing. The error looks like the project was not properly loaded, or the license was not properly applied.
We have updated VisualGDB to show a more informative error message in this case. Please try this build: VisualGDB-6.0.107.5300.msi
No problem, we have rechecked both remaining issues. The logic for moving the solution file was indeed not used when importing CMake projects, and the logic handling rebuilds contained a glitch that didn’t work with some combinations of settings. We have fixed it in this build: VisualGDB-6.0.107.5300.msi
Hi,
No problem, this is indeed a separate issue. That said, it shouldn’t be VisualGDB-specific. VisualGDB uses the same low-level debugging tool as the STM32CubeIDE, and both ultimately show the values they receive from the chip via the debug interface. There might be some device register or OpenOCD command overriding this behavior, and turning it on will fix the problem regardless of the IDE you are using, but VisualGDB cannot do it automatically.
Sorry, this doesn’t look like any known issue. Please try following the tutorials from scratch, make sure it works there, and then try comparing the broken project against the working one. If you can point out a specific setting that consistently triggers the problem, we might be able to suggest a workaround.
It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey
Looks like something is broken with the symbols. Please make sure you understand which symbols are loaded, which paths are referenced by them, and what paths are expected by gdb.
Hi,
Due to historical reasons, the maximum memory size shown in the build output and in the Memory Explorer is fixed for each device type. It doesn’t affect anything other than the displayed utilization, so for the devices with variable size we usually just take the default value from the default vendor-supplied linker script.
You can always patch it on your side by editing the MemoryMap tag in BSP.XML under %LOCALAPPDATA%\VisualGDB.
Another option would be to configure VisualGDB to infer the memory map from the linker script (requires Custom edition) via VisualGDB Project Properties -> Memories.
Hi,
Please refer to the following thread: https://sysprogs.com/w/forums/topic/debugger-setup-for-black-magic-probe/
