Firmware update via USB mass storage

[Boomerang]

Hi,

I'm trying to understand how the USB bootloaders actually work... I must be able to prepare some binary file and distribute it through web site or e-mail to my future users and they must be able just to copy the binary file to the device (via USB) and update to initiate after next reset. No need for any security - no need for encryption of the binary, users must be able to upload any firmware (not only mine). It will be good to have only some basic transmission error checking.

Is this possible with current factory bootloaders from ST or NXP?

[NottheDan]

something like this? Also this.

[Boomerang]

About the NXP's implementation - from the document I see that the emulated disk drive is not behaving completely standard - it executes only some small set of commands and etc. My question is: is it possible to update the firmware without downloading and installing any "update tools" - is it possible to do this only with standard Windows?

Anything similar from ST ?!

[bobaruni]

You're looking for a MSD (Mass Storage Device) bootloader.
When in bootloader mode, the device behaves like a USB stick, just drag and drop the firmware and reset after the file has copied.
I don't know of any STM32 chips that have this feature from factory but you could definitely put it on yourself.
Some of the STM32 chips come with a USB DFU (Direct Firmware Upgrade) installed but this requires proprietary software to access it and is not drag and drop like MSD.

[jnz]

Listen, you can go this route, and maybe it makes sense for you... But honestly, I looked at USB, Mass Storage Controller, File System, all that.... Went bluetooth instead. Saved myself a TON of work.

[Koen]

NXP LPC1343 have an USB-MSD bootloader, maybe others. It isn't hard nor long to program on STM32.

[nctnico]

About the NXP's implementation - from the document I see that the emulated disk drive is not behaving completely standard - it executes only some small set of commands and etc. My question is: is it possible to update the firmware without downloading and installing any "update tools" - is it possible to do this only with standard Windows?

AFAIK this works out of the box on any OS (including Windows). Forum member Zapta has made a nice little board which uses an NXP controller which supports this way for firmware updating.

[Boomerang]

Listen, you can go this route, and maybe it makes sense for you... But honestly, I looked at USB, Mass Storage Controller, File System, all that.... Went bluetooth instead. Saved myself a TON of work.

This is cool

How you make it? Do you install the bluetooth module just to be able to update or also for general communication? Please describe how it works!

[tszaboo]

I used the LPC13xx bootloader. Just pull down a pin, and plug it to your pc, copy that 64 KB firmware file on it, reset. Very easy, works out of the box. You dont even need a debugger/programmer for the LPC13xx to get you started.

[Jeroen3]

NXP LPC1343 have an USB-MSD bootloader, maybe others. It isn't hard nor long to program on STM32.

LCP11U24 have it in ROM indeed. Not very stable though.

Programming a bootloader isn't an easy task. It requires advanced knowledge of the toolchain to configure the linker and boot code. And it requires knowledge of the used interface to make it robust. Using USB isn't as easy as CAN to build. But for anything not MSC, you'll need an application. True.
In the end, you're linking two projects into your mcu.

Most people lack the knowledge of the toolchain's linker (eg: they have never heard of a map file before).

I'd recommend not using USB MSC for bootloader because you then rely on something you can't possibly have any effect on.
The Operating System and how it handles files.
Instead, use USB DFU, which is developed for this. You then only need an application. Which also resolves a lot of potential usage errors.

Eg: Will your USB MSC upgrade firmware still work on Windows 7 to 10, and 11? If it doesn't, you have to go on-site or have a lot of send-ins.

Safest way to perform USB MSC upgrade is to have enough memory to store the image fully (flash/sd/ram). Perform checksum, and rewrite it. Most mcu's don't have that though.

[nctnico]

Eg: Will your USB MSC upgrade firmware still work on Windows 7 to 10, and 11? If it doesn't, you have to go on-site or have a lot of send-ins.

I recon manufacturers of thumb drives will have the same problem in that case.

[voltsandjolts]

If your actual application requires a USB host anyway, then yes, it would be reasonable to use this for firmware updates. But do the USB MSD handling in your application (it does that anyway) and copy the firmware update file to onboard memory (serial flash?) which is easily accessible by a much simpler bootloader (i.e. bootloader knows nothing about USB).

If your application doesn't need USB then don't design it in just for firmware updates!

Edit: I concur with posts below, if a USB bootloader is provided then its worth just adding a socket to get USB firmware updates for zero effort.

[Boomerang]

I will have micro-USB port to charge the device. It's logical to use it also for the firmware updates.

[andy1]

NXP LPC15xx also has the same USB bootloader and I have used it in couple projects, really nice as like said you just press button (or whatever you tie to the isp pin) and plug the USB in and it wil pop-up as disk drive and just drag the new binary there and boot into the new firmware, I also like the fact that the bootloader is in ROM so no messing up with linker settings etc.

[timb]

I've done this with an MSP430 before (the F5529 variant I think).

Basically, TI had some demo code that set the MSP430 up as a MSC device. In the demo, you could edit a text file stored on the device and then hit a button and have it type the contents of the file (it also enumerated as a HID keyboard). Anyway, the MSC portion of the code was very helpful in getting the firmware loader working.

I implemented the MSC functions in the user application code and *not* in the bootloader itself. It was much easier that way and a whole lot more stable! (I'm not an expert in writing bootloaders, so I figured the built-in bootloader would be a better choice..)

Basically, you power the device on with a special GPIO shorted and connected to a USB host. It enumerates as a MSC drive and you drop a file named firmware.hex and firmware.txt onto it; the txt file contains an MD5 checksum and a version number while the hex is the firmware itself. When you eject the drive, it will look for those files, run an MD5 and if it's valid, reboot into the bootloader, directing it towards the new image. The bootloader then verifies the image is valid, copies it to the correct location, verifies it was copied correctly and reboots.

When the new firmware boots and sees the firmware.txt, it reads the version number out and, if they match, erases the MSC partition.

It's simple but seems to work well in the field. I'm currently porting it to the PSoC5LP.

[zapta]

If your application doesn't need USB then don't design it in just for firmware updates!

It provides a very user friendly firmware update. No need for a special cable or software on the host computer, just a standard USB cable and file drag and drop.

I am using it with NXP LPC11U35. It works so well that I used the USB bootloader also for normal code development cycle, having an auxilary script in LPCXpresso that automatically copies the new signed binary to the mounted USB disk.

The boards have an ISP button with a simple diode logic that when pressed resets the MCU and pulls the ISP pin to start in USB ISP mode. A second button (RUN), pulls down only the reset pin to start running the program.

[voltsandjolts]

Agreed, if a bootloader is already available its worth adding the USB socket. I think coding a USB bootloader yourself is not worth the effort.

... copies the new signed binary to the mounted USB disk.

How are you implementing firmware signing - with Public Key/Private Key encryption?

[Jeroen3]

NXP requires a signed image with a checksum of the vector table.
https://community.nxp.com/thread/389046

No fancy cryptography.

[zapta]

Agreed, if a bootloader is already available its worth adding the USB socket. I think coding a USB bootloader yourself is not worth the effort.

... copies the new signed binary to the mounted USB disk.

How are you implementing firmware signing - with Public Key/Private Key encryption?

Yes, Jeroen is right. It's not actually signing the binary but only setting its checksum. The checksum program is provided by NXP and you run it after the standard gcc toolchain. Without it, the MCU will reject the new binary.

Also, on Mac OSX, a GUI file drag and drop doesn't work because the OS also tries to copy first a metadata file call .DS_store which confuses the MCU (it tried to accept only the first file written to it) but a command line file copy works just fine.

I setup this shell script in lpcspresso as a post build script and it copies the .bin automatically to the ISP/USB drive.

https://github.com/zapta/arm/tree/master/pro-mini/lpcxpresso/arm_pro_mini_lib/tools

[Jeroen3]

I have to. 

Also, on Mac OSX, a GUI file drag and drop doesn't work because the OS also tries to copy first a metadata file call .DS_store which confuses the MCU

I'd recommend not using USB MSC for bootloader because you then rely on something you can't possibly have any effect on.
The Operating System and how it handles files.

[timb]

I have to. 

Also, on Mac OSX, a GUI file drag and drop doesn't work because the OS also tries to copy first a metadata file call .DS_store which confuses the MCU

I'd recommend not using USB MSC for bootloader because you then rely on something you can't possibly have any effect on.
The Operating System and how it handles files.

That's a problem with that specific MSC bootloader though.

In my implementation, I simply look for files called firmware.txt and firmware.hex; blindly accepting the first file is absolutely dumb as shit and that's wholly on whatever CS intern they got to program it.

[zapta]

That's a problem with that specific MSC bootloader though.

In my implementation, I simply look for files called firmware.txt and firmware.hex; blindly accepting the first file is absolutely dumb as shit and that's wholly on whatever CS intern they got to program it.

With your restrictions, the image file cannot include in its name metadata such as product name and version.

[timb]

That's a problem with that specific MSC bootloader though.

In my implementation, I simply look for files called firmware.txt and firmware.hex; blindly accepting the first file is absolutely dumb as shit and that's wholly on whatever CS intern they got to program it.

With your restrictions, the image file cannot include in its name metadata such as product name and version.

In my method, that information was included in the firmware.txt file. The two (hex and txt) could be zipped together for distribution and the zip itself could have that information in the name as well.

*Or* you could easily alter the MSC loader to grep the checksum and version from the firmware file's name, like this:

firmware-v1_23-1234567890abcdef.hex

So, it looks for a file that starts with "firmware" and ends with "hex", loads the file name into a variable and parses it. Parsing could be done easily, just look for the first dash character, what comes after that is the version, being terminated by a second dash; the checksum is the remaining characters after, being terminated by a period. Pretty simple assuming you're using a FAT library that supports LFN.

The reason I went with a separate txt file is because it made it easy to parse and I didn't have to worry about long file names. I intended to go back and implement the version and checksum in the filename itself, but ran out of time.

The client ended up liking having the separate txt file anyway; the final version had the MSC loader write debug information to the file during and after the firmware upgrade. So, the first boot after the new firmware was flashed, you could grab the firmware.txt file back off the drive and verify there were no errors. Once you ejected it the first time (or restarted) it would erase the firmware files and disable MSC mode.

[rstofer]

I kind of like the mbed drag-and-drop approach to updating firmware.  There is a second MCU on the board that handles the USB interface and there is enough storage for several images (I don't know how many, I erase obsolete images).  The main MCU gets updated at the next reset.

Look over at mbed.org and see if you can find out how they did it.  The scheme works well across a variety of hardware.

More, I like the idea of using an SD card and some kind of tiny processor to grab the image and flash the main MCU using JTAG.  This implies the end user can download the image from the web to the SD card but that's no more difficult that downloading the image from a laptop to the product board.  I can envision a product installed on the fourth floor of a test tower (or an Atlas Missile erection tower, which I have climbed) with a long straight ladder and backstraps.  Climbing with an SD card is easier than climbing with a laptop.

I suppose you could ship the image as an encrypted .zip file and have the boot processor decrypt the entire set of files looking for the firmware image.  The end user wouldn't have access to the files and there would be little chance of having a file damaged without detection.

[NottheDan]

I can envision a product installed on the fourth floor of a test tower (or an Atlas Missile erection tower, which I have climbed) with a long straight ladder and backstraps.  Climbing with an SD card is easier than climbing with a laptop.

Though, having just an USB port and sticking a USB stick in there, waiting for an LED signal and pulling the USB stick out again might even easier than trying to fiddle that small SD card into a tiny slot and then ejecting it again, fiddling it out and putting it somewhere safe, four stories up in the air. You can at least put a USB stick on a lanyard.

[SeanB]

Well, for that application simply having a small ( easy these days) microcontroller, with a built in SPI interface, that you plug into a normally sealed socket, which then gives you power and a JTAG interface which then loads the new firmware onto the chip. 3 leds on the plug in card, power, busy and then a bicolour led for pass/fail result of programming, so you know to unplug and try again, or that the device is failed and needs replacement. You can then have some security as the target can have protect bits set which are erased with the bulk erase command, then write the new firmware, read back to verify checksum then set lock bits on it afterwards so you can only run the code on the device.

Small low cost micro ( possibly even a LCD display, but 3 lights is easier to use) with some EEprom for storing number of attempts, versions before and after and probably the built in serial numbers ( stored on the built in EEprom of the target so it is not erased with the flash) of the updated devices, so you can get a report of the updates you have done after completion.

Bespoke for sure, but can be fitted into a small package, perhaps with a built in power bank to power up the target if needed to program it with main power off.

[nctnico]

The first thing I disable on a production device is the JTAG interface to prevent (deter) copying the firmware. Secondly a JTAG interface is notoriously susceptible to interference which makes it a very bad choice for anything else than R&D use.