Recommanded ''Final Product'' firmware update method

[Arguimbau Olivier]

Posted on October 24, 2017 at 09:22

Hi.

Our company is working on a product that use 'STM32L151' MCU, for debug we are using SWD with a custom connector. For prototype tests we used USB with 'DFU USB Mode' and the 'DfuseDemo' program.

Now come the time to think about final product update system, we are new to this market and I appreciate any advice for implementing a reliable 'update mecanism'.

Here are some product specs : 

- USB connector available (work as a VCP with a debug console and can be switched to DFU mode with a console command after reboot)

- Dual bank flash (Actually firmware use one bank)

- One button on device (+one power button)

And i have no time to develop a specific USB driver for Mac +Windows ...

I was thinking of reuse ST's DFU usb mode , i don't know if it's legal or even if it's the best technical solution.

Advices are welcome.

Bye !

#dfu #firmare-update #final-product

[AvaTar]

Posted on October 24, 2017 at 10:05

Some additional information might be helpful:

 - who is updating your device (customer, your service people) ?

 - how often, and under what conditions (location/circumstances, downtime limitations, etc.) ?

 - any form of protection (like ROP) enabled ?

And by the way, some L151 devices have a NRND status. Hope you are aware.

[Arguimbau Olivier]

Posted on October 24, 2017 at 14:04

Hi, and thank you for your response

- Update process is for customers

- Update is planned for 1 time/year  by the customer (through a dedicated application i think, not sure quite now)

- For now no protection at all (i know it's dangerous) , as soon as i get more time i 'll look for ROP or similar system

I was thinking of using the second bank to store the firmware and then use a simple 'boot to bank 1' or 'boot to bank 2' system

We are aware of NRND thanks.

[AvaTar]

Posted on October 24, 2017 at 15:12

- For now no protection at all (i know it's dangerous) , as soon as i get more time i 'll look for ROP or similar system

I'm not judging (I never use ROP for my private projects), but it might complicate things.

- Update process is for customers

That means, IMHO, keep it simple and save.

No too complex manipulations to get into an update mode, and proper checks if the update succeeds.

I was thinking of using the second bank to store the firmware and then use a simple 'boot to bank 1' or 'boot to bank 2' system

The only issue with most STM32 MCUs - no code execution from Flash while erasing/programming, no matter where from.

You might need to locate certain routines in SRAM.

Swapping complex protocols to SRAM might be impossible for some protocol - SRAM size combinations.

A proven method is a permanent second-stage bootloader (the ROM-based system BL being first stage) that checks for a boot flag and an proper application in flash at every startup.

A 'boot flag' could be a button pressed during startup.

If this flag is set, or no proper application found, the device remains in the BL, else it jumps to the application.

Checking the downloaded data for corruption and proper signature is highly recommended.