There are many ways to program an STM32 chip (in my case STM32L4R5):
- USB DFU mode (using DFuSe utility from ST)
- UART Serial Port (through something like FTDI chip)
- JTAG or SWO debug ports
- 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!
-
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– old_timer2019年09月16日 03:51:33 +00:00Commented Sep 16, 2019 at 3:51
-
3\$\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\$Chris Stratton– Chris Stratton2019年09月16日 04:15:35 +00:00Commented Sep 16, 2019 at 4:15
-
1\$\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– Ben Voigt2019年09月16日 05:04:54 +00:00Commented Sep 16, 2019 at 5:04
-
1\$\begingroup\$ ... without extracting/decompressing it first \$\endgroup\$Ben Voigt– Ben Voigt2019年09月16日 05:05:10 +00:00Commented Sep 16, 2019 at 5:05
-
1\$\begingroup\$ @BenVoigt DFU requires the installation of a driver first (on Windows at least) in addition to the updater, which might be quite challenging for some users. An emulated mass storage device requires no user action other than dragging and dropping a file. \$\endgroup\$followed Monica to Codidact– followed Monica to Codidact2019年09月16日 07:17:50 +00:00Commented Sep 16, 2019 at 7:17
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– Neil2019年09月16日 22:53:29 +00:00Commented 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.