Forum Replies Created
-
Posts
-
The arduino-builder is a part of the Arduino build system. It is generally good for quick prototyping, but is rather hard to maintain because Arduino packages and libraries keep changing, and you will inevitably end up dealing with some compatibility issues in the long run.
As every Arduino core has its own layout of packages and tools, there is no good universal way of archiving them. You can try making a copy of the entire Arduino15 directory and other package directories, but it will still not work if you end up missing some files. A good long-term solution would be to create a regular STM32 project, and manually port the Arduino-specific code from the Arduino project into it, but it would be quite a time investment.
A somewhat easier way would be to put everything into a VM and make a backup of it.
Hi,
This is caused by what appears to be a bug in the device definitions on the ST side. Different variations of the STM32G431 device are now defined with different memory layouts, so our BSP generation logic treats them as separate devices.
It will likely get fixed in the next BSP version once ST fixes the device definitions. Until then, you can use one of the 2 workarounds:
- Manually edit the BSP.XML file, replacing STM32G431RBIx with STM32G431RB.
- Opening VisualGDB Project Properties and changing the device type from STM32G431RB to STM32G431RBIx
On our side, we have updated the BSP generation logic to keep a track of such changes, and preserve the device entry with the short name, even if the latest SDK appears to split it into multiple devices.
Hi,
Thanks for checking this. If the Arduino IDE works, but running the same command outside it produces a different result, it could be some system-level setting (antivirus?) or Arduino IDE doing something undocumented (running a different command before it?). Unfortunately, we are not aware of anything specific that could be causing it and don’t have the same board to try it out.
You can try asking on the Arduino forums for any clues to run the programming command line manually (it’s not really specific to VisualGDB). If there is any trick to getting it to program via command line, VisualGDB should be easily able to replicate it, but if it’s something non-trivial deep within the Arduino IDE, there might be no easy way around it.
Hi,
If it works manually, you can configure it as follows:
- VisualGDB Project Properties -> Debug Settings -> Debug Using = Full-custom mode
- Target selection command: target extended-remote blackmagic.local:2345
- After selecting target: run
- VisualGDB Project Properties ->Additional GDB Commands -> after selecting a target:
- mon swdp_scan
- attach 1
- run
This should fully replicate the manual setup you described.
Hi,
Are you using the Arduino build system (Arduino project wizard) or have you manually ported the Arduino libraries to a regular embedded project?
@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.
