OpenOCD reset command

DietWall · ‎2025-12-28

Hello,

I am using a custom environment for development and debugging for NUCLEIO-STM32F767ZI.

It is based on a custom devcontainer, VSCode and gdb-multiarch. On the server side I have OpenOCD, running on a ubuntu 24.04 PC. This is connected via USB to the board. The Board itself is not changed in any way, maybe I changed jumpers at some point, I would need to check this if this might effect the behavior.

The first connection after Powerup works always as expected, the Firmware is flashed and works as expected.

If I rebuild the project or flash the firmware again, the MCU is in some kind of undefined state.

Calls to different HAL functions fail, return Errors. As some return values are not verified within the generated calls, I don´t see the errors immediately, but very late during debugging. Missing interrupts as an example. The code is a simply generated STM32CubeMX project, without any changes. I am using only GPIOs and Systick interrupt so far.

I need the right Reset command for OpenOCD BEFORE or AFTER Firmware flashing.

According OpenOCD documentation, this depends on the board and how STLink is wired to the MCU.

Does anyone has experience on such a setup and have some tipps for the correct Reset command.

And which type of Reset is used inside STM32CubeIDE? Is there a way to retrieve any Logs from GDBServer and GDB inside STM32CubeIDE? If I try to connect STM32CubeIDE to OpenOCD, it fails with something like: This is not a STM32 Chip.

If I plug the board into my Windows PC, everything works as expected. But I want to use my Ubuntu PC for debugging and Development.

I tried to use

monitor reset halt

before Flashing the firmware, The result is as described above

Manually typing:

monitor reset init

shows also the same, The chip restarts with initialization, but the errors are still there.

Inside OpenOCD are also commands like:

monitor soft_reset_halt

But they are refused by openocd with:

[stm32f7x.cpu] requesting target halt and executing a soft reset

Target stm32f7x.cpu does not support soft_reset_halt

I do not have further configuration in OpenOCD beside the delivered scripts for initialization. My openocd startup arguments look like this:

-f /usr/share/openocd/scripts/interface/stlink.cfg -f /usr/share/openocd/scripts/target/stm32f7x.cfg -f /home/<user>/openocd.cfg.

openocd.cfg contains only: bindto 0.0.0.0

I know, that there are STM32 Extensions for VSCode, But in the Videos I saw, they used a direct USB connection.

I want OpenOCD to be available on my network.

Thanks in Advance and Best Regards.

Dietrich

DietWall · ‎2025-12-30

Found it,

I have been using the wrong linker script.

For some reason, STMCubeMX generated 2 linker scripts: <device>_FLASH.ld and <device>_RAM.ld.

What I did, was just to copy both linker scripts into my build environment and writing this into my cmake files:

target_link_options(${PROJECT_NAME}
    PUBLIC "-TSTM32F767ZITX_FLASH.ld"
    PUBLIC "-TSTM32F767ZITX_RAM.ld"
    PUBLIC "-Wl,-Map=${PROJECT_NAME}.map"       
    #export map after linking, still required for debugging
)

There were some warnings at the beginning of development, because some sections were defined twice. So instead of really taking care of this warning, I just commented the second definition in RAM.ld out. (I guess gcc takes the second linker script, if 2 are given?)

Because of that, the variable _sidata (I guess an abbreviaton for: Statically Initialized DATA) in the startup_<device>.s file was not properly linked.

So therefore the underlying array had a length of 0, and no data was copied from FLASH to RAM.

The linking command from CubeIDE includes only the flash linker script.

My Linux OpenOCD works actually good enough now without any changes. But I am still wondering why it has been working sometimes...

View solution in original post

DietWall · ‎2025-12-28

I would also appreciate any type of documentation for the board, stlink or its connection to stm32f7.

I am still not used to ST documents. But this is not related to the documentatton itself.

Version information:

openocd --version
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html

gdb-multiarch --version
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

TDK · ‎2025-12-28

Board documentation is on the product page:

NUCLEO-F767ZI | Product - STMicroelectronics

In particular, the User Manual and the Schematic are there and are usually helpful.

If you feel a post has answered your question, please click "Accept as Solution".

DietWall · ‎2025-12-28

thank you for the reference.

After checking some documentation, I could read out the RCC_CSR Register, verify and see if there is a difference between openocd and STM32CubeIDE. And also if there is a difference between a cold start and a re-flashing procedure in openocd.

Additionally, I think that clock or Systick configurations might also provide some useful information.

The biggest issue right now is a return HAL_ERROR here:

https://github.com/STMicroelectronics/stm32f7xx-hal-driver/blob/e1446fa12ffda80ea1016faf349e45b2047fff12/Src/stm32f7xx_hal.c#L236

The return value is not checked in HAL_INIT(), so therefore this condition is not easy to catch yet.

Just a side question:

What means MSP in STM32F7HAL like in:

/* Init the low level hardware */

HAL_MspInit();

The function is completely empty.

TDK · ‎2025-12-28

The only reason that should fail is if this gets caught:

STM32CubeF7/Drivers/CMSIS/Core/Include/core_cm7.h at 4d308aa04f6a5fff988126e5124ffcf597639647 · STMicroelectronics/STM32CubeF7

Which would indicate a serious issue with the project configuration and how it was created. Step through. Is that where it fails?

Try creating a new project in STM32CubeMX and compiling. Does that work? If so, start from there.

If you feel a post has answered your question, please click "Accept as Solution".

Pavel A. · ‎2025-12-28

Hi,

There's a request to provide updated source of the ST branch of OpenOCD:

https://community.st.com/t5/stm32cubeide-mcus/how-can-i-obtain-the-latest-source-code-for-openocd-that-comes/td-p/862800

If granted, this should help with debugging STM32s on various platforms.

> What means MSP in STM32F7HAL

It means "MCU support package" or something like that. There is one "global" HAL_MspInit() and a MspInit for each kind of "peripheral" which is called from specific "peripheral" init functions. It does stuff like pin configuration. This layer should be also enabling "peripheral" instances, set up power and clock sources per instance, but all that got mixed up in the current Cube and HAL library, so don't take it too seriously. Just look at the provided source - it is what it is.

DietWall · ‎2025-12-28

you´re right, it fails exactly there.

ticks has the value of: 392350558

Ticks calculation depends on this declaration:

uint32_t SystemCoreClock = 16000000;

And its value at failure is: 1 177 051 676

The second variable for the calculation:

uwTickFreq is at 254

So I guess the clock initialization is wrong on the second debugging session.

I have still the feeling that the reset sequence is not the right one. It works as long as I am not connected (I can see the LEDs blinking) and on the very first GDB connection. If I disconnect and reconnect again, it starts to fail.

Maybe there is an additional sleep required to settle some of the clocks? Or an additional signal from STLink to reset some clocks circuit?

The generation was based on the Board (Nucleo-STM32F767ZI) in STM32CubeMX and I am pretty sure I did no changes beside of activating USART3. I don´t think there is much to mess up here? The only change inside the generated code was to deactivate USART3 init functions.

Pavel A. · ‎2025-12-28

Does this error [after warm reset] occur without debugger, or you state that the debugger causes it?

DietWall · ‎2025-12-28

Its just the declaration with 16MHz.

The variable changes during runtime. It has the value of 1177051676 if it fails

1 177 051 676 / (1000 / 254) = 1 177 051 676 /3 = 392.350.558 = 0x1762CB5E

Maybe it is some kind of linking error? The value is 1177051676 on main entry point:

From my understanding of the C Language it should be initialized to 16 MHz during startup, something around here:

https://github.com/STMicroelectronics/cmsis-device-f7/blob/2352e888e821aa0f4fe549bd5ea81d29c67a3222/Source/Templates/gcc/startup_stm32f767xx.s#L98

and should have 16MHz at main entry point, the way it is declared.

DietWall · ‎2025-12-28

I did not do any warm resets without debugger yet. If I am not debugging on it, the board is just connected to the usb port. So I would have to test it.