ST-Link burns the microcontroler while debuging (Solved)

[Diego B.]

I'm working on a custom circuit based on STM32 mcu. I can connect the controller and read the memory on ST-LINK utility; then I open atollic, generate a basic code with CubeMX and try to debug.

Atollic is able to connect the MCU but, as soon as I click "start" debuging, it takes less than 1s to lose the connection and after that I can't connect with the controller anymore. No even with the ST-Link utillity.

In the circuit there is nothing else than the MCU and the decoupling caps. The current is around 6mA so I want to believe that the controller is still alive. I've changed the device 3 times and, tried two different boards. Every time I had the same response.

I was working with this circuit for one month (programming and debuging) and it worked fine. Then suddenly this problem showed up and I don't know what to do...

Is there any hardware feature in the STM32 familly which may, somehow, block the processor preventing the debug? also I have the Boot pin unconnected, I don't know how important is to ground this pin during the debugh process.

Thanks

Diego B

[Tesla DeLorean]

Ok the BOOT0 pin tends to be critical, as it determines who's code runs, yours or the ROM. If your power supply ramps slowly a floating BOOT0 might be interpreted as being relatively HIGH, the core can become sentient at about 1.2V

The debugger can change the address it wants to execute code at.

If you put the core into low power mode the JTAG interface shuts down (powers off), you will consequently lose connection to it.

If the ST-LINK can connect with BOOT0 pulled HIGH, something in YOUR code is causing the issue. Normally you should pull BOOT0 LOW

I would guess a WFI instruction, so grep the source for WFI or __WFI or things like STOPMODE or SLEEPMODE

[Diego B.]

So I managed to make it work by doing a "full chip erase" with ST link Utility.

• Startup ST Utility
• Press the Reset button and keep it pressed
• Select Erase Chip (in Target menu)
• Release the Reset button
• The chip is erased

I found the solution here: https://electronics.stackexchange.com/questions/357613/error-when-using-debugging-under-atollic-truestudio-stm32/426612#426612

All the problem came up when I reinstalled Atollic and CubeMX, but finally it seems to work fine again.

What I don't really understand is what happened with the controller? why it got stuck and it didn't work until I full erased it?

[Tesla DeLorean]

If BOOT0 isn't pulled down you're going to have failures in the field.

[Diego B.]

I'm aware of that. It's in my "to do" list, but at least now I can carry on with the firmware development and debug. I'll short that pin to ground asap.

Thank you for your answers!