Firmware update via USB mass storage - Page 1
Forum section: electronics / general

author: Boomerang
author_rank: Regular Contributor
timestamp: November 22, 2016, 09:21:14 am
content: 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?

author: NottheDan
author_rank: Frequent Contributor
timestamp: November 22, 2016, 09:49:17 am
content: something likethis? Alsothis.

author: Boomerang
author_rank: Regular Contributor
timestamp: November 22, 2016, 11:19:32 am
content: 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 ?!

author: bobaruni
author_rank: Regular Contributor
timestamp: November 22, 2016, 01:34:04 pm
content: 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.

author: jnz
author_rank: Frequent Contributor
timestamp: November 23, 2016, 12:15:09 am
content: 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.

author: Koen
author_rank: Frequent Contributor
timestamp: November 23, 2016, 12:23:00 am
content: NXP LPC1343 have an USB-MSD bootloader, maybe others. It isn't hard nor long to program on STM32.

author: nctnico
author_rank: Super Contributor
timestamp: November 23, 2016, 01:01:28 am
content: Quote from: Boomerang on November 22, 2016, 11:19:32 amAFAIK 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.

author: Boomerang
author_rank: Regular Contributor
timestamp: November 23, 2016, 10:20:40 am
content: Quote from: jnz on November 23, 2016, 12:15:09 amThis is coolHow 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!

author: tszaboo
author_rank: Super Contributor
timestamp: November 23, 2016, 03:51:39 pm
content: 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: November 23, 2016, 04:15:53 pm
content: Quote from: Koen on November 23, 2016, 12:23:00 amLCP11U24 have it in ROM indeed. Not very stable though.Programming a bootloader isn't aneasytask. 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 linkingtwoprojects 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 thenrelyon 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.

author: nctnico
author_rank: Super Contributor
timestamp: November 23, 2016, 04:49:36 pm
content: Quote from: Jeroen3 on November 23, 2016, 04:15:53 pmI recon manufacturers of thumb drives will have the same problem in that case.

author: voltsandjolts
author_rank: Unknown
timestamp: November 23, 2016, 06:58:32 pm
content: 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.

author: Boomerang
author_rank: Regular Contributor
timestamp: November 23, 2016, 08:00:15 pm
content: I will have micro-USB port to charge the device. It's logical to use it also for the firmware updates.

author: andy1
author_rank: Contributor
timestamp: November 23, 2016, 09:43:45 pm
content: 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.

author: timb
author_rank: Super Contributor
timestamp: November 24, 2016, 12:50:27 am
content: 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.

author: zapta
author_rank: Super Contributor
timestamp: November 24, 2016, 05:08:43 am
content: Quote from: voltsandjolts on November 23, 2016, 06:58:32 pmIt 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.

author: voltsandjolts
author_rank: Unknown
timestamp: November 25, 2016, 09:03:23 am
content: 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.Quote from: zapta on November 24, 2016, 05:08:43 amHow are you implementing firmware signing - with Public Key/Private Key encryption?

author: Jeroen3
author_rank: Super Contributor
timestamp: November 25, 2016, 02:07:11 pm
content: NXP requires a signed image with a checksum of the vector table.https://community.nxp.com/thread/389046No fancy cryptography.

author: zapta
author_rank: Super Contributor
timestamp: November 25, 2016, 07:00:56 pm
content: Quote from: voltsandjolts on November 25, 2016, 09:03:23 amYes, 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

author: Jeroen3
author_rank: Super Contributor
timestamp: November 25, 2016, 07:24:28 pm
content: I have to.Quote from: zapta on November 25, 2016, 07:00:56 pmQuote from: Jeroen3 on November 23, 2016, 04:15:53 pm

author: timb
author_rank: Super Contributor
timestamp: November 25, 2016, 11:03:31 pm
content: Quote from: Jeroen3 on November 25, 2016, 07:24:28 pmThat'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.

author: zapta
author_rank: Super Contributor
timestamp: November 26, 2016, 11:34:55 pm
content: Quote from: timb on November 25, 2016, 11:03:31 pmWith your restrictions, the image file cannot include in its name metadata such as product name and version.

author: timb
author_rank: Super Contributor
timestamp: November 26, 2016, 11:56:15 pm
content: Quote from: zapta on November 26, 2016, 11:34:55 pmIn 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.hexSo, 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.

author: rstofer
author_rank: Super Contributor
timestamp: November 27, 2016, 04:27:39 pm
content: 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.

author: NottheDan
author_rank: Frequent Contributor
timestamp: November 27, 2016, 05:14:43 pm
content: Quote from: rstofer on November 27, 2016, 04:27:39 pmThough, 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.

author: SeanB
author_rank: Super Contributor
timestamp: November 27, 2016, 06:02:43 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: November 27, 2016, 06:15:09 pm
content: 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.