STM32F051 IAP w/o a pushbutton

Posted on August 21, 2013 at 21:15

Thank you for the short and sweet answer.

I got a STM320518-EVAL kit a couple days ago and have been playing with the IAP demo in an effort to understand how the whole thing works. I think it makes sense to me.

Our goal is to be able to ship our unit with the IAP functionality and some flavor of full functioned ''factory default'' code. By initiating the IAP upgrade interface code another image is programmed at another spot in flash. When the unit is reset a jump is done to this upgraded code instead. The demo IAP code has the upgrade code at 0x08003000, I will need to move this to a higher address to leave room for our factory default code ... and I'll have to change some other things of course but ... I think this is doable.

Can anybody see any potential gotchas in this scheme?

Thanks.

Mike

Posted on August 21, 2013 at 22:25

You can partition your memory in several ways, and have multiple executable images.

I would typically place a boot loader at the base of memory, and it's size would determine where the application would be placed. The boot loader would typically validate that the application is intact before jumping to it. The boot loader would not be erased, and would fail safe if the update procedure did not complete. The loader and the app(s) would need to be compiled for the specific addresses they reside at.

You could have the boot loader dwell for a while before executing the app, waiting for serial input, commands, or external signals. Many, like u-Boot for instance, display a message or prompt, and wait a couple of seconds for an ESC character, and either drop to the application normally, or to a boot loader command line. One of the options being the download of a new application, other features would depend on the level of diagnostic and control you wished to implement.

One issue with the STM32F0 (M0) is that you can't relocate the vector table. Any application that's not running at the base of memory (0x08000000, mapped at zero) has to allocate space in the base of RAM (0x20000000), copy the new vector table there, and them map RAM at zero.

Consider carefully what interrupts are enabled/functioning when switching control between the loader and application, or the reverse.

Posted on August 22, 2013 at 15:37

Thanks a million for your input clive1. That really helps a lot.Yes, the scheme you describe is pretty much the direction I am going. It will probably be another embedded controller that is interfacing with the bootloader rather than a computer but that is besides the point.

In my research and experimenting I spent some time trying to understand the issue with the vector table and I think it makes sense to me. With the IAP demo running I examined the flash at 0x08000000 and at 0x08003000 and the SRAM at 0x20000000 after the upgrade is done. I can see what needs to be done with copying the vector table and remapping the vector table to SRAM.

Thanks for the tip regarding interrupts, that makes sense that you could get into trouble with them popping off at inopportune times.

This is my first design ever with an ARM processor, I've done loads of work with 8051 and MSP430 so I'm adding that onto my learning curve.

Thanks again,

Mike