Forum Replies Created
-
Posts
-
@raabjo, we are aware that OpenOCD is not perfect. However, it’s an open-source tool that we have little to do with. Specifically, the FLASH programming code in OpenOCD is maintained by ST. We don’t have any special insights into it and do not know why it doesn’t work with a particular binary. You can try using Memory Explorer to compare different binary versions and narrow down some particular trait that can be avoided (e.g. too small sections or unaligned sections), but it may stop working when ST updates the FLASH programming code.
You can also try using Segger J-Link. They have their own fully supported software stack that typically works better than free open-source tools.
No worries. Their support is usually great and they release updates very frequently, so if you can get them something they can reproduce in their lab, they should be able to fix it.
It’s too bad those things are like 10x the price of ST-Links….
That’s how much it costs to rigorously test the low-level logic with all the combinations of the devices and modes. The fact that nobody in the several decades managed to offer comparable quality, totally speaks for itself.
As for us, we focus on high-level features: visualizations, analysis, live monitoring, while delegating the low-level to those who excel at it.
All we did with the FLASH plugin was looked how OpenOCD handles FLASH drivers and made a convenient adapter that lets you create your own FLASH drivers as ELF files, so instead of digging and patching OpenOCD internals, all you need to do is implement a relatively simple interface on he device side. A small improvement to a free open-source tool that makes it a bit more convenient, that’s all.
We have not tested it with every available device. Our fork of the ST fork does include the logic for loading the plugins, but we have not tested it for compatibility with every ST device family.
If you want something more streamlined, you can look into Segger J-Link. They have their own software stack that doesn’t rely on open-source parts like OpenOCD, and usually just works. VisualGDB supports it out-of-the-box, fully interchangeably with OpenOCD. Another option would be to disable memory programming on the VisualGDB side, and run the STM32CubeProgrammer as a custom pre-debug step (see this tutorial).
As for the open-source parts like the FLASH plugin, please consider them reference designs. Like you can go to the ST’s website and get schematics for typical uses of different microcontrollers. But if you make your own board based on one, and it doesn’t work, it’s generally up to you to figure out why.
The command lines look identical except for the -d argument:
VisualGDB:
"C:\Users\RobertOujesky\AppData\Local\Arduino15\packages\arduino\tools\bossac\1.9.1-arduino5\bossac" --port=COM3 -U -e -w "C:\Users\RobertOujesky\source\repos\ap7\Output\Arduino_UNO_R4_WiFi\Debug/AP1.ino.bin" -R
Arduino IDE:
"C:\Users\RobertOujesky\AppData\Local\Arduino15\packages\arduino\tools\bossac\1.9.1-arduino5/bossac" -d --port=COM3 -U -e -w "C:\Users\RobertOujesky\AppData\Local\arduino\sketches\9144B9EB1CD4BF9BEC21C2EBE1773425/AP1.ino.bin" -R
Please try running both commands manually from the Command Prompt window. Can you confirm that adding “-d” to the VisualGDB’s command line resolves the problem?
Hi,
Sorry, this is for you to figure out. Our support is limited to VisualGDB-specific issues, and this looks like something between OpenOCD, ST-Link and a particular device.
Hi,
The command line looks fine. You can try running it manually and comparing it against the command used by the Arduino IDE (should be mentioned in the Arduino IDE logs). If there is a particular difference between the command lines, we should be able to fix it.
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
