Go Down

Topic: Boot from SD Card (Read 511 times) previous topic - next topic

rfresh737

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?

CrossRoads

Wow, what do I have to do to get word of these out there?
http://www.crossroadsfencing.com/BobuinoRev17/


Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

CrossRoads

More pics
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

kowalski

@rfresh737

How would you like this to work?

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.

Cheers!

CrossRoads

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.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

CrossRoads

#5
Oct 04, 2015, 04:49 pm Last Edit: Oct 04, 2015, 04:51 pm by CrossRoads
Quote
I think this could be done with a SD shield, LCD and ISP cable.
That's how my board started out - I took Nick's program
http://www.gammon.com.au/forum/?id=11638

came up with a neater hardware solution, and worked with Nick to add code for the display and file selection hardware.

I turned it into a cleaner solution - add a battery pack or wallwart, power switch, put it into an enclosure


Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

rfresh737

#6
Oct 04, 2015, 06:56 pm Last Edit: Oct 04, 2015, 06:59 pm by rfresh737
>How would you like this to work?

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)

rfresh737

@CrossRoads

Thanks for the info and the links...

kowalski

@rfresh737

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.

The bootloader would need a minimum configuration; e.g. SD chip select pin (D10) as https://www.adafruit.com/products/1141.

Last, the bootloader has to fit into the max size of the boot sector (ATmega328, http://www.engbedded.com/fusecalc/) 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).

Cheers!

rfresh737

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.

kowalski

@rfresh737

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.

Cheers!


backwoodsjack

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..

pert

I have successfully used https://github.com/zevero/avr_boot 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.

Go Up
 


Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

Arduino
via Egeo 16
Torino, 10131
Italy