STM32F4 Firmware upgrade

russdx · ‎2012-09-22

Posted on September 22, 2012 at 20:19

I have found a few examples of how to update the firmware on a STMF4. The first one you needed to use a usb memory stick and the second one you had to reset the microcontroller and put the boot pins in the correct configuring to put it into dfu mode and then use some weird stm software to upgrade the firmware.

I have noticed the st-link uses a stm32f1? microcontroller and to update this you simply run a little .exe and it talks to the microcontroller checks the current firmware version and then downloads the latest if needed. no putting it into some weird boot state.

my question is can this simple process be used on the STM32F4 as well? if so does any one know where the documentation for this process is?

thanks 🙂

frankmeyer9 · ‎2012-09-23

Posted on September 23, 2012 at 15:44

See this application note:

AN2606, ''STM32 microcontroller system memory boot mode''

russdx · ‎2012-09-25

Posted on September 25, 2012 at 15:34

Thanks 🙂 that was very helpful.

I dont want this update process just to happen at boot. it could happen at any time (basically when the user runs the update firmware program on there pc)

So am i right in saying this now has nothing to do with the bootloader?

can i just download the new program using usb while my application is running and then write it to the flash? while the microcontroller is running its current program?

Tesla DeLorean · ‎2012-09-25

Posted on September 25, 2012 at 15:53

Not really.

The ST-LINK in the VL-DISCOVERY uses DFU, and places the device in this mode prior to updating it. The regular application has to stop running, and you need to be running code from an area of flash you are not going to erase or rewrite. This is most generally achieved by having some code tailored to do this, like a boot loader, that is separate and distinct from the regular application.

The ST-LINK upgrade app looks simple and slick because the people that coded it understood a lot about Windows programming, and boot loader and updating mechanics.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..

russdx · ‎2012-09-25

Posted on September 25, 2012 at 22:38

ah i see.

hmmm, my device needs to be running its program from the second it is turned on (updating a gas DMD display which needs to be constantly updated or it can burn out). so i cant wait in a special DFU state every time its turned on.

need to think about this a bit more hehe.

maybe the usb key update example might be better suited to my application. as the program can be running / checking for the usb key at the same time 🙂

or maybe i can add a special update button that the user presses when they want to update the board and this causes it to go into the dfu state. (they would have the dmd unplugged if updating firmware)

Tesla DeLorean · ‎2012-09-25

Posted on September 25, 2012 at 23:10

You'll have to think about the best way to proceed. The key is to come up with a method tailored appropriately to your unique circumstances, and not some arbitrary solution that was designed to address a different set of circumstances/conditions.

Typically you'd send some custom command to get the device into a programming state, this wouldn't preclude you have some minimalistic code that can drive the display in a safe/sustaining fashion. This doesn't have to be a boot/reset, but you have to be conscious of interrupts, and perhaps shadow some of the function of the primary app which is being replaced.

You could get multiple application images within an F4's flash space, figure a number of 128KB blocks. Now one of the issues here is that the erase takes a long time (seconds), and will stall execution if running out of flash. If things can be run out of RAM you'll be a lot safer/faster, but it will complicate recovery from flash or power failure issues. ST has been promising a dual banked device which might help address the run-while-flashing issue.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..

russdx · ‎2012-09-26

Posted on September 26, 2012 at 15:27

My application is basically a device which receives 128x32 pixel display frames from a pc using the STM32 usb classes, then sends them to the DMD display. (constantly updating the same frame until it changes)

when the user needs to update the device they can unplug the display so the firmware download process can take as long as it needs (over usb probably not that long at all)

if im understanding what your saying correct.

instead of sending a dmd frame, i could send a firmware update code followed by the actual firmware data and just write this to an unused part of the memory. once wrote i start executing the code again from this new part of memory.

one question i have is when the device next boots up how will it know to now run the code from the new part of the memory and not the default part it was using before?

thanks for all your help 🙂

Tesla DeLorean · ‎2012-09-26

Posted on September 26, 2012 at 17:01

You'll observe that the front end flash blocks on the STM32F4 are smaller, the purpose here is to allow a small boot loader, or arbiter app, to control the boot process and farm it off to apps/code parked in subsequent larger blocks. The small blocks can be used to write NV configuration, personality or calibration data.

The first 16K block should be sufficient to code a small and permanent boot loader, which can test other regions for valid application code, perhaps compare date/version codes and pick the most current. RAM retains across a reset, so you can also park magic values there to pass data from the current application to the boot loader. The boot loader could also manage the flash, erase blocks, and move things around.

One of the key things you can do for robustness is to stage the new firmware somewhere, and then when you have a complete/validated image you can do an erase and write to the final destination in a single swift operation. Having a complete image before you start significantly improves the chance of success, compared to erasing and then getting data sent by the host a bit at a time. See ST's IAP Y-Modem example. You could stage it in unused flash, or external memories like serial flash, or SD Cards.

If your flash budget is tight you'll need to map out what you can use. I'll note that the STM32F4 die has 1MB of flash on it. A large portion of that will assuredly work even in 256KB marked versions, and you can certainly test.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..

russdx · ‎2012-09-26

Posted on September 26, 2012 at 17:44

ok this is sounding good 🙂

i will be going with the STM32F407VET6 as it seams to be the cheapest. it has 512k flash which i think will be more then enough as my program code is very very small, its all the usb libs that bump it up a bit in size.

i like the idea of usb downloading the new firmware as a complete image to a spare part of the flash then writing it to the default part of the flash.

im a little bit confused about if the program is running, how can it write to the default flash? as it will be in use by the main program?

or does the main program download it to spare flash? then it resets it self and the boot loader then copys to the default flash and just boots as normal?

can these stm32s reboot them selfs?

thanks for all your help, im very new to stm microcontrollers but am learning alot!! 🙂

russdx · ‎2012-09-30

Posted on September 30, 2012 at 14:12

Thanks Clive 🙂

I have gone down the route of just using the built in dfu bootloader and am resetting the micro controller my self in code and setting a flag in the sram, then checking this in the startup.s and switching to the bootloader.

the user can then use the DfuSe demo program or i can write my own to download the new firmware.

It all works great 🙂

Thanks