STM32F051 IAP w/o a pushbutton

[munger]

Posted on August 15, 2013 at 21:45

Hi,

We are developing a product using a STM32F051 and want to be able to upgrade the code using IAP. I've been reading anything I can find, AN4065, the examples, etc. It seems like the general idea is that the micro powers up and looks at the state of a port pin to decide if it should start the IAP Driver. But, we won't be able to have that port pin available. The micro will be buried in a machine with only RX/TX and power and ground going to it. So, will I be able to set it up so that it initiates the IAP driver via a serial command anytime I want to?  Or, can I do this: Start up, init the UART, wait ~100ms for a command to initiate the IAP driver, if I don't get the command before 100ms start up normally.Thanks.Mike #iap #stm32f051 #stm320518-eval

[Tesla DeLorean]

Posted on August 15, 2013 at 22:14

You can write your code to behave however you want it too.

[munger]

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

[Tesla DeLorean]

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.

[munger]

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