Flashing via SD card


I’m working on a project that would greatly benefit from being able to load .hex files off of an SD card, and then flash the ATMega chip to essentially run different programs at will.

I’ve browsed the forums for doing this, and the general concensus is that I would need to write a bootloader that reads an SD card to flash. While the Uzebox does this, I’d rather not get into that - way more than I want.

Instead, I was thinking of using two ATMegas - one which is the standard Arduino running the standard bootloader. The other loads .hex files from an SD card and uploads them to the first chip.

Is this feasible? If so, can someone point me to the protocol for serial program uploading? (I essentially want to emulate the Arduino UI upload). I read the app note on the original STK500 protocol, but it wasn’t exactly very clear, and going through the source code for the bootloader is rather confusing as well.


look up ummc sd bootloader. http://www.roguerobotics.com/wikidocs/code/bootloader_using_ummc

That will help you.


Thanks, this looks like I can hack it into doing exactly what I want.

However, it looks like that bootloader is designed to be under 4 KB, but I thought the 328 only had room for a 2 KB bootloader?

I have not looked into that but I presume it is under 2KB. As you say, the max is 2KB (well as far as I know). Not sure about the size of that one though.


Just got home to test it out. Unfortunately, the uMMC bootloader is 3450 bytes when compiled. This is fine if using an ATMega644PA (which I might do in the end anyway...), but it's far too big for the 328P.

Fortunately, I've been able to figure out the source code well enough that I think I might be able to whip up my own bootloader that will fit on a 328.

It might be just a pipe dream, but I'll keep you posted!

...but it's far too big for the 328P

Not so - max bootloader size for the AtMega328P is 4KB.

Sooo.. 2048 words == 4096 KB?

Sooo.. 2048 words == 4096 KB?

2048 words == 4096 bytes

I like the idea of this very much - but i thought you couldnt run code tat is not in a certain memory section of the atmega which is write protected? Am i wrong here?

Well you are not running the code off the SD card, rather loading the arduino up with the code that is on the SD card. Then you could remove the SD card and the code would still be running.

You are correct that you cannot run code that is not on the chip.


It would be very cool, if it were possible to choose between code-files from SD card to install into Arduino. - by pressing input button you can choose between those files and for showing what file is selected, we may use graphical display or some 7 segment dispalys or just led blinking (file no 1 is 1 blink...etc)

Insert SD card to Arduino, choose your code-file and press reset button to upload code to Arduino.

That could be easily done on the data storage boards from rogue robotics due to the file features already implemented. I considered this but I have not got round to changing my arduino bootloader to this one to let me do it yet.

This has been discussed a few times before (quite a lot recently). I still think that it would also be nice to be able to read off the SD card and program to an un-modified arduino board (standard bootloader). ;)


Actually i was also thinking about using default bootloader. If we could use the SD Card just like Arduino sofware “Arduino 0018” (but without it) - choose code and upload it. (the codes inside SD should be pre-verified/compiled)

Here is a youtube video about using SD-Card without any Shield (just some wires and resistors and SD card). - i am planning to do this.

Ugh... Yea, I meant bytes.

Well that is good then. BOOTSZ would have to be set to 00 for that, if I can remember.

Though I might still give that custom bootloader a try to see if I can make it any smaller. (the uMMC one looks like it contains two methods of uploading sketches... If I'm only going go be loading from the sd card then I could probably get rid of half the current code...

Again, I'll keep you posted.

Thanks for the help!

Not modifying the bootloader is what I had originally intended so that would be nice.

I was planning on using this in my "ArduinoBoy" project. There would be a glcd and two or three chips (possibly one for handling the display). When the device is turned on, the "programmer" chip displays a list of hex files (games in this case). The user picks one, then the "proccessor" chip gets flashed and takes control of the system.

Nice project!
I really like this part “The user picks one, then the “proccessor” chip gets flashed and takes control of the system.

Well regarding games for an arduino, I would have thought it would be much better to just have a seperate code routine for each game and a menu. If you can upload from one arduino to another it will be very slow, espeicially if the code is so big you could not fit a few of them on the ATmega chip.

If you are short of space then just go for the 644 or something. Double the space (and double the RAM etc - better for games)


In SD-Card there are many game-files (preverified/compiled). User chooses one code-file and uploads it to Arduino. Every time user wants to change to another game, he must reset and reupload from SD. I think theres no need of another Arduino... just figure out, how to upload from SD-card. To erase old uploaded script, just use reset button on Arduino board.

For graphical games, we may use some small LCD-s // or led-s + buttons (reaction time games)... led tic-tac-toe etc.

Also I was thinking, if it is possible to upload code from SD card, then how to upload libraries? Lets say there are games for LCD.... but every time when reset is being made, the old library is erased... then when uploading new game for LCD we must also upload the library.

BTW: Sorry for my messy elngish 8-)

I see what you're thinking, Mowcius, but I was going more with what D3C3PT1C0N said..

Use one chip to load up an SD card, and look for .hex files, showing those .hex files to the user (via a 128x64 graphic lcd). When they pick the one they want, it loads the .hex from the SD card and uses that data to flash the "processor" chip.

The idea behind this was that to get a new game on the thing, I wouldn't have to plug it in and reprogram it from a computer, I could just have / build multiple .hex files on an SD card and use those (and add, swap, edit, etc, at will).

As to the speed, I don't see how it can be any slower than how the Arduino currently uploads files (through UART) - those only get uploaded at 57600 baud (and only in 64 byte chunks too!)

I have considered using a 644, but a) I don't currently have any laying around, whereas I have several 328's lying around, and b) I thought it would be cool to just create standard Arduino programs, with their native libraries and everything that doesn't need to get ported to the 644.

This morning I played around with writing my own bootloader, but it didn't pan out so well (couldn't make it properly work / couldn't verify the bootloader was running, but I'll put more time into it when I actually have the time..).

What might be easier for me to do, however, is to just have code on the Arduino that "emulates" the STK500v1 protocol that avrdude / uisp use to upload.

I just found the "upload.verbose" preference, so that will make my reverse engineering of the upload process much easier.

Also, D3C3PT1C0N: I don't understand what you mean by libraries? Currently all Arduino "libraries" are compiled straight into the .hex as regular code. Are you thinking along the lines of shared object files (ala .dll's, etc)? If you are, then I don't think that's possible / feasible with embedded chips like these.

i was thinking about those that are at the beginning of a script
(like #include <Servo.h> )
When both files are in SDcard (script + Servo.h) then how to tell Arduino, that when you select a file to upload, then it must also upload that Servo.h

but compiling into “HEX” - it means that “script + Servo.h” are both inside it?