Flashing a sketch from SD card using 2boot bootloader

well done osbok! it works with Arduino ethernet
thanks for your contribution!!

I put the code up on github. I need to add more doc, improve the makefile, etc but it's there for use now.

Note: The original author at elm-chan.org published this under a very liberal open source license, so this is legit.
I hope to find his/her actual name so I can at least give credit.

I also forked the code on Github GitHub - mharizanov/avr_boot: Flash Arduino from SD card

My modifications are:

  1. only re-flash if the sketch has changed. the original bootloader flashes everytime, this is not so good.
  2. to achieve the above, I discarded FAT12 compatibility (who uses fat12 anyway)

[edit] for the future I plan that the bootloade reads the firmware name from EEPROM (default will still be "app.bin") so that will allow the applicatiom to re-flash with needed portions by itself.. neat
Also, I will make .HEX compatibility since the .BIN is additional step that isn't really needed

Do you want to work together on this?
I have code for doing the hex file (from my bootdrive project) but I'm wondering if it's worth the space. It's only a small simple command to convert it.

I was going to try to squeeze it down to either:

  1. get it out of the 4k bootloader zone (into at least the 2k zone)
  2. add back serial programming. The Optiboot code is very small and should be easy to integrate (I ported it into my bootdrive code)

Yes, that would be great. I have doubts about the 2K target, I'd rather focus on fixing the 2boots if we go in that direction. I guess it is something really small that is missing to get it working.

My ideal bootloader will have these features, in order of importance:

  • SD card flashing (only if new file is uploaded)
  • EEPROM based firmware file name
  • Serial programming
  • .HEX rather than .BIN
  • 2K

With the EEPROM based firmware file name, the application may switch itself to a TFTP sketch that will run for 20 minutes and revert back to the original application. The TFTP will wait for incomming connection and if found will save the uploaded file to the SD card (new firmare)..

i also have the code for loading from eeprom EDIT: I mean: the code for reading the filename from eeprom

:smiley:

Cool. Can we agree to use one github? We can all be contributors, or we could designate one master and do forks/pulls.

Martin, I like the load only if new, and would incorporate that right away. The LED thing should be under ifdef with some defines to make it board dependent.
I have an idea how to handle this in the makefile (similar to 2boots).

I think it will be best to do it this way. As I am less experienced, I suggest you take the lead.

Hi guys,
I agree to make a colaborative github, also, I would like to give an other chance to the 2boots code. I sent a mail to the main developer of 2boots explaining our problems. I still waiting for an answer...

But 2boots is based in another code => MMC/SD Bootloader fΓΌt ATMega16 - Mikrocontroller.net and this one might work for FAT16, if works, we will have 2K extra for including all this stuf!!

This is great.
Martin, I added you as a collaborator to

Eudaldcp, what's your github id?

I spent a lot of time on 2boots, and actually got about 50% done rewriting it using the sdfat library code. It was really hard to debug. I'm hoping that changes when I get the Dragon I ordered (allows breakpoints.)

hold off on putbacks to the repository until I branch (to preserve the current working version.)

Ive just created an account. My ID in github is: eudaldcp :slight_smile:

OK, you are added. WE can probably take this offline to github, unless they are general ideas you feel others would be interested.
I created the v.1 branch which nobody should touch (putback to master)
Later today I'll draft some groundrules. Basically if you are confident with your change, you can put it back directly. If you want a review, it is best to fork the repository, and then do a pull request.

Also, if you have "application specific features" that aren't of general use, you should probably just put those in your own fork. You can have as many as you want.

Hi to everyone, interesting thread.

I've a lot of problems to let it working.
I'm using an arduino ethernet board
4gb Microsd sdhc, partitioned to only 2gb fat16 formatted.

I've dowload the code from here :https://github.com/osbock/avr_boot/downloads

I've compiled and flash fw into my board making only little modifications at the file provided then i've put a app.bin sketch file named in the root of sdcard.
Nothing happen, after reset, app.bin fw not loaded, i can see only the board led (in my board connected to pin9) always on.

Any suggestion?
Thanks in advance.

Did you set the chipselect?
It's been a while since I tried this and some folks have made some changes. I'll try to look and see if I can see anything obvious. Unfortunately I don't have an arduino ethernet to test

No i've not set any chipselect.

For what Board that fw is ready TO go?
It's possibile that problem come from sdhc card?
Thanks again tor your time.

By default it's set up for Arduino Ethernet (someone else tested it, though I emulated it with a specially wired sd holder)
I think your problem might be that it is looking for the program name in eeprom. It is supposed to default to app.bin, but I'm not sure that's tested.

You are trying to load a binary file right? this firmware doesn't read hex files.
This was a feature that someone wanted, but I think I'm going to revert back to a fixed filename. Your program could always rename another program to app.bin .

Sure i try TO upload a bin file, not an hex .

I thought that this bootloader does not read filename from eprom but it is already made fixed to app.bin.
I need to see deep the code...

Little update:

i've let it working flashing directly this hex file for bootloader : http://baldwisdom.com/data/ArduinoEthernetSDBoot.hex

In wich is different from the code on github?

Thanks again osbock.

Hi, I am very interested in this project and I would like to get involved. In addition make it compatible with the 2560. Can someone tell me where it currently stands what the latest builds are etc?

I am using a 2560v running at 8Mhz so the whole board is running at 3.3v so I have no level shifter. The SD card is connected directly to the SPI lines.

My board is one of these with an W5200 Ethernet module attached. (Same way as the W5100)