Skip to main content
L
linards-ee
Visitor II
February 13, 2025
Solved

STM32G431 unable to enter bootloader mode

  • February 13, 2025
  • 2 replies
  • 940 views

I have a custom PCB with the STM32G431 microcontroller and ESP32 controller. ESP32 is connected to STM via GPIO pins in order to perform firmware upgrade using STM32 bootloader protocol. Connection are as follows:

ESP32 UART TX <-----> STM32 UART RX (PC11)

ESP32 UART RX <-----> STM32 UART TX (PC10)

ESP32 GPIO <-----> STM32 RESET pin

ESP32 GPIO <-----> STM32 BOOT0 pin

 

ESP32 controller triggers the STM32 bootloader entering sequence using RESET, BOOT0 pins and sending start byte 0x7F. The problem is that with STM32G431 the ESP32 does not receive ACK (nor anything else). When I soldered STM32G474 on that PCB, everything worked fine (ESP got the ACK and was able to execute bootloader commands).

 

I checked AN2606 and AN3155 to interface bootloader communication. For me it seemed that both microcontrollers (STM32G474 and STM32G431) are compatible to communicate with bootloader, unfortunately they are not. I triple checked both MCU Option bytes and pinouts, and it seemed to be okay.

 

Please, help me to solve this issue with STM32G431.

    This topic has been closed for replies.
    Best answer by linards-ee

    Seems I have found a solution.

    I tried to read more bytes during ACK reception. It turns out that the ACK were "hidden" in the next bytes. The first bytes were garbage. Also, there is no exact number of bytes to check, just read unitl get ACK. Very strange that STM32G474 ACK was a single byte and always the first one.

    2 replies

    U
    Uwe Bonnes
    Graduate II
    February 13, 2025

    Make sure that no other UARTx_RX pin toggles during startup!

    L
    linards-eeAuthor
    Visitor II
    February 13, 2025

    Thanks for reply,

    Double checked other UART RX pins and they are not toggling. Also, as I mentioned before, STM32G474 worked as expected. Any other ideas?

    L
    linards-eeAuthorAnswer
    Visitor II
    February 13, 2025

    Seems I have found a solution.

    I tried to read more bytes during ACK reception. It turns out that the ACK were "hidden" in the next bytes. The first bytes were garbage. Also, there is no exact number of bytes to check, just read unitl get ACK. Very strange that STM32G474 ACK was a single byte and always the first one.

    Terms & ConditionsAccessibility statement