Bootload feature for stm32C013

[zin10]

Product: SMT32C013
Issue: firmware download in bootmode

Details: 

I’ve recently started firmware development and, with community help, I’ve managed to create firmware for STM8 and several STM32 devices. Until now, I’ve always programmed the MCU using ST-Link—either by debugging or by drag-and-dropping the binary file.

Due to new system design requirements, I’d like to create a GUI tool to download firmware using the built-in bootloader. According to AN2606 and the MCU datasheet (STM32C013 series), the bootloader supports two interfaces:

• USART1 on PA9/PA10

• I²C on PB6/PB7

Here are my questions:

1. If PA9/PA10 and PB6/PB7 are already allocated to GPIOs for LEDs, buttons, or other connectivity, can they still be used for bootloading? Or does their existing allocation block firmware download?

2. If those pins are unavailable, are there any alternative methods to download firmware via bootloader (besides ST-Link)?

3. What is In-Application Programming (IAP) bootloading approach? 
   
4. Bootloading Pattern: details below

The documentation also refers to Pattern 11 for bootloader activation, listing conditions like:

• BOOT_LOCK(bit) = 0, nBoot1(bit) = 1, nBOOT0_SEL(bit) = 1, nBoot0(bit) = 0

• BOOT_LOCK(bit) = 0, nBoot1(bit) = 1, Boot0(pin) = 1, nBOOT0_SEL(bit) = 0

• BOOT_LOCK(bit) = 0, nBOOT0_SEL(bit) = 1, nBoot0(bit) = 1, and main flash empty

• BOOT_LOCK(bit) = 0, Boot0(pin) = 0, nBOOT0_SEL(bit) = 0, and main flash empty

I’m having difficulty understanding how to apply this in a real setup. Could anyone explain how Pattern 11 actually works and how I can configure it to reliably enter bootloader mode?

[Pavel A.]

Hello @zin10 ,

The ST-Link is great for programming and updating your device, so keeping it this way is most preferred.

To create your own software to program over ST-Link, use the "API library" provided with the CubeProgrammer.

The library, documentation and examples will be installed together with the CubeProgrammer.

Also, your software can "wrap" the command-line CubeProgrammer utility, installed with CubeProgrammer.

To your questions:

> If PA9/PA10 and PB6/PB7 are already allocated to GPIOs for LEDs, buttons, or other connectivity, can they still be used for bootloading? Or does their existing allocation block firmware download?

Or. If these pins are connected to something else, most probably the built-in bootloader won't work.

> If those pins are unavailable, are there any alternative methods 

Yes. You can make your own bootloader, and this is the IAP (in-app programming) approach.

Such bootloader can use any available pins and protocols. From the "bootloader activation" POV it is just the regular user firmware. The system bootloader won't be involved at all, and all these patterns are irrelevant.

ST provides examples of in-app update over UART and X/Y Modem protocol.

[Tesla DeLorean]

AN2606 does describe the limits and expectations of the loader. If you have space for your own code, you can make a simple loader to facilitate other pin usages.

>>If PA9/PA10 and PB6/PB7 are already allocated to GPIOs for LEDs, buttons, or other connectivity, can they still be used for bootloading? Or does their existing allocation block firmware download?

Can you be more specific? Pins that go to LEDs could be attached to at other nodes and driven externally. It's going to be looking for a pattern on PA10, and PA9 will be tri-stated.

If it's an existing board it might be difficult to access the nodes from programming.

[zin10]

Can you be more specific? Pins that go to LEDs could be attached to at other nodes and driven externally. It's going to be looking for a pattern on PA10, and PA9 will be tri-stated.

Currently, all pins on the STM32C031 are fully allocated, and there are no spare pins available. The request for a firmware update via GUI has came after the board had already been designed and production had begun, which makes remapping the pin configuration nearly impossible.

At present:

• PA9/PA10 → I²C1

• PB6/PB7 → LEDs

My understanding was that, regardless of how pins are configured in application mode, once the mcu enters boot mode, all pins would return to their reset state and could be reconfigured as needed. However, I realize this assumption may be incorrect.

[zin10]

The ST-Link is great for programming and updating your device, so keeping it this way is most preferred.
Yes, I completely agree, in most cases, sticking with the defaults is the best approach.

To create your own software to program over ST-Link, use the "API library" provided with the CubeProgrammer.
I wasn’t aware of that. Thank you for pointing it out — I’ll definitely look into it.

Or. If these pins are connected to something else, most probably the built-in bootloader won't work.
My initial assumption was that once the MCU enters boot mode, all pins would revert to their reset state and could then be reconfigured, regardless of their application mode settings. However, I now realize that this may not be correct.

Yes. You can make your own bootloader, and this is the IAP (in-app programming) approach. ST provides examples of in-app update over UART and X/Y Modem protocol.
If that(IAP) turns out to be the only option, then I’ll have no choice but to proceed with the IAP (in-app programming) approach, and from what I have learned so far, it is not as easy as it sounds, I’d really appreciate it if you could recommend any tutorials or resources you personally find helpful.