STM32 standard bootloader question

[gosal]

Posted on September 28, 2012 at 09:25

Hi all,

I need to be able to reprogram an STM32F103 device in the field through a USB connection on UART1. It is critical that the firmware update is performed without any direct user intervention on the board (apart from maybe a power cycle of the board). I really like the fact that the STM32 devices come with an inbuilt bootloader and would like to use this bootloader if possible.I have successful managed to force the device to jump to the bootloader using a serial command parsed through the main firmware and that works flawlessly.  The problem is what would happen if the firmware update process is abruptly interrupted leaving the main firmware in a corrupt state. The device would remain inaccessible via UART1.Is it possible to have the device always boot on the internal bootloader but then jump to the main firmware if there is no communication on UART1 after x seconds ? This would at least provide a recovery method involving only a power cycle of the board. Thanks,George

[frankmeyer9]

Posted on September 28, 2012 at 11:13

The problem is what would happen if the firmware update process is abruptly interrupted leaving the main firmware in a corrupt state. The device would remain inaccessible via UART1.

Indeed. If you have not enough RAM to store the whole update package, this becomes tricky. A solution would be to select a part with at least twice the Flash size required for your application. You can load the update in the second, inactive part, and activate it in the bootloader part of your application, once the update loading proved successfull. I would than have the updated version to erase the Flash block containing the previous version at first startup. At least, I would avoid to erase any Flash during the update transmission, as Flash erase times can be arbitrary long.

[Tesla DeLorean]

Posted on September 28, 2012 at 11:50

You need to break your firmware into two sections, and code your own bootloader to address the seamless/recovery issues, and validate and jump to your application code.

[David Littell]

Posted on September 28, 2012 at 13:22

Is this ''USB connection on UART1'' (whatever that is...) to be used for anything other than field updates?  If not, you could add a little external function that watches the reset signal, can drive reset and the BOOTx signals, and watches for anything being plugged at the update connector.

When this function sees a reset with nothing at the update connector it drives the BOOTx's to run your code.  If something is plugged in to the update connector the function asserts reset and drives the BOOTx's to run the bootloader.  It then waits for the updater to be unplugged, drives reset when it's unplugged, and continues on.Of course, some idiot could hang your board just by plugging in something...

[Tesla DeLorean]

Posted on September 28, 2012 at 15:39

Is this ''USB connection on UART1'' (whatever that is...) to be used for anything other than field updates?

One might hazard that it's one of those SiLabs/FTDI/Prolific USB-to-CMOS serial chips, in which case you might be able to use DTR, or some other pin to control BOOT0/RESET etc. While using the built-in loader as an end-user update mechanism it is fraught with issues that could easily be addressed by writing one's own boot loader and update strategy. One of the critical strategy is not to update/erase the boot loader itself,  and have it sanity check the application code it is jumping too.

[gosal]

Posted on September 28, 2012 at 17:49

Thanks for the replies so far...

Yes the USB interface is FTDI (FT232RL) based so in theory yes I can use the DTR or some other pins to select the bootloader option but in practice it is something I would like to avoid, as Dave mentioned one could easily hang the system. The USB connection is normally also used for communication and PC interface and it is either permanently connected or connected by the user as needed. So anything involving detection of the USB connection won't work. Using the DTR is an option but as I said I would like to avoid that.I was hoping that with the inbuilt bootloader in the STM32 I would avoid having to write my own bootloader but it seems that is the only option to ensure and ''unbreakable'' firmware update process.I was also thinking about the possibility of using one of these devices: 

http://www.ramtron.com/products/nonvolatile-state-saver/

 to set the state of the BOOT pins. Basically before jumping to the inbuilt bootloader, the firmware would configure the BOOT pins to bootloader mode so that if anything fails , the next power cycle state would be in bootloader mode. A valid firmware, on startup would then reset the BOOT pins status so that the next power cycle would call the firmware.Of course there is the cost of the device but it would save me the time to write an throughly test a custom bootloader.

[Tesla DeLorean]

Posted on September 28, 2012 at 19:54

The RAMTRON solution seems a bit hackish. It's not as if the System Loader is a particularity elegant implementation. Something simple using a more robust protocol like X-Modem-1K shouldn't take more than a couple of days to fashion.

Presumably you're review the IAP (In Application Programming) App note?

[gosal]

Posted on September 29, 2012 at 11:02

Hi Clive,

Thanks for the tip on the IAP appnote, No I was not aware of this app note and the example IAP driver source code. I'm relatively new to STM32 and that's why I prefrred to use the inbuilt bootloader rather than develop my own but seeing this IAP driver I think it will be quite easy to modify it to my needs.Yes I agree the Ramtron solution is purely a hack :).Thanks a lot! Will try this out next week.George