Dual-boot Your Arduino

There was a time, not so long ago, when all the cool kids were dual-booting their computers: one side running Linux for hacking and another running Windows for gaming. We know, we were there. But why the heck would you ever want to dual-boot an Arduino? We’re still scratching our heads about the application, but we know a cool hack when we see one; [Vinod] soldered the tiny surface-mount EEPROM on top of the already small AVR chip! (Check the video below.)

aAside from tiny-soldering skills, [Vinod] wrote his own custom bootloader for the AVR-based Arduino. With just enough memory to back up the AVR’s flash, the bootloader can shuffle the existing program out to the EEPROM while flashing the new program in. For more details, read the source.

While you might think that writing a bootloader is deep juju (it can be), [Vinod]’s simple bootloader application is written in C, using a style that should be familiar to anyone who has done work with an Arduino. It could certainly be optimized for size, but probably not for readability (and tweakability).

Why would you ever want to dual boot an Arduino? Maybe to be able to run testing and stable code on the same device? You could do the same thing over WiFi with an ESP8266. But maybe you don’t have WiFi available? Whatever, we like the hack and ‘because you can’ is a good enough excuse for us. If you do have a use in mind, post up in the comments!

28 thoughts on “Dual-boot Your Arduino

    1. Enterprise grade network components actually allow you to do that. Ciscos have just a flash memory where you can store some firmware files. HP Procurve/Aruba switches offer primary and secondary flash storage for the firmware files. So whenever something goes wrong with your updated firmware, you still can revert to the old one without having to copy over another image.

  1. Maybe in a master/slaves context. You could maybe program all your devices the same, and then switch one to be a master easily. Can be useful if the program and/or the server programs takes more than half the flash space.
    (just a wild idea)

      1. Except that hasn’t been true in a while, when windows 8 and their app store said they wouldn’t allow ‘in-app purchases’ valve told microsoft to shove it and that they didn’t need their two-bit operating system. This is why SteamOS is a thing and Steam on linux is so big, they’re using their influence to force developers to develop for linux.

        1. Yes, but these are relatively recent developments (I do love Steam) and the article said “back in the day”, a timeframe for which the assertions of gaming sucking on linux are true.

          You’re right, but your point is irrelevant. :)

    1. There was a point where it seemed reasonable you had Dos/WFWG3.11, Win95a, OS/2 Warp, and Slackware configured to quad boot, probably with LILO unless you had some spawn of lucifer drive overlay software.

    1. As a professional software dev, you should not be debugging on your production device. If you cannot afford to have 2 MCU boards, then I would argue that you probably dont truly have a “production” environment anyway.

      A possible use for this would be an on-board backup copy, in case the primary software bits decided to rot, a little watchdog could toggle this to the backup side and reset the MCU… If the backup came online and passed a self-check, it could even reflash the “primary” from the backup? A self-healing system?

      1. I have this kind of setup on my ebike. After small bugfixes I’m often lazy enough to test them, so instead I’ll test them the next morning. But I still have to get to work somehow, so if it fails, I just have a button to restore previous working firmware. And if it works, I press another button which copies the firmware to backup area.

        Probably not “real production” by your standards, but pretty useful nonetheless.

      2. I kind of disagree. You can have a production mode and an engineering mode or a production mode and a failsafe mode. Walking an enthusiastic customer through a customizing procedure is much better than product return. Granted, you might not need two firmwares for that, just a toggle switch for the existing one.

  2. I know what it’s good for…. if you do one of those arduino arcade things and also want to do mini basic or something…. or anything else that might use similar display/input and you might like to switch. Or didn’t we see forth and lisp as other options to switch between.

  3. Synthesizing previous comments a little, how about a fail-safe system for field updatable firmware? Imagine uploading new firmware to a satellite – you don’t want to permanently update the only flash on the device, blindly assuming that the update will work correctly, because you’ll never be able to plug a serial cable into that device, ever, once deployed.

    So instead you have multiple “slots” for system software, and only update one at a time. You could have some kind of reversion system, where a failure in version n causes a reboot into n-1, and too many failures results in booting into version zero, a debug mode.

  4. if only there was a THIRD system of memory, a three-memory system with the usual RAM and FLASH but with a third bus titled program-RAM, one that wont wear-out from constant rebooting, if this project were to dual-boot into the other system every 2 mins flash wears out quick… but for once-a-week updates ect its perfect.

  5. I’m using ESP8266 with Arduino core. And I see a big use for it.
    When your primary bin is too big to flash via OTA.
    So, you keep a minimal version, as a second bin, capable to flash via OTA.
    Then, enter in second boot and overwrite the primary bin.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.