Electronics > Microcontrollers

Custom STM32 bootloader guidance

(1/7) > >>

Tripplecheckuser:
I want a way to upgrade a custome pcb board for a product in the the field in case there is a bug of some sort. My board uses the STM32F030K6T6 ic. I haven't done any work with bootloaders so I started by reading through the available documentation ST provides (DataSheet, AN3155 and AN2606 ). From this, I gathered that I can access boot mode from the boot0 pin but can only flash an image via USART (pins pA10 and pA9 or pA14 and pA15). Problem with this is that the pcb has already been designed to use pA10 and pA9 for I2C communication with modules, pA14 is for SWD clk for flashing and pA15 is for a random LED. A full redesign isn't really possible as the product is set to launch in the next few months. My initial thought was to finish testing and functionality and work on upgradable capabilities later but it looks like bootloaders are a lot more complicated than I thought. On some of our older products, we use I2C to update our firmware but those products use Microchip ICs (PICs). With this issue in hand and a miniscule amount of experience, I came up with 2 possible solutions:

1. Make a custom bootloader for the stm32f030k6t6 that will allow for me to update via I2C

2.  switch pA9 and pA10 to USART peripherals, switch into boot mode via code (the boot0 pin was not considered when the circuit was made) and update firmware via USART.

Both these options seem way out of my scope of understanding, but I am willing to put in the work. What advice can you give me in terms of tackling this? Is there one option that is more practical than then the next given my experience level? :scared: :scared:

Siwastaja:
There is absolutely nothing complicated in bootloaders, just some work and learning curve as always with anything.

Most robust and probably also easiest way to deal is dividing the flash into three parts: bootloader, application A and application B. Bootloader only verifies the validity of application A & B (against a checksum) and boots either one; a few dozen lines of code. Then application itself is responsible of receiving the firmware update data, erasing the other app and writing there. This way, power loss or other issues leave the working application intact, and the bootloader will just boot the old firmware again in case the new one fails at check.

This way, bootloader itself does not need any flash writing or I2C receiving functionality, and therefore, can be simple enough that bootloader itself does not need an update mechanism, either. I don't frankly understand why people prefer complicated bootloaders over doing most of the work in the application itself.

You have to:
* Learn how to use linker scripts to describe the memory addresses where application code is placed;
* Learn how to erase and program the flash memory - this is all explained in STM32 reference manual and simply involves some register writes and polling for status flags
* Learn the bootloader magic itself, which is just a few lines of code of inline assembly copy-pasted from the internetz.

Psi:
The bootloader isnt very complicated, it's just like any other app

The most annoying bit is usually figuring out the correct settings for the linker script.
You usually also need to setup some variables no-init and have them at a fixed memory address.  (so the bootloader and app have some shared space to exchange flags bits and stuff)

Tripplecheckuser:
So basically application A is my default ap that will act as a default (when I don't have an ap B or there is an error with app B's checksum) and application B would be the updated version of the application?

Tripplecheckuser:

--- Quote from: Psi on June 08, 2023, 01:07:28 pm ---The bootloader isnt very complicated, it's just like any other app

The most annoying bit is usually figuring out the correct settings for the linker script.
You usually also need to setup some variables no-init and have them at a fixed memory address.  (so the bootloader and app have some shared space to exchange flags bits and stuff)

--- End quote ---

Hmmm linker scripts seem to be a big part of the process. I guess I will have to dive into what it takes to make one. I assume it is different than the bootloader code or application code?

Navigation

[0] Message Index

[#] Next page