Update to latest OpenOCD (ST Fork)

Sysprogs forums Forums VisualGDB Update to latest OpenOCD (ST Fork)

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #36023
    MrZANE
    Participant

    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.
    #36025
    support
    Keymaster

    Hi,

    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.

    #36026
    MrZANE
    Participant

    Yeha, 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?

    #36027
    support
    Keymaster

    Our 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.

    #36163
    Arek
    Participant

    I 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?

    #36164
    Arek
    Participant
    #36166
    support
    Keymaster

    Hi,

    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.

    #36196
    Arek
    Participant

    Hi,

    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.
    #36198
    support
    Keymaster

    OK, 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.

    #36199
    Arek
    Participant

    Hi,

    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 bytes

    After 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 — set

    Removing “–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.

    #36200
    support
    Keymaster

    Hi,

    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.

Viewing 11 posts - 1 through 11 (of 11 total)
  • You must be logged in to reply to this topic.