- This topic has 3 replies, 2 voices, and was last updated 3 months ago by
.
-
Posts
-
I recently upgraded the VisualGDB-managed ARM toolchain from GCC 12.3.1/GDB 13.2, to GCC 13.3.1/GDB 15.1. After updating, VisualGDB is unable to program the STM32F767 I have connected via a ST-Link V2 programmer.
This includes programming with the menu options “Start debugging” and “program and start without debugging.”
The following still work:
-Reverting the toolchain to GDB 13.2 and programming with VisualGDB
-Programming manually using the OpenOCD command “%LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -f interface/stlink-v2.cfg -c “transport select hla_swd” -f target/stm32f7x.cfg -c “debug_level 2” -c “program build/Hardware/RelWithDebInfo/[name_of_project].bin verify reset exit 0x08000000”Which leads me to believe that the upgrade to GDB 15.1 is definitely the issue. The OpenOCD version in use is 20240813-0.12.0. The same issue occurs with OpenOCD (ST Fork) 20230713-0.12.0.
When attempting to program with GDB 15.1, the progress bar for the flash programming does not advance as normal – it stays at 0% throughout both erase and write, despite the log advancing through commands and claiming that progress reporting is enabled. Nothing seems out of the ordinary in the GDB log itself, other than the verifications obviously failing at the end. Using ST-Link Utility, I have verified that neither the erase nor the write commands are executed – there is zero change to the contents of flash. I’ve also verified that there is no hardware read or write protection enabled.
The GDB log is attached.
Hi,
We have just rechecked it with a basic STM32F746NG project using the latest toolchain, latest GDB and the latest OpenOCD, and it worked just fine.
Most likely, something about your project is triggering a bug in some of the tools. Please try narrowing it down as follows:
- Double-check that switching to the old toolchain, but keeping the latest OpenOCD fixes the problem. You can also check if using the previous OpenOCD with the new toolchain works (normally, the toolchain should not affect the FLASH programming at all). Make sure you fully rebuild the project after switching the toolchain.
- If the problem is specific to the toolchain and is not affected by OpenOCD, try copying the old gdb executable into the new toolchain. Does the problem still trigger?
- If the problem happens with the new toolchain and old GDB, it can be triggered by some optimization done by GCC. You can try comparing the 2 builds of the project with Embedded Memory Explorer. Is there something particular about the broken version (e.g. some section alignment is off, or some new sections have appeared)?
So, only one version of OpenOCD is involved; it hasn’t changed. Only GCC and GDB changed, and since VisualGDB is using GDB to issue the load command to OpenOCD, GDB is involved. I have been doing full rebuilds when I switch back and forth between the toolchains.
I was going to try swapping the GDB executables, but I actually stumbled on a fix that works in the new GCC/GDB toolchain. I changed the Startup GDB commands from the default:
set remotetimeout 60
target remote :$$SYS:GDB_PORT$$
mon halt
mon reset init
loadto:
target remote :$$SYS:GDB_PORT$$
set remotetimeout 60
target extended-remote :$$SYS:GDB_PORT$$
mon halt
mon reset init
loadI actually just changed ‘remote’ to ‘extended-remote’, per a note I found in the GDB log saying that extended-remote was “preferred.” VisualGDB force-adds the ‘target remote’ line to the start of the commands if it isn’t in the commands though, so I have no idea if it works without that first target remote.
I went back and confirmed via a few wipes and reprograms; it works with extended-remote, but not with remote.
I’ve never used the CLI level GDB commands for a remote target, so I’m no expert, but it seems that the difference is that extended-remote remains connected when the target exits. Maybe the newer version of GDB is triggering an exit before the programming starts, but after it fetches information like flash size.
Hi,
Thanks for sharing this. Normally, the main difference between the “target extended-remote” and “target remote” is about being able to restart the debugged program without restarting the debug session. It makes sense for debugging Linux programs (being able to start the program again without manually restarting gdbserver), but doesn’t change much for the embedded workflow where the target program never truly “exits”, hence we never changed the default command used by VisualGDB.
Either way, it using target extended-remote works around the programming bug, you can use it instead of target remote. The rest of the functionality should work the same.
We have also released an updated OpenOCD package (20240820-0.12.0) that uses target extended-remote by default.
- You must be logged in to reply to this topic.