There are many ways to program an STM32 chip (in my case STM32L4R5):

  1. USB DFU mode (using DFuSe utility from ST)
  2. UART Serial Port (through something like FTDI chip)
  3. JTAG or SWO debug ports
  4. SD Card bootloader: https://github.com/akospasztor/stm32-bootloader

But often omitted in discussions is something similar to NXP's In-System Programming (ISP), see note AN10986 (PDF)

It is the easiest (avoids using a proprietary ST DFuSE utility), cheapest (avoids SD card receptacle BOM cost, or USB-to-Serial chip) of all but I couldn't find a solution anywhere on the internet. For example, the Teenage Engineering OP-Z firmware upgrade process is similar to NXP's ISP - i.e., connect the device to a computer over USB, it shows up as a Mass Storage Device and drag and drop the .bin/.hex file, eject and voila! the firmware upgrade process automatically starts. How can one implement such a way to upgrade firmware on STM32 devices?

I want the user to upload firmware on my device in the simplest, easiest way. It is OK for prototyping phase to use aforementioned methods (1-4), but it is unacceptable in a real production device.

Any insight into this matter would be greatly appreciated!

  • \$\begingroup\$ the nucleo boards show up as a usb drive on your computer. thats the debug end of the board, but I think those are also ST devices. there is no such thing as "best" of course, that is a "primarily opinion based" closure kind of thing. But the dfu mode only requires a usb connector on your board, and a jumper or switch. The other solutions require additional hardware on the board (ftdi or other as you have pointed out) or an external board and a cable/wires. So the dfu solution is probably the winner. \$\endgroup\$
    – old_timer
    Commented Sep 16, 2019 at 3:47
  • 1
    \$\begingroup\$ If you write perfect firmware, of course why would there ever need to be an upgrade, but you can create a usb protocol that doesnt require additional hardware other than the usb connector. Can go so far as to look like a mounted drive, although they could drop anything on there and crash the product. You can make a protocol that is simpler than dfu, but you would need to create the software to do the upgrade. You could put a switch/jumper on there and have an alternate boot path that looks like a mounted drive. \$\endgroup\$
    – old_timer
    Commented Sep 16, 2019 at 3:51
  • 2
    \$\begingroup\$ There are multi-platform open source solutions for this such as UF2 available out there, but requests to find libraries or code modules to meet a purpose are off topic in the SE system, just as requests to find physical parts to buy are. Also worth noting that faking USB mass storage is horribly complex given the wide variety of host operating system behavior, and the fact that the data will not, in actuality, be absorbed into a file system of the type falsely presented. \$\endgroup\$ Commented Sep 16, 2019 at 4:15
  • \$\begingroup\$ "I want the user to upload firmware on my device in the simplest, easiest way." That would be accomplished by providing an upgrade tool that automatically finds the device and loads the firmware. Maybe should have a DFuSe library built in. Appearing as mass storage is not actually very user-friendly... they have to distinguish your device from other USB storage devices, place the right file on the device, and prevent the OS from making "magic" files (Windows loves its "System Volume Information" directory, Mac likes to make resource forks). Just wait for a user to drag their firmware zip. \$\endgroup\$
    – Ben Voigt
    Commented Sep 16, 2019 at 5:04
  • \$\begingroup\$ ... without extracting/decompressing it first \$\endgroup\$
    – Ben Voigt
    Commented Sep 16, 2019 at 5:05

3 Answers 3


It's possible if there is enough memory (RAM or FLASH) to be used as a backing store, holding the filesystem image consisting of filesystem structures (FAT tables, directory entries etc) and the new firmware, in addition to the flash where the firware is to be written.

Check the STM32Cube library distribution for your controller series, it might contain an example application called USB_Device/MSC_Standalone, which emulates an usb mass storage device (flash drive) using some onboard storage. If there is none for your controller, find one for a similar MCU, it's quite portable.

The first step is to adapt it to your device, to use whatever onboard storage your board has. Easiest if the firmware fits in internal or external RAM.

The memory area should contain an empty (formatted) filesystem image at the USB connect event, you can create it with FatFS.

After the USB disconnect there should be a filesystem image with the firmware in it.

Use the FatFS library to access the firmware (.bin) file stored in the image, and copy the contents to the right address in the internal flash where it can be executed.

It is also possible to turn this around (when the MCU has USB host capability), read the firmware file from an USB flash drive using FatFS, and write it directly into the internal flash without using intermediate storage. Again, there are example programs showing how to read a file from a flash drive using FatFS.

This would work with an SD card too, using SDIO (if present) or SPI interface.

  • \$\begingroup\$ Thanks, I can try to edit the existing STM32 SD Card Bootloader (linked in the original post) and modify it to fetch files from USB MSD instead of SD Card. \$\endgroup\$
    – Neil
    Commented Sep 16, 2019 at 22:53

It is OK for prototyping phase to use aforementioned methods (1-4), but it is unacceptable in a real production device.

Are they really? I know many products that use any of the above simplified by a simple gui tool. If they don't have WiFi ota updates... Except the SD card one, everyone knows how to use that.
Are you expecting users to update very few days? Since if you are, I strongly suggest writing better code.

Anyway, the USB MSC DFU in the LPC11U24 just writes a bin file directly to flash if the checksum of irq table is correct. Doing the same for hex files would be challenging. The bootloader also cannot recover from failed writes, since there was never room to cache the entire binary. It's really just a gimmick, and they haven't really put it in any other parts since these few select parts.

It is up to you if you want to add a little flash chip you can perform the USB MSC on, and the reboot loading the new flash image from that. It should be perfectly possible to do this reliably.


If you have USB in app, i'd recommend to use USB DFU (Device Firmware Upgrade) mode, but use STM32CubeProgrammer instead of DfuSe - there is also CLI for it (you can see https://electronics.stackexchange.com/a/540449/35381)

however there should be also other DFU tools, it's USB standard.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.