I’ve got the magic in me…
Well, given that a number of people wanted ATMEGA32U4 and smaller support for my Mass Storage class bootloader, I’ve gone ahead and implemented the linker gymnastics required to make it work. A warning: it’s pretty ugly since I had to split the text segment into a secondary “Aux” bootloader space to make it fit on the smaller devices, but that’s just details. I’ve uploaded binaries of all the bootloaders to this location, including one for the Arduino Leonardo (ground IO13 on start-up to enter the bootloader).
I’ve also gone ahead and added EEPROM support to it, so the bootloader now exposes two virtual files, FLASH.BIN and EEPROM.BIN. Magic! Special thanks to Matt over at Opendous Inc. for his assistance with getting Linux support of the bootloader working, since my initial release had a few issues with write offsets.
Now, recently with the release of the LUFA VSIX extension to the Atmel Gallery for Atmel Studio 6.1, I’m getting increasing pressure to release ported demos for the XMEGA architecture, even if the backend implementation has a few known issues. A little while back I started work on porting things over in a separate branch (called “XMEGA-Demo-Ports”, for those playing at home) which you can try out inside AS6.1 using these instructions, or standalone if you just check out the SVN/GIT.
Right now I’m weighing up the XMEGA demo port branch, and I need a public opinion poll; given that the cross-architecture demo code is a little more complicated (since it needs #ifdef checks for architecture detection and hardware detection) I’m not totally convinced this is the right direction. On the plus side, the new ported demos can be compiled as-is for both XMEGA and AVR8 with no user-changes, and can be compiled for boards that lack some of the UI hardware the current demos expect (such as buttons and joysticks). An example of a ported XMEGA demo for a Device Mouse can be found here – contrast with the AVR8-only demo here. Note the addition of the #if ARCH=... and #if defined(BOARD_HAS_...) checks.
Hi,
I just found this “Mass Storage class bootloader” and I am fascinated about getting it to work even on a small ATMEGA32U4…
Thanks for your work and for sharing this to the public.
as a beginner I just have 2 questions:
1.)
at the download location there are sets of files for one type of MC
–> http://fourwalledcubicle.com/files/LUFA/Bootloaders/
e.g.
xxx_BOOT_yyy.hex and xxx_NON-BOOT_yyy.hex
what is exactly the difference between these BOOT and NON-BOOT variants ?
2.)
the EEPROM.BIN file:
when (and how often) is it written to the EEPROM of the MC ?
Is the writing of the EEPROM performed each time (!) when booting into (or “leaving”) the Bootloader ?
(EEPROM has limited (lifetime) numbers of write actions, I think)
Hi Dirk,
1) The precompiled bootloaders are named like:
{Bootloader Name}-{Architecture}-{Device}-BOARD_{Board}-BOOT_{Bootloader Section Size}-{Crystal Frequency}.hex
Such as:
MassStorage-AVR8-at90usb1286-BOARD_NONE-BOOT_4KB-16MHz.hex
The “NONE” in most of the bootloader filenames refers to the board hardware, which in most cases is set up to be compiled for no specific board hardware (BOARD_NONE). This removes the LED flashing and other minor board specific tweaks, but gives the best compatibility. In cases where specific code is required for a board in order for the bootloader to work correctly at all (XPLAIN and Leonardo) I have board specific variants available.
2) The EEPROM is written any time the virtual file is updated. That means on most sane operating systems, the EEPROM will only be altered if you overwrite the virtual file. Of course if you write to it in a tight loop with a fsync() call you’ll wear it out quickly, but just mounting the disk should not alter the EEPROM or shorten its lifespan.
Hi Dean
Great job on the mass storage boot loader!
My question is: do you think that this can be run on a device without hardware USB, such as ATmega328, using firmware USB emulation such as v-usb?
Thanks
Hans
Unfortunately not Hans – the software USB implementations only implement Low Speed USB, which doesn’t support the bulk type endpoints required by the Mass Storage class to make the bootloader work.
– Dean
Hi,
is it needed to pull the “(#HWB)PE2” (Pin33) of the Atemega32U4 to ground for jumping into the MSD-Bootloader on power-on-boot or after hardware-reset (via Pin 13 “!RESET”)?
My project has no user interface* at all,
*(neither hardware nor software)
and I would like to have the following behaviour:
USB-cable not plugged in (detected on “VBUS” Pin 7):
– hardware-reset: start the normal firmware in flash
– power-on-boot: start the normal firmware in flash
USB-cable plugged in:
– hardware-reset: jump into the MSD-Bootloader
– power-on-boot: jump into the MSD-Bootloader
is this possible ?
Sure, this is possible – you can just edit the bootloader code to check for USB power on start-up, and if not found jump to the application software. Then all you have to do is change your device fuses to always start from the bootloader (BOOTRST=1) and not check the HWB pin state (HWBE=0) so that the bootloader always runs first to determine what mode needs to be entered for each reset.
Cheers!
– Dean
Could you provide some advice on how to create the FLASH.BIN from an Arduino build? I’ve tried using…
avr32-objcopy -R .eeprom -O binary xxx.elf xxx.bin
I copy that BIN file to the bootloader storage device and reset the 32u4 but the bootloader just runs again.
Thanks,
Tim
Hi Tim,
Try:
avr-objcopy -O binary -R .eeprom -R .fuse -R .lock -R .signature xxx.elf yyy.bin
– Dean
[…] of controller – quite tedious. I needed a bootloader and I found one. It’s called USB Mass Storage Bootloader and it’s really fantastic. After you reboot your board into bootloader mode, your PC shows a […]
Hi,
is it planned to have a atmel gallery version of LUFA that is usable for the new “atmel studio 7”
(you can not load the current version into atmel studio 7)
–> https://gallery.atmel.com/Products/Details/96acf4c2-4d70-471b-847b-136568300b8d
Absolutely – I actually just set up my new PC’s development environment tonight with AS7, Visual Studio 2015 and all the dependencies needed to rebuild Atmel Studio extensions. The only missing piece of the puzzle is the AS7 SDK, which isn’t available yet. Once that’s made available by Atmel I can make up a new integration binary that doesn’t crash inside the new VS shell.
– Dean
2019 here. I couldn’t even build atmega32u4 configuration now with NONE/32/4 settings no matter I try. Also poor choice of PIN for Leonardo, people mostly use Pro Micro now and IO13/PC7 is not even broken out, so I can’t even use prebuilt ones. Could you please rebuild bootloader for Pro Micro using double reset or something, as on Adafruit boards?