cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H743 system bootloader does not work by USART2

I would like to download code from Raspberry Pi to NUCLEO-H743ZI2 board. On RPi, I use STM32flash app and 2 GPIOs for NUCLEO's NRST & BOOT0. STM32flash generates the signals properly (I see that current STM32 application does not start) and I acquires 0x7F byte by scope on USART2 RXD (PA3) pin of NUCLEO as stated in AN3155 & AN2606 but there is no response on TXD (PA2).

What is really weird: red LED on NUCLEO (at GPIO PB14) is turned on after boot setting. Does the bootloader indicate something by a GPIO? It might interfere with HW on a user board.

The reason why I did not use USART1 is that their pins are not free.

Thanks for any opinion.

8 REPLIES 8
TDK
Guru

Does the nucleo have a USB cable plugged in? The bootloader will detect this and jump to the USB DFU booloader and stop listening to the UART peripheral.

If you feel a post has answered your question, please click "Accept as Solution".

Thanks for an immediate answer.

Neither direct USB nor ST-Link cable is connected.

I confirm that by a manual boot setting (wire from +3V3 to BOOT0 and pressing RESET button) the red LED (PB14) is switched on - but I understand now: PB14 is also the second alteration of USART1 TXD pin so the bootloader sets it to output high as TXD idle level. But there is no reason for not working USART2 or USART1 that seems also not working.

I also see the high level on TXD2 so the bootloader sets the GPIO as TXD output properly.

I found a note in AN2606 that USART2 is not working in the bootloader.

I tried USART1 (besides default 57600 Bd also with 9600 Bd) but unfortunatelly it is also not working.

Useless bootloader.

SF??r
Associate III

The STM32H7 bootloader has major problems... we have a ongoing unanswered bug ticket at st....

Better stop using them...

FColl.1
Associate III

@Community member​ That is very interesting to us. We just found that note in the AN2606 doc. Our system works with the bootloader on a STM32H743 RevY chip running bootloader V13.2 (confirmed using STLINK). So that contradicts the AN2606. We are trying to get it working with STM32H743 RevV chip running bootloader V9.0 and it does not work.

Watch for other pins supported by the boot loader having noise/traffic on them at startup.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Thanks for that quick reply. Yes, I'm going to go through them all with the scope. The other pins should all be the same as our old board. I guess the 0x90 bootloader is not just an incremental change but a complete rewrite, hence the strange version number.

The idea of enabling several different ports and polling them in a loop for a handshake is a terrible design, what were they thinking?!

Is there any documentation on the bootloader internals or a decompiled code? For example does it do glitch rejection on the USART speed detection or just sample the first toggle that it sees?