[reset] Unable to reset board in gdb

[dflogeras]

I am using ChibiOS-2.6.5 and attempting to integrate the CMSIS library for DSP functionality.

My board is a STM32F407-Discovery and my toolchain was generated using Gentoo's crossdev package, with the following:
gcc-4.7.3 (compiled arm-hardfloat-eabi)
binutils-2.23.2
newlib-2.0.0
gdb-7.6.2

So far, the process of compile, flash, debug, repeat has worked great on this, as well as another project using a STM32L151 chip.

After adding linking the CMSIS library into my project, I have found that I cannot debug reliably. If I attach to the gdb server, it will often be in the ChibiOS unhandled_exception() handler, or maybe __gnu_unwind_execute(), I assume after hitting an exception condition.

Oddly though, I cannot reset the board in gdb with kill/run. Doing so ends up right where it was before, even with a breakpoint in the ResetHandler() function. Even pressing the reset button on the devkit doesn't reset it. I have to use 'load' with gdb, sometimes pressing the reset button while loading the firmware before it works fully.

I am wondering if this is a known issue, and if there is anything I can do to debug or work around it?

[xor-gate]

Please test against v1.2.0 or master and report if the problem still exists.

[dflogeras]

I can reliably debug with my current toolchain and stlink on a STM32F4 CMSIS project. Unfortunately I cannot easily go back to the toolchain I had 2 years ago, but I doubt it has much value.

I did notice while testing that doing a kill/run in gdb would produce:

Starting program: /home/dave/ChibiOS_3.0.5/stm32f4_test/build/ch.elf 
inferior.c:361: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

I found that I can:

a. Instead of kill/run, I can kill, then "target remote :4242" to re-attach and it is waiting for me in ResetHandler()
b. Upgrade gdb from 7.10.1 to 7.11 and the issue seems to go away

Is this expected?

[xor-gate]

Thank you for testing, that is a good answer. I have currently no clue what is expected (by others) and why it is solved by using gdb 7.11. I have seen similar problems when running under ChibiOS RTOS also under OpenOCD. This needs more investigation by others who may or may not reproduce the problem.

[rewolff]

To me: "even pressing the reset button doesn't reset it" is a red flag. The hardware reset should always work.

What possibly might not be working is that the debugger catches the processor as it comes out of reset. In that case Chibios will be crashed in "unhandled exception" before you get to move your finger from the reset button to your keyboard.

[xor-gate]

You are right, I have no clue how OpenOCD handles this nicely. Again the gdb-stubs in stlink are in a very bad shape currently (as you know yourself).

[Ant-ON]

@Nightwalker-87
I think it can be closed by #1071
The problem is most likely due to the reset pin not being connected. In older versions of the st-util, the reset through the SWD was not implemented

[Nightwalker-87]

The observed behaviour obviously derived from the following issues:

• Bug in the external debugging tool gdb 7.10.1 which appears to have been fixed in v7.11.
• Missing ability for a software reset via the SWD interface that was not present before Reset through AIRCR (#540) #712.
• Further improvements for the software-based reset functionality have been added in [feature] Extended support for STM32H7 & rework of software reset #1071.

With this conclusion based on a final review of the related topic we can safely close this ticket as resolved.