cancel
Showing results for 
Search instead for 
Did you mean: 

Is it possible to automate flashing a STM32?

CDyer.1
Senior

Hi, I've designed a custom board that has a STM32F411 and a STM32f446 on it. I would like to be able to have customers update the firmware on the boards as easily as possible. Currently, I program the chips using an ST-Link but can also program over UART using a TTL to USB cable. Now my question; is it possible to program the STM32 without using software provided by ST? I'd like to be able to provide a USB stick and a TTL to USB cable to a customer so they can program the system without having any microcontroller knowledge (or something similar). What is the best way to achieve this?

edit: Just to clarify a couple of points

  • The device is for heavy industry applications and will be installed in an IP67 rated enclosure usually outside in a quarry or inside a factory
  • It is possible that the customer may have no dedicated IT staff (if a small quarry for example) but will have HR staff that can use a Windows computer
  • I will be assuming that the customer can move a windows machine to the location of the installed device (via a laptop for example)
  • The device will be updated on a one to one basis - no organisational updates needed
  • Upgrading the firmware on the device needs to be as basic and simple as possible so an individual familiar with how a PC works can do it.
  • Hardware is not 100% finalised yet. Small changes can still be made to accomodate any hardware needed for reflashing on the customers end.
11 REPLIES 11
TDK
Guru

Using the STM32CubeProgrammer command line interface is pretty simple. You could write your own software, but I don't see it getting any easier. The UART bootloader interface is fully documented.

https://www.st.com/resource/en/application_note/cd00264342-usart-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf

If you want to use UART, you need a method to get the chip into bootloader mode. To avoid that, I'd prefer ST-Link/SWD, which allows debugging as well.

If you feel a post has answered your question, please click "Accept as Solution".

As customers will mostly be non-technical and may just want future software updates, it doesn't make sense to provide them with st-link debuggers to update their firmware. I was hoping that there was a simpler solution to programming the chips than programming via command line. Thanks for the link to the UART bootloader I'll take a look. It shouldn't be too confusing to ask a customer to press a switch to pull the boot pin high and press a reset button to get into bootloader mode, but it's the software side that may cause a problem. I wonder if I can automate the UART programming via batch file or something

You can certainly put the command line commands into a batch file and run it from there. That is the path I would take. Again, doable with ST tools but you could certainly recreate it yourself.
If you feel a post has answered your question, please click "Accept as Solution".
Pavel A.
Evangelist III

Is your device distributed to individual users (consumers) and updated one by one on (say) a WIndows PC, or organization which will update many devices at once, by a [minimally trained] IT person?

Does your board have USB function?

From POV of individual user with a PC, dropping the file to a virtual USB drive is easy and intuitive.

Next comes a virtual COM port and common software such as Teraterm with X/Ymodem.

A custom serial cable is less preferable: users will lose it.

The UART protocol is documented, people can and have written applications based on this.

I think the DFU mode is probably documented sufficiently also, but not something I've personally needed to recode.

Any of your staff able to write Windows Applications?

The USB Flash and USB-to-TTL don't really make a whole lot of sense together, you'd need to host the flash drive directly on the STM32

One could use an SD card on the system if it has a card slot, you could connect a USB Flash drive with the right connector and USB Host side software. The STM32F4-DISCO actually has a FWUPDATE example. Getting the update off an SD card also is not particularly hard.

With your own loader you can implement any kind of update process you want, it can be robust, and you can put whatever user interface on it that suits you or your customers.

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

I'll add these details in the original question, thanks for asking.

Javier1
Principal

Small battery powered blob that ,when plugged to the electronics ,flashes things automatically.

im doing a similar product for a client.

Im just giving them a battery powered raspberry Zero with a stlink connected to its USB. (openocd)

with a fancy screen so they know if everything went ok

the raspberry is running python/bash scripts to detect and flash new chips automatically (plug and flash)

 And, if connected to wifi, checks github for firmware updates

With minor modifications this can be archieved with any device running linux

we dont need to firmware by ourselves, lets talk

That's not something that I've thought of, although a raspberry pi zero in a case with a screen is more hardware than I wanted to deal with. In my experience a SPI controlled screen for a raspbery pi is usually about 320x240 in resolution and so the OS and touch functionality for navigating is almost useless. Could you perhaps share a link to the screen hardware if possible?

"The USB Flash and USB-to-TTL don't really make a whole lot of sense together, you'd need to host the flash drive directly on the STM32" What I meant by the USB-to-TTL was to use the UART flash bootloader but hook it to a Windows machine using a USB-to-TTL and then program it over serial. Unfortunately I'm the only technical member of staff so my resources are limited and the project only has months left. I'd love to write my own bootloader and i think that would be the ideal scenario but I have neither the time or the skills. I'll look in to the SD card option, that's a scenario I've not considered, thanks.