OpenOCD and GDB keep failing randomly during debug sessions

[getreu]

After running the "concurrency" example, the STLink communication gets unstable. The only way to connect is keeping the reset button hold while starting openocd. As soon as I release reset the connection breaks down:

Polling target stm32f3x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 6300ms
Info : Previous state query failed, trying to reconnect  
Error: jtag status contains invalid mode value - communication failure

A similar symptom and its solution is described here:
Error: jtag status contains invalid mode value – communication failure = SOLVED! – Jara's Spare Time Electronics

Finally I found this message in a discussion forum. The problem is in the low-power mode! When CPUcore clock is halted the debugger connection fails and debug session is halted.

I am using low-power mode to halt CPU clock when OS is idle – in vApplicationIdleHook() function I have the __WFI() – wait for interrupt – intrinsic function.

DBGMCU_Config(DBGMCU_SLEEP \| DBGMCU_STOP \| DBGMCU_STANDBY, ENABLE);
-- | --

[getreu]

Workaround:

1. Keep the reset button pressed while connecting with openocd.
2. Build your program in debug mode, sometimes it also helps to comment out the rtfm::wfi(); instruction.
3. In arm-none-eabi-gdb type load and release reset.

I also updated the bootloader, but I did not notice any influence.

[japaric]

Keep the reset button pressed while connecting with openocd.

I think there's an option for this (reset upon connection) on OpenOCD but the RST (?) line of the microcontroller has to be connected to the hardware debugger.

From the linked blog post:

The solution is either to entirely disable low-power modes, or allow low-power debugging in the DBGMCU_CR register:

It might be possible to do this in .gdbinit (using monitor commands to make OpenOCD do the register manipulation) though I'm not sure how portable DBGMCU is.

[getreu]

It would be very useful to find a suitable way to set the DBGMCU register. My above workaround only works when you compile the binary in debug mode. Seeing that the binaries compiled in debug mode are 10-20 times bigger my method is limited to very simple programs.

[getreu]

I discovered that some people experience the same issue with the blue-pill board:
blinky program bricked Blue-pill · Issue #20 · japaric/blue-pill. Surprisingly with this board I can not reproduce the issue.

[bergus]

No description provided.