STM32FG031 once pin 4 (PF0 - NRST) is set as GPIO input, it is not possible to reprogram the MCU flash. How to recover ?

[Frabs]

Working with a STM32G0316-DISCO, I was so stupid I wrote a test program where I set pin 4 (NRST) as GPIO input (PA0). It goes without saying that now I'm not able to reprogram che MCU. Is there any magic trick to get out of this situation aside buying another Discovery board.

[Nikita91]

Perhaps :

BOOT0 pin high on power on to put the MCU in bootloader mode,

use STM32Cube Programmer to do a mass erase through UART.

[Frabs]

Thanks Nikita91, I just tried it but without success.

I put pin 8 (BOOT0) to VDD, connected pin 5 Tx and 6 Rx to my PC through a FTDI usb to serial cable (COM15).

On STM32Cube Programmer I selected the UART PORT (COM15) then I power up the mcu and activate CONNECT but I get the following message :

Error : Activating device : KO. Please verify boot... (etc etc).

As soon as I power up the mcu it executes the resident firmware previously flashed regardless of BOOT0 status.

Unless I've done something wrong, it's not working. So I'm still stuck with a blocked mcu. Guess I'm going to buy another DISCO.

Again thanks for your fast support.

[Andreas Bolsch]

Setting BOOT0 pin to high might not work - this depends on the option bytes ... As you touched the NRST settings, chances are high you did touch the nBOOTx settings as well?

As long as your program doesn't change alternate function for PA13 and PA14, debugger access via SWD should still work without problem. However, if it does, it becomes a bit delicate. There is still a chance to halt the CPU via SWD interface right after internal reset release (i.e. before the program reassigns PA13 and PA14) after power on, but timing it quite critical and it probably won't work on every attempt. The SWD activation sequence etc. and the halt command would have to be sent immediately after reset release at high speed. With stock debugger/software: no chance. Anyway, interesting experiment ...

[Frabs]

Hi Andreas,

The micro setup was done by means of STM32CubeMX, so I guess nBOOTx may have been messed up.

I think that the situation is unrecoverable.

But what you wrote confirm an idea of mine I want to experiment with : should I need to reassign functional pins such as BOOT0 and SWD, a half second delay could be added before hw setup of the mcu. This amount of time could allow an external device to take control of the mcu for erasing/programming.

This provided the delay does not interfere with the mcu activity.

I'm going to buy another STM32G0316-DISCO and an handfull of STM32G031J6 to sacrifice on the altar of "interesting experimenting" 😂 .

Thanks for your support.

[Andreas Bolsch]

Right, this delay is exactly what ST proposes for the STM8L001J3 when reset pin is reassigned ... Similar problem.

[Frabs]

👍