2025-04-26 9:43 AM
Hello everyone, I have a problem with the bootloader of the stm32h503 microcontroller. I can't get a response from the stm32 via any of the UART interfaces. I tried different baud rates (9600,57600,115200) but I don't get an ACK from the STM32H503 in response to 0x7F via any of them.
The BOOT0 pin is set to a logical one, and then the microcontroller is reset using the nRST pin. I tried re-soldering the H503 to a new one, but there is no difference. The F103 responds perfectly to the same requests and correctly displays the CHIP ID with the same adapter and connection.
USART1 on the H503 is working properly, since it is used to transfer data between the 503 and the ESP32.
Please tell me what the problem could be and how to solve it?
I am attaching a screenshot from a logic analyzer, the first signal is pin BOOT0, the second is RESET, the third and fourth are USART
Solved! Go to Solution.
2025-04-27 8:18 AM
The pins supported by the System Loader, per AN2606, are a hard commitment. Generally it's limited so as not to create a whole lot of potential conflicts.
So no it's not going remap pins.
What you can do is have your own minimal loader, that uses a protocol of your choosing, like X/Y-Modem, per the IAP examples. You can restart that and interact with it. But you're going to have to push this on initially via SWD, would take several KB, and perhaps permit security and integrity also.
If you need the ESP32 to program a blank device, you're going to have to switch your pin usage in the design.
2025-04-26 10:51 AM
Are you using pins supported by the bootloader as outlined in AN2606? Which ones?
Try waiting longer between NRST high and sending 0x7F.
2025-04-26 6:09 PM - edited 2025-04-26 6:12 PM
Does it work with SWD/JTAG ?
Show your FULL wiring, or schematic around the H503 ?
It won't work if the part isn't viable. So look at power supply connections, main supply, analogue.
Check state of NRST pin
Check voltage on VCAP pins is present
Check other pins described in AN2606 as possible noise sources, Especially UART RX inputs like GPS/GNSS that might chirp at start-up. The detection methods in the System Loader are one-shot, so if it's picking up noise you'll have to reset and start-over. You need to suppress other noise sources.
It might take a while for the System Loader to start completely, ie bring up clocks and PLL. Give it several hundred milliseconds
The 0x7F pattern is at 8E1, a TIM is being used to measure the pattern as a means to auto-baud
2025-04-26 9:34 PM
Thanks for the reply, looks like you are right about Rx Tx pins.
I tried to create a demo board based on bluepill, soldering H503 and connecting a 2.2 microfarad capacitor to both VCAPs.
I was able to get an ACK in response to 0x7F, on pins PA9 PA10, but in my project USART1 is reassigned to pins PB6 PB7. In bootloader mode, H503 seems to listen only to the main pins PA9 PA10. Is it possible to switch the bootloader to listen to pins PB6 PB7? Thank you!
2025-04-27 8:18 AM
The pins supported by the System Loader, per AN2606, are a hard commitment. Generally it's limited so as not to create a whole lot of potential conflicts.
So no it's not going remap pins.
What you can do is have your own minimal loader, that uses a protocol of your choosing, like X/Y-Modem, per the IAP examples. You can restart that and interact with it. But you're going to have to push this on initially via SWD, would take several KB, and perhaps permit security and integrity also.
If you need the ESP32 to program a blank device, you're going to have to switch your pin usage in the design.
2025-04-27 5:41 PM
It's not possible to change the pins supported by the bootloader, they are hardcoded.
You'll have to make your own bootloader, or respin the board, or find some other solution.
2025-04-27 10:02 PM
Thank you so much, friends :) I will try to connect with X\Y modem, i think its good solution for me, cause i have ordered 150 pcb's alredy and can not change the hardware pins