Nucleo F746ZG: How to use USART1 with PA10 and PA9 pins?

[is45]

Hello, I am using an STM32 Nucleo F746ZG board.

I need to make an application where one board can transmit some firmware over to the second board via UART, and the second board will use it's default bootloader to read and flash that firmware.

However, according to documentation I read here: https://www.st.com/resource/en/application_note/an2606-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf, on page 212, it mentions that the bootloader can only use USART1 or USART3. I cannot use USART3, since I am already using that as a VCP for debugging printf messages. Thus, I have to use USART1. However, the problem is that the USART1 pins, PA10 and PA9 pins it requires me to use, are already being used here:

The PA10 pin is being used as USB_OTG_FS_ID, and the PA9 pin is being used as USB_OTG_FS_VBUS. From what I read online, I think these pins are important if I want the STM32 to communicate with my laptop right? If so, then how am I expected to use USART1 to flash firmware when my board is running the default bootloader?

I feel like I am missing something, since the default bootloader would not give USART1 as an option if there wasn't any way to use it.

I would greatly appreciate any help. Thank you!

[KnarfB]

> I think these pins are important if I want the STM32 to communicate with my laptop right?

Sometimes connecting only DP and DN is sufficient, depends on the use case. See  

Introduction to USB hardware and PCB guidelines using STM32 MCUs - Application note

You may adapt the ST provided bootloader middleware to use whatever pins you prefer: STMicroelectronics/stm32-mw-openbl: Provides the Open Bootloader library, part of the STM32Cube MCU Component "middleware", for all STM32xx series.

But this takes extra Flash space and development efforts. Maybe a simpler home grown update protocol is sufficient for you.

Maybe you can use DFU firmware update via that USB connection? 

hth

KnarfB

[Andrew Neil · Accepted solution]

---

@is45 wrote:

I think these pins are important if I want the STM32 to communicate with my laptop right?

---

As the names suggest, those pins are used by the USB function within the STM32F7 chip.

Note that this is entirely separate from the VCP connection via the ST-Link.

If you won't be using the USB function within the STM32F7 chip, then you should be able to use those pins for UART.

Check the board's User Manual and schematics for details ...

---

@is45 wrote:

I cannot use USART3, since I am already using that as a VCP for debugging printf messages. !

---

Could you not switch that to a different U(S)ART?

Or use ITM; eg,

https://community.st.com/t5/stm32-mcus/using-the-itm-console-for-printf-redirects-and-lwip-debug/ta-p/723472

Or, as @KnarfB said, use a custom bootloader - then you can choose any interface on any pins you like

[TDK]

Click on the pin and select Reset State. Then you can assign them to USART1.

[Ozone]

> Check the board's User Manual and schematics for details ...

Exactly.

There are life examples of other ST eval boards that have large electrolytic caps connected to VBUS, and thus are unusable for UART without modifications.

[Andrew Neil]

---

@TDK wrote:

Click on the pin and select Reset State. Then you can assign them to USART1.

---

@is45  But you'd need to check (UM & Schematics) that there's nothing on the board which would obstruct using them as UART pins - eg, as @Ozone said, capacitors ...

[Andrew Neil]

---

@is45 wrote:

I feel like I am missing something, since the default bootloader would not give USART1 as an option if there wasn't any way to use it.

---

You're missing that this is just a result of the design choices made in the Nucleo board - it's not a limitation of the chip itself.

The Nucleo board has an ST-Link built in - so there's little demand to use the UART bootloader.

[is45]

---

---

As the names suggest, those pins are used by the USB function within the STM32F7 chip.

Note that this is entirely separate from the VCP connection via the ST-Link.

If you won't be using the USB function within the STM32F7 chip, then you should be able to use those pins for UART.

---

Ah okay, that's great, I tried using the pins and I am able to communicate using USART1, thanks!

---

---

Could you not switch that to a different U(S)ART?

---

I am pretty sure I need to change some physical connections on the board if I want the ST-Link to connect to another USART instead of USART3, and I don't really want to mess with that.

---

Or use ITM; eg,

---

Hmm, I looked through that, but since USART1 works through those pins I think I'll just stick to using USART3 for debugging for now.

Thanks for the help!

[is45]

Thanks everyone for the help!