STM32F405 bootloader not responding in some boards

[julio_cf]

I'm testing a batch of 7 boards with an STM32F405RGT6. I'm trying to access the factory bootloader using an ESP32, which sets the boot0 pin to HIGH and RST to LOW and then sends the character 0x7F at 9600 bauds 8E1 (using pins PA09 and PA10). The procedure is successful for 4 out of 7 boards, as the STM32 effectively responds with ACK (0x79), and subsequent commands like Get are successfully tested. However, I'm encountering issues accessing the bootloader on the other 3 boards. This problem seems persistent as it consistently fails or succeeds with the same boards (they are identified). All these tested boards have the same hardware and are soldered with PCB assembly. All boards were tested with the same ESP32, since the board has pin headers for it.

Here's what I've tried so far:

• Verified board hardware: Checked visually for any damaged or poorly soldered components on the three problematic boards compared to the ones working correctly.
• Enter the bootloader 'manually': Using buttons to activate boot0 and RST and Realterm to send 0x7f with a USB-UART converter. I tested both a 'good' and a 'bad' board. Same result, only the 'good' one responded with ACK; the other one simply didn't respond.
• Tested with different baud rates: Although I'm currently using a baud rate of 9600, I've tried other speeds like 115200 to see if it makes any difference on the problematic boards.
• I also read this: https://community.st.com/t5/stm32-mcus-embedded-software/stm32f405rgt6-fails-to-enter-bootloader-sometimes/m-p/126995/ but it doesn't seem to be the problem.

[waclawek.jan]

Are there signals on other bootloader pins? 

Can you program the STM32 in  other way (SWD)?

JW

[Tesla DeLorean]

Signal noise, on these pins or others the MCU might be listening on? See AN2606

The response to the 0x7F pattern is a one-shot deal, it's used by a TIM input to compute a baud rate.

Make sure the pin is high or pulled up high at start-up.

Reset, send the pattern, if no response you need to rinse-and-repeat.

[julio_cf]

All the other pins that may be used for the bootloader according to AN2606 (i.e., PB11, PB10, PC11, PC10, PB5, PB13, PB6, PB7, PA8, PC9, PA7, PA6, PA5, PA4, PA11, PA12) are floating, at least for these tests, since I have not yet soldered the other (optional) components.

@waclawek.jan  Yes, actually I can program the chip through SWD without problems. In fact, I verified that all of them show 0x91 as the bootloader version.

@Tesla DeLoreanThe procedure to enter the bootloader using ESP actually runs inside a loop, so many attempts are made. However, the 'good' boards succeed on the first try.

//This runs inside a loop
if(!bootloader_ok){
 digitalWrite(STM_BOOT0_PIN, HIGH); //BOOT0
 vTaskDelay(50);

 digitalWrite(STM_RST_PIN, HIGH); //Reset pulse
 vTaskDelay(200);
 digitalWrite(STM_RST_PIN, LOW);
 
 //This function sends 0x7F, waits 1 second, and repeats 5 times
 bootloader_ok = stm32_enterBootloader();
}

 

[waclawek.jan]

Write a simple "blinky" (toggle a pin) for the STM32 and observe, whether the "blinking" stops when you attempt to enter the bootloader.

Write a simple software which mimics the bootloader, i.e. with clock set to HSI, sets up UART at the expected baudrate, receives a byte and transmits the expected answer if it's 0x7F (and blink a LED if it is not - this is to find some potential problem with interconnections); test this with the same program in ESP you use for bootloading but modified so that it does not set the BOOT0 pin high.

> //This function sends 0x7F, waits 1 second, and repeats 5 times

You need to have some delay after the reset pulse, before sending 0x7F. See USART connection timing chapter in AN2606. Note, that those numbers are measured with some particular hardware setup, mind that you have a quite long RC on the NRST pin.

JW