STM32C011 OpenBootloader

[starivore]

Hello,

I want to use ST's default OpenBootloader that the virgin chips have on board.

The pheripheric I wanted to use is the UART1, and on the AN2606 Application note I saw that the pins I need to use are  PA9/PA10, or to be more precise PA11/PA12 since I'm using the UFQFN20  version. In fact, in the application note is written that: "On WLCSP12, SO8N, TSSOP20, and UFQFN20 packages USART1 PA9/PA10 IOs are
remapped on PA11/PA12."

However these are not the usual pins that I typically use for UART on STM32C011. My firmware also uses UART1 to communicate with an external microcontroller and in that case the pins that the datasheet states I can use are:
USART1_TX: PA0,PC14,PB6;

USART1_RX: PA8, PC14,PB6, PB7;

Why are the pins used in your bootloader not the same as the ones that should in teory be used for USART1? How can I use the same pins for bootloader and user firmware?

I don't want to customize the bootloader as I want to skip the flash programming in production.

Thank you in advance.

Best regards,

Eduard

 

[TDK]

You can use PA9/PA10 which are remapped on PA11/PA12 here to communicate with the bootloader. I don't see what the problem is.

PA9/PA10 are listed as USART1 pins in the datasheet.

[starivore]

Thank you for your quick reply.

The problem is that with my package(UFQFPN20), PA9/10 are not present. As you said they are remapped on pins PA11/PA12, but on the datasheet PA11 and PA12 don't have USART1_TX and USART1_RX as you can see in the following table.

Even STM CubeMX doesn't allow me use PA11/PA12 for USART1.
So that's the source of my doubt. But if you confirm that I can indeed use PA11/PA12 as USART1 then it's perfect.
Regards,

[TDK]

Remapping PA9/PA10 on PA11/PA12 does exactly that--it physically (via a switch) connects the PA9/PA10 pins to the external PA11/PA12 pin positions.

Load up CubeMX and maybe that will help with understanding.

 

[Tesla DeLorean]

>>Why are the pins used in your bootloader not the same as the ones that should in teory be used for USART1?

They want to use the same software on the same die regardless of how it's bonded out to any given package.

You've opted to use the USART1 in a different configuration, but that's a design choice. They don't monitor all pins because that likely ends up creating a design with more gotch / keep-off requirements so things don't conflict with the boot loader case.

If you put your own loader on there, it can make a whole lot of board appropriate choices tailored to your needs. Not sure these super small devices are anticipated to get a lot of user update action.

[Tesla DeLorean]

Unfortunately ST makes a lot of bad and inconsitent choices about how things escape the devices.

The STM32C011 at least has USART2 on the same pins as SWDIO/SWCLK so there are programming and diagnostic options for a header there.