Sysprogs forums › Forums › VisualGDB › Update to latest OpenOCD (ST Fork)
Tagged: OpenOCD ST STM32U0
- This topic has 10 replies, 3 voices, and was last updated 3 weeks, 3 days ago by support.
-
AuthorPosts
-
September 24, 2024 at 05:16 #36023MrZANEParticipant
Hi
I’m trying to develop for the new STM32U0 series, STM32U073KC to be more precise.
Unfortunately the latest OpenOCD (ST Fork) isn’t available in VisualGDB so debugging isn’t possible.Any chance you could update to latest version (Reported as Open On-Chip Debugger 0.12.0+dev-00597-ga5a21219f (2024-06-03-11:04) [https://github.com/STMicroelectronics/OpenOCD] from OpenOCD in STM32CubeIDE)?
Kind regards
Jimmy- This topic was modified 3 months ago by MrZANE.
September 24, 2024 at 08:25 #36025supportKeymasterHi,
Based on what we’ve seen, ST hasn’t published the sources for their latest OpenOCD. We opened an issue on Github for it, but got no reply. You can try contacting them directly – maybe you’ll get better luck.
September 24, 2024 at 08:59 #36026MrZANEParticipantYeha, their github page doesn’t contain anything useful.
Why do you need the source code?
The binary and all relevant support files can be had from C:\ST\STM32CubeIDE_1.16.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.1.400.202404281720 if last version of STM32CubeMxIDE is installed.
License issues?September 24, 2024 at 09:02 #36027supportKeymasterOur OpenOCD forks (including the fork of their fork) contain a couple of minor changes (e.g. commands for low-latency memory reading used by Live Watch and tracing), so we usually just apply those on top of the original sources from either fork, and rebuild everything. Without the sources, this won’t work.
Either way, you can manually just copy the binary from STM32CubeIDE on your side. It should work the same way.
November 27, 2024 at 05:43 #36163ArekParticipantI am working with two STM32H503 Nucleo boards.
Once I switch to USB devices (to allow selection of specific nucleo), I am no longer able to select STM32H5xx device.
There is OpenOCD v0.13 which have added support for those H5 chips, how can I upgrade to this version?
November 27, 2024 at 05:51 #36164ArekParticipantA typo, not 0.13 bt 1.13
https://github.com/STMicroelectronics/OpenOCD/releases/tag/openocd-cubeide-v1.13.0
November 27, 2024 at 16:43 #36166supportKeymasterHi,
Our latest build of the ST’s OpenOCD fork is based on the 1.13.0 branch. Please refer to this page for more details.
December 1, 2024 at 04:28 #36196ArekParticipantHi,
When starting the debuuging following log is produced:
Open On-Chip Debugger 0.12.0 (2023-07-13) [https://github.com/STMicroelectronics/OpenOCD]
What is problematic? For example, either the VS will not start openocd stub, will not erase the flash “Error erasing flash with vFlashErase packet”, do not set breakpoints and – most frequently “Received a SIGINT: Interrupt”. The only way forward is to use STM32CubeProgrammer to erase the chip, then again first debug session starts OK, and I can checkmy app until the SIGINT is faced. Very frustrating. Please not both STM32CubeProgrammer & STM32CubeIDE (1.17.0) works without any issues.
Devices STM3H503CB, STLinkV2 (clone)
- This reply was modified 3 weeks, 3 days ago by Arek.
December 1, 2024 at 08:11 #36198supportKeymasterOK, we have double-checked everything again.
ST appears to have some glitch with their repository. The OpenOCD binary shipped with STM32CubeIDE mentions a git commit that is not listed on Github and appears to support more devices as well. The Github repository shows the last commit in March 2024, but the git log for the same repo dates it as June 2023.
It looks like this has interfered with our release system, so the last batch of commits was not included in our last binary. We have updated it to match them. If it still doesn’t work, you can simply replace the OpenOCD binary under %LOCALAPPDATA%\VisualGDB with the exact version shipped with STM32CubeIDE. It won’t support some secondary improvements like ultra-low-latency Live Watch, but should work fine otherwise.
December 1, 2024 at 09:20 #36199ArekParticipantHi,
I have updated VS to 17.2.2, VisualGDB itself and the aforementioned OpenOCD (STFork). No big difference unfortunatelly.
FYI – the STM32CubeIDE folder tool name is ‘com.st.stm32cube.ide.mcu.externaltools.openocd.win32_2.4.0.202409170845’ vs 20240421 as in yours package.
And this is how the opencd announces itself:
C:\Users\qarkraj>C:\ST\STM32CubeIDE_1.17.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.openocd.win32_2.4.0.202409170845\tools\bin\openocd.exe
Open On-Chip Debugger 0.12.0+dev-00600-g090b431b1 (2024-09-13-19:14) [https://github.com/STMicroelectronics/OpenOCD]One can see see the branch and commit. Apparently hidden on some local server and not propagated to github itself.
When it comes to the binary itself there is a difference in ‘bin’ folder’.
28.11.2024 10:26 <DIR> ..
25.11.2024 23:45 1 112 776 libgcc_s_sjlj-1.dll
25.11.2024 23:45 338 880 libhidapi-0.dll
25.11.2024 23:45 1 169 768 libjaylink-0.dll
25.11.2024 23:45 1 068 712 libusb-1.0.dll
25.11.2024 23:45 540 896 libwinpthread-1.dll
25.11.2024 23:45 5 143 328 openocd.exe
6 File(s) 9 374 360 bytesAfter copying those files, debugging do not start:
C:\Users\qarkraj\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd.st\bin\openocd.exe -c “gdb_port 54354” -c “telnet_port 54352” –set “CHIPNAME STM32H503CBXx” –set “CONNECT_UNDER_RESET 1” -f interface/stlink-dap.cfg -f target/stm32h5x.cfg -c init -c “reset init” -c “echo VisualGDB_OpenOCD_Ready”
Open On-Chip Debugger 0.12.0+dev-00600-g090b431b1 (2024-09-13-19:14) [https://github.com/STMicroelectronics/OpenOCD]
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
C:\Users\qarkraj\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd.st\bin\openocd.exe: unknown option — setRemoving “–set “CHIPNAME $$SYS:MCU_ID$$Xx” helps, debugging is started, however still getting SIGINT errors.
Anyway, this option is added every time I opend the VisualGDB configuration window.
December 1, 2024 at 09:47 #36200supportKeymasterHi,
The –set argument comes from the way VisualGDB handles the device parameters. STM32CubeIDE generates temporary scripts for each project that set some parameters and reference the original script. Our fork instead takes the –set arguments via command line so you won’t need the temporary files. The exact parameters passed via –-set come from the configuration files themselves (see the #SysprogsConfig lines in stm32_common.cfg). VisualGDB parses them, displays them in the GUI, and then passes the selections back to OpenOCD.
You can work around it by either just reusing the generated script from STM32CubeIDE, or removing the “#SysprogsConfig” lines from the .cfg files, and hardcoding them inside your device script.
-
AuthorPosts
- You must be logged in to reply to this topic.