UART bootloader

[Alex_7777]

Hello!

I'm utilizing the STM32L476VCT6 in my project. Through the UART (PC4, PC5), this MCU interfaces with the Wi-Fi SoC. For firmware updates, I want to use this UART connectivity. But I notice that USART3 bootloader has dedicated PC10, PC11 pins. Could I use these PC4 and PC5 somehow? 

[Issamos]

Hello @Alex_7777 

Bootloader have specific TX and RX pins. So you can't use other pins to do the same work. I suggest you to plug your WiFi soc to PC10 et PC11.

best regards.

II

[waclawek.jan]

Instead of using the built-in bootloader, you can write your own, using the pins you have at hand. You would need to program this bootloader once, at manufacturing time, using SWD or any other means.

JW

[Tesla DeLorean]

The AN2606 defines the usable pins, and those which you should avoid creating noise on. Say a GPS receiver chirping at startup. The options here are not flexible.

With your own loader instance you can do whatever you want with regard to peripherals and pins, and to support external interfaces and methods well beyond the scope of the ROM based loader. This can allow for more standard protocols and a simpler user interface, and integration with your own Windows, etc, apps facing the end-users.

You'd partition the available FLASH to accommodate a loader/recovery app, and your primary app. Typically just update the primary app, and have authentication or validation to determine if it is all present and correct before transferring control. The loader can do a lot of the memory, pin and clock initialization once, removing the need for the app to do this again.

[SofLit · Accepted solution]

Hello,

You can use USART3 (PC10, PC11) in bootloader then when you jump to your application you can use another pins where USART3 is available like (PC4, PC5). I don't see any constraint. 

[Tesla DeLorean]

Correct, secondary and different mappings could keep the USART in play. Tends to be more of an issue with the CM0(+) where such resources are low, and mapping options reduced.

The real gotcha with the ROM loader is that it can recognize signals that might occur in a normal system. One other trick there is to swap the RX/TX usage on UARTs you don't want the ROM loader seeing/probing.