Query on Bootloader Firmware for STM32F072xx

[gmate1]

Posted on October 06, 2015 at 17:44

Hi,

I'm relatively new to STM32 series of SOCs and there seem to be pleothra of

information on Bootloader and Device Firmware update. These are perhaps the

two major reason, why I do not have a clear picture of DFU of STM32 (In my

case STM32F072R8). My queries are:

1: Does ST Microelectronics releases some bootloader code with the appropriate

memory layout (I assume that bootloader and the application firmware(s) will

sit in the different flash memory region) that I can compile, build and flash

using usual programming tools (KEIL uVision5, ST Link Debugger) ?

2: In the

http://www.st.com/web/en/catalog/tools/PF260157

for STM32F0xxxx, I found one sample program that

describes the method to program the STM32F0xx internal flash memory, which

could be a starting point for writing a custom bootloader, but this is not

complete, since this sample code (Flash_program) does not have logic to switch

back and forth from Application firmware code or handling corrupted firmware

download. For my application needs, I'm thinking of a trigger mechanism, that

will boot STM into bootloader mode, where the Bootloader will download the

new firmware over USART (Bootloader should be able to access peripherals and

recieve application firmware binary over USARTx) and flash the internal user

flash and switch to the new firmware, in case the new firmware flashing

completes with success. Are there similar application guide and/or sample code?

Thanks. #stm32

[Tesla DeLorean]

Posted on October 06, 2015 at 18:01

The System Loader is in ROM, if it supports DFU for your specific part then it will load it into FLASH in exactly the same place every other piece of code resides.

You should review other IAP (In Application Programming) examples. Transferring control is a matter of jumping to another location, typically done with the standard C concept of function pointers. The concept of booting optionally into the loader has been covered here numerous times. One technique being to place a magic constant in RAM, and having the loader recognize that if it boots. You will need to manage the error handling, and checksumming of your own firmware images, there are many ways of doing this, and it is a staple of embedded development, don't assume it needs to be STM32 specific. You'll need to floor-plan how much space is committed to the loader vs the app, you are in the best position to determine the size and requirements. Express these in your IDE's GUI, linker script or scatter file, so the linker knows where you want to place things. The FLASH is divided into blocks/sectors, you'll need to review the manuals to understand these. The Cortex-M0 is complicated by the fact you can't set the Vector Table address, it can be mapped to the base of FLASH or RAM, so when you don't have your table in those places, you must copy one to the base of RAM and map that at the zero address range. Use Google to search the forum posts related to your problem. Elecia's book may provide some foundation here

http://shop.oreilly.com/product/0636920017776.do

[gmate1]

Posted on October 06, 2015 at 18:19

According to application note, ''

AN2606

'':

''The bootloader is stored in the internal boot ROM memory (system memory) of STM32 devices. It is programmed by ST during production. Its main task is to download the application program to the internal Flash memory through one of the available serial peripherals (USART, CAN, USB, I2C, SPI, etc.)'' I am looking, something like a DFU-OTA (Device firmware Update over the air) feature in which the bootloader handles the reception and programming the internal flash over USARTx  interface. The application firmware would be downloaded from the cloud using external GSM module and passes it over to the bootloader over USART. 

[gmate1]

Posted on October 06, 2015 at 18:29

Thank you Clive. Seems I pulled the trigger a little too early. All the time, I was searching for Bootloader and none of those searches took me to

IAP

(Recently, I completed DFU over Bluetooth for a SOC that has BLE Radio) and during that period, Bootloader was my main search text. Now I'll investigate IAP, Thanks to you and also thank you for other guidelines as well. 

[Tesla DeLorean]

Posted on October 06, 2015 at 19:06

OTA is going to be a lot more involved, the Ethernet IAP might give some clues.

I've used HTTP to pull firmware images across cellular connections, it's a non-trivial exercise, and I prefer to stage the image locally before flashing the STM32. The way the STM32 flash works it does permit you to execute and write, but it can stall the processor beyond the abilities of the serial protocols to recover. If you can fit your OTA applet entirely into SRAM,  consider doing that.