How to hard reset STM32 devices from gdb?

[Renegade85]

Hello guys,

recently I've switched to Linux and I downloaded the st-util (which is great btw.) to be able to flash/erase/debug my ST boards. Everything works perfectly expect of resetting the board.

I've created a simple blinking LED project.
Compiled the project including debugging information.
Loaded the firmware into the board and LED was blinking.

I wanted to try out the debugger, so I connected to the board using gdb. The code was running, LED blinking, but I wanted to restart my board to start my debugging session again.

According to instructions from the texane/stlink project I've directed gdb following way:

• target extended-remote localhost:4242
• it asked me to kill the session as it is running, so I've done so
• I've entered next and I saw the session starts from the beggining...

However, the LED was still on. I realized, the reset was performed, but it appears to me it's not a hard reset, where the whole MCU gets restarted (all registers are set to default etc.), but it's some sort of soft reset (a jump to start only?).

I've checked the content of the registers and they really stayed set!

So I tried to perform a hw reset pressing the reset button on the discovery board and everything worked perfectly!

As I'm not very familiar with all the gnu tools, I'm not sure whether this is an issue of gdb, or st-util or so. Is this a feature or a bug? Do I need to perform a manual reset to really reset the device, or is there some gdb reset command to do so or this is not supported at the moment?

Thank you very much for help,
Renegade

• Operating system: Fedora 24
• Stlink tools version and/or git commit hash: v1.2.0-147-g3de5cf0
• Target chip (and optional board): e.g STM32F407VG (STM32F4-Discovery)

PS: I was trying to find out whether this has been discussed already and I found few information, but it appears to me none of them were related to the issue I have observed.
Also it's possible that I'm just doing something wrong in the compile/flash/debug process, but at the moment I've a feeling everything is done properly from my side.

[xor-gate]

You are right about this one, the current reset behaviour is not well-defined. Probably st-util is missing the kill/reset sequence from gdb.

[Renegade85]

Not sure I understand you properly. So you are saying that after gdb sends the kill command to the st-link via st-util, st-util transfers the command improperly to the MCU? So instead of putting it into a reset state, it only stops execution and sets the PC to 0x0 or so?

Also I've noticed while connecting to the board with st-util (LED blinking), the LED froze (it was on). So it appears the server connects to the st-link, but instead of putting it into reset it only stops execution. Unfortunately I don't have a scope to confirm this 100%, but I think if the NRST pin would be low, the LED would be off...

Renegade

PS: What would be a solution? Maybe I can take a look on this in my free time.. but I'm not very familiar with the whole concept of GDB server and also I don't know the st-link commands etc., but if able, I could help a bit...

Thank you,
Renegade

[xor-gate]

Sorry for my late reply, I'm also not 100% familiar with the control between gdb and st-util (gdb-server). There are many issues around (mostly about st-flash) which have "unexpected" reset behaviour. There are 3 types of resets as I know:

• JTAG/SWD programming core reset
• Reset line assertion (CPU n_reset pin)
• Writing SYSREQRESET bit to the CONTROL register (software reset)

And during this writing I found something interessting in the ARM docs:
Cortex-M3 reset modes

[Nightwalker-87]

Feedback by @xor-gate appears to have been a sufficient response to this issue, which is now finally closed.