The new, new LUFA bootloader
Three blog posts in one week, after being so tardy in the last few months. Things are looking up!
After my last post detailing my latest and greatest abomination to the world of embedded engineering, Markus asked if I had considered making a Mass Storage class bootloader. Those are fairly common in the embedded world — the idea is that the device shows up like a normal disk drive, and you can reprogram it by dragging-and-dropping a new binary file to an emulated filesystem.
I had thought about this in the past, however somehow I never quite got around to looking into it properly. The FAT specification is one I’ve never really looked into before now, preferring instead to use the well known, proven FATFS library in my projects. Actually, I admit I previously thought it impractical on the USB AVRs, as for some reason I had it in my head that the file system had to be buffered in RAM before the new firmware was extracted and copied to FLASH. Revisiting this made me realize what a world class fool I am (hold your nods of agreement, please) when it hit me that I could just map the virtual filesystem to physical FLASH blocks.
As a result, I now have this working:
Which allows you to reprogram the AVR via a BIN file by overwriting the existing FIRMWARE.BIN file (which, when read, returns a binary image of the current FLASH contents). The emulated FAT code was actually surprisingly straightforward to write once I started reading some decent overviews on the subject, although I spent far longer than I care to admit (ok, ok, five hours) going back and forth over my code looking for a flaw, before finding out that the host OS was thinking my (valid) FAT16 partition was a FAT12 partition and becoming confused. That was the real piece of information I missed that is absolutely crucial; it’s the sector size and count that determines which of FAT12 and FAT16 the host interprets your partition size as, and not the obvious filesystem identifier string. Damn.
Actually, now that I know just how awful FAT is, I’m horrified to realize I used to store all my data on it in the 1990’s under Windows 95 and later Windows 98. It’s a terrible (if simple) filesystem where a single bit of corruption in the right place can cause horrendous data loss. I’ve no idea why Microsoft wants to patent it, since it’s…well…terrible. Objectively so.
Right now the new bootloader code is available on GitHub, if you have a device that is supported (currently just the 128KB and 64kB USB AVRs, since I need an 8KB bootloader section). Paul Stoffrogen’s made the great suggestion of remapping some of the routines to a custom section located just before the bootloader section in order to make it work on smaller devices, but I want to gauge the public opinion first. If you would really like to see a Mass Storage class bootloader on the ATMEGA32U4 or smaller devices, let me know.
In other news, my friend Morten and I went to see the local NTNU university last week, so he could give me a tour. I’ve put some photos up here, however one that stands out:
The room to the bottom-left of the main door is the Omega Verksted; the crazy place where Alf-Egil Bogen and Vegard Wollan designed the first AVR, the AT90S1200.