I've been searching around the internet on the topic of updating my sketch/hex file in the field via an SD card.
I'm somewhat surprised that there doesn't seem to be an official Arduino SD card reader shield that is designed to do this. There seems to be many working on this solution but many run into problems that they may or may not be able to solve.
I have also read comments by many expressing an interest in being able to update their Arduino boards in the field.
I know there is a lot of info on this subject on the internet...have I just not come across it yet? Or is it really just not on the Arduino Development team's radar?
Arduino with an SD shield. New bootloader that detects on reset if there is a SD with a new image. The bootloader would have to look for something like BOOT.HEX and read from this to burn the new application. This assumes a file system on the SD and this will make the bootloader larger. Assuming a raw block read makes the bootload smaller but a special tool is needed to write the image to the SD.
Should there be a fall-back? Or do you assume that the users has an SD with the previous image.
Last but not least, should the bootloader also support upload over serial?
A totally different approach is to make a new version of the Arduino ISP that uses an SD shield for the image. In that case an LCD is needed to browse and select the file. I think this is @CrossRoads approach, though with a special board. I think this could be done with a SD shield, LCD and ISP cable.
LCD is overkill. How many files would you send out to the field? 0 to 15? 0 to 255? Don't need an LCD for that.
You're not really "booting" from SD - you're loading a new sketch into the fielded hardware. Bootloader is not even needed - just have a card like mine (328P with SD & 3.3V buffer, voltage regulator, and display driver(s)), download the code using the equivalent of the IDE's File:Upload Using Programmer command.
Another member did a simple Serial Uploader sketch, that could be run as well with a couple jumpers to bring a DTR signal out for an autoreset function. But then your fielded hardware has a bootloader, and a user could easily hack into it and put in new code. Loading via ICSP doesn't prevent that, but sure makes it more difficult.
I thought my thread title was clear but maybe not. Whatever hex file is on the SD card, that's what gets loaded upon board start up.
Mail your customer a new SD card with an updated sketch and have them (or you if you're physically there) insert the new SD card and now they are running with updated code.
Should there be a fall-back? (No...keep it simple)
Or do you assume that the users has an SD with the previous image. (Yes)
Last but not least, should the bootloader also support upload over serial? (No)
Ok, so we are looking for a new bootloader with a SD FAT16/32 reader instead of serial. Burns the file "BOOT.HEX" if available on the SD. No serial bootloading.
Last, the bootloader has to fit into the max size of the boot sector (ATmega328, AVR® Fuse Calculator – The Engbedded Blog) which is 2K words (4K byte). And this is where we run into trouble.
Write the smallest possible SD/FAT16 sketch that opens a file, and reads it. How large is that? 6-7K. Much to large.
Write the smallest possible SD sketch that reads a raw block. How large is that? 2K. Could work.
So here is the problem with the bootloader idea in a nut-shell. A new tool is needed to write the file as raw blocks. FAT file system would take too much space without a lot of work (i.e. there is no business case for that).
What if you (or me) wrote the SD/FAT16 code in assembly language? That would be smaller but I don't know if that would small enough.
Sounds like using assembly would work for reading a raw block.
I guess the whole thing would have to be done in assembler if there were any chance at all to make it work. And even then, that might not be small enough.
I used to do 8080/8086 assembler programming a few years back. I know this chip would require different assembler code as each cpu chip is different.
No need to go so far as to assembly. It can be written in C and meet the constraints. The SD/FAT16 library can be refactored to this very specific use case. There is a lot that can be removed. Or actually totally rewritten.
My guess is that it is about 1-2 KLOC in C and maybe 2-5 times more in assembly. With some aggressive refactoring the bootloader should be possible to write in 500 lines of C (with SD and FAT support). The FAT struct definitions are hard to refactor but these are already written.
It is possible and I think that there are already a few attempts made.
this is a very old thred..
but i am looking for exactly this answer.. i would like to snailMail a SD card to my customers with a new
upgrade firmware..
i am working with mega2560 R3s in the field..
thanks for any update..
I have successfully used GitHub - zevero/avr_boot: Arduino Bootloader to Flash from SD Card for this, it is a bootloader that loads a .bin file from the SD card but unfortunately we didn't get it working with ATmega2560 yet. I'll have another try at it on the next release(or any help would be welcome) but until then there is a list of other SD bootloader options on that page under the Thanks To and Alternatives sections. I haven't looked closely at them but maybe there is one that will work for you.
