STM32H5 bootloader uses USART pins that do not match roles in datasheet

[MBC]

STM32H5763IIK, Bootloader v14

I'm planning on using USART1 and USART3 in my application. I'd like to be able to access the bootloader from both. The bootloader documents say that USART2 and USART3 at very least use pins that are not attached to their respective modules.

On the chip, USART1 can be:

TX PA9, PB6, PB14
RX PA10, PB7, PB15
The bootloader note AN2606 says the H5763 USART1 uses: A9/A10 which are valid options! No issue.

For USART3 the chip can operate on:
TX PB10, PC10, PD8
RX PB11, PC11, PC4, PD9
AN2606 says USART3 can use: None of those pairs... uses PD9 ok, but also PA4 which isn't associated to UART3 at all.

Applies to USART2 as well.

• I've checked all of the alternate function lists and verified at least CAN and USB have seemingly correct line ups. Didn't look at SPI or I(2/3)C.
  
  
• The only way I think this can happen is if the bootloader's code defines and uses software UART TX. Where at least the TX pins aren't driven by hardware but bit-banging out their signals. I can not imagine why this would be the case, some peripherals use the correct pins, and others do not, for software reasons?
  
  

• As a workaround USART2, I could use RX PA3 / TX PA2 and PA5 so that when the bootloader is running it uses PA5, but in the application I use hardware an PA2. Uses an extra pin only for bootloader, and that's fine so long as I know this limitation / configuration is real.
  
  
• I would be less surprised if the list of bootloader pins was just incorrect.

I need someone from ST to confirm that AN2602 (Page 250) matches up with reality.

AN2602: https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf

Datasheet: https://www.st.com/resource/en/datasheet/stm32h563ii.pdf

[TDK]

Almost certainly an error in AN2606, unlikely to be a software-based USART. Probably copy/pasted the H7 tables and didn't update them appropriately.

If you can boot into the bootloader, you can debug and look at GPIOx registers to see the configuration.

[MBC]

Yea, it doesn't look right to me. But it's also not impossible to use software peripheral or they have some access they don't disclose maybe because of TrustZone being able to access peripherals differently. IDK.

I do not have access to an H5 unfortunately. It would also be a bit of setup to get there, as none of the peripherals are set up for transmit until they detect a valid signal on their receive lines.

[Foued_KH]

Hello @MBC , 

I confirm this issue in the AN2606.
I will report that internally.

Thank you!
Foued

[MBC]

Ok, well good to know.

Now I need the correct bootloader pins for USART and CAN on this series chip. I don't quite have enough information to complete this layout yet, and I need to be at least closer in order to go to purchasing for an order of chips.

[Tesla DeLorean]

If you know this is the part, and you're just finishing up the layout, might suggest you get the order on the books. The lead time is at least 15 weeks

[Foued_KH]

Could you please open a new thread and you can ask for USART and CAN bootloader pins.
Thank you!

Foued

[Tesla DeLorean]

Not clear why related issues can't be addressed in a single thread. Just need solid and definitive answers..

New Thread https://community.st.com/t5/stm32-mcus-products/stm32h5-need-bootloader-pins/td-p/595584

[Foued_KH]

I confirm the issue and I reported internally.

Internal ticket number: 162709  (This is an internal tracking number and is not accessible or usable by customers).

Foued

[Foued_KH]

Hello @Tesla DeLorean , 

Each thread in the community must contain only a content
So if there is another question or issue it must be asked in another thread.

Thank you for your comprehension!
Foued