Go Down

Topic: Mega 2560 bootloader revised? (Read 16162 times) previous topic - next topic


We're working on testing the bootloader here: https://github.com/arduino/Arduino-stk500v2-bootloader (there's a .hex file in goodHexFiles).  It fixes the !!! problem and watchdog problem, along with a few other bugs - all corrected by Mark Sproul.

I've seen occasional failures to upload with this new bootloader, but I'm having trouble reproducing them.  Any testing of this bootloader would be a big help, particularly on big sketches. 


I used the hex file at https://github.com/arduino/Arduino-stk500v2-bootloader/tree/master/goodHexFiles and tested it under IDE 21.  The IDE really doesn't matter though since you don't compile it, just load it.  The reason for the 'almost' is because it is still being tested and has not been totally wrung out yet.

The way I loaded it was to replace the bootloader in the ide under hardware/arduino/bootloaders/stk500v2 (saving the old one of course) and then using the IDE tools->bootloader to burn it into the chip.  Then I used a couple of little test programs to try out the items that have been driving me nuts.  It worked.

I screwed up doing this the first time and loaded the wrong bootloader; second time was the charm though.


What about those of us who can't burn bootloaders? Are we just out of luck then?


No, you can get an ISP programmer and update the board or contact someone that has one and ask them to program it for you.  I  have used both the ladyAda USBTinyISP and the AVRISP mk 2 to program the board.  The lady Ada one has a problem with the bigger boards and will throw an error, but the error can be ignored and the loader will work.  Yes, I've done this about 25 times before I got the AVRISP.  There are other folk out there that have done it also.

You can also use another arduino as an ISP, there are threads here that will cover the specifics of this.  There's one user here that has modified the code to work really well for this.

But, yes, you do actually have to do something to get past the problem.


I'm just concerned about buying more equipment when I'm not even sure this is the problem. I'm having the same exact issue people are describing, but my board was working for months and then just stopped. Even if I try using the basic example sketches. I just don't understand what changed to make the Mega stop accepting uploads. Does that still seem like the boot loader is the problem?


No, not if the tiny examples aren't loading.  Things like blink should work just fine.

When it happened to me I had changed an array of data such that it introduced the three exclamation points as data.  This caused me to fail loading the board.  It took me hours to figure out what had happened.  I was even reduced to looking at a hex dump to find the darn thing.  Much later I had the compiler create code that stopped me from loading.  This time I knew what and how to look for it and found it in a little while.  After the first revision to the bootloader that fixed the exclamation points problem, I loaded it and haven't had a problem since.  I'm currently running the latest one from a few posts above and it is working fine so far, both the watchdog and the exclamation point problems.  It's been months since I had to chase down the problem, so I don't remember how I did it, but I grabbed a hex dump program and piped it through grep somehow or the other. 


More on the continuing drama of the 2560 bootloader.

I just move a lot of my code up to IDE 1.0.3 and decided to check and see if they had updated the bootloader in this.  Well, they haven't.  I just used it to program 2560 and the bootloader supplied with the release failed on both the !!! and the watchdog timer problems.

But, I went searching to see if there was some schedule and ran across another bootloader that works.  This one is smaller because the author removed the code that samples for the !!! to jump into a rom monitor.  So, there is no problem with !!! because it doesn't look for it, and the watchdog timer works.  Plus, we get a little code space back (not that it matters on a 2560).  I tested it with several things and successfully loaded code that exceeds 60K (biggest I currently have) to the board.  The hex file is at:


If you want to get it and try it.  I used an AVRISP mk 2 to replace the bootloader, I haven't tried anything else.

Here is the code I used to test the two problems:
Code: [Select]

#include <avr/wdt.h>

void setup(){

  wdt_reset();   // First thing, turn it off
  Serial.println("Hello, in setup!!!");

int firstTime = true;

void loop() {
      if (firstTime){
        firstTime = false;
        Serial.println("In loop waiting for Watchdog");
        wdt_enable(WDTO_8S);    // eight seconds from now the device will reboot
      // now just do nothing

It's annoying that they haven't updated the IDE with a version that works.  But, there are a couple of solutions that work now.

Oh, for the person that is looking for the 1280, look for an optiboot version.  I ran across several references to a new optiboot bootloader that fixes that board.


Yea, I'm running optiboot on a mega1280 board. Made a new board entry in the boards.txt file to support it. Works great but I don't recall where I found it as it was a pretty long search to come up with it, so no link. Let me know if anyone needs it and I'll post it.



(ah.  Someone attached a stk500boot hex files to one of the "issues" for optiboot, which is a completely different bootloader.  I guess that's livable.)

Mark Sproul (the current maintainer) fixed the watchdog and !!! problems in the "source repository" for stk500boot about a year ago.  That's here: https://github.com/msproul/Arduino-stk500v2-bootloader
However, the .hex files there don't seem to be updated, and for some reason the changes seem to have hit a bottleneck in getting propagated into the Arduino code repositories.

Note that updating bootloader code is always subject to "deployment issues", since most users will not be able to simply burn a new bootloader into their MEGA.  Having a new bootloader in the arduino code distribution, while there are still a number of MEGA boards in the the (hardware) distribution pipeline is a less than desirable situation.  At least with the current situation, we KNOW that if you have a MEGA and haven't updated the bootloader yourself, then your bootloader is broken in known ways...


westfw, everything you said is true.  Did you read this thread?  In the third post I called (yes, I actually talked to him) and discussed the !!! problem.  He knew nothing about the watchdog problem.  He fixed it, but compiled it wrong and it wouldn't load onto the board.  It took someone else, many months later to get a version that would work.  Then another version turned up that works also and doesn't have the very marginally useful boot monitor in it at all.

But, I want to understand what you said.  Do you think it's alright to leave a broken bootloader in the IDE release after release?

Louis Davis

See this pull request for reference:

It looks like the updated version of the bootloader will be included with the 1.0.4 release of the IDE.

The team is currently waiting for feedback to complete the merge.


I hope they can get it in place for people.  I suspect it may not make it since I haven't seen many people following up and testing the various problems.  One thing I just don't understand is why they try to fix all the bugs in the world before including something.  Being able to load a sketch to the board seems to be a big enough problem to warrant inclusion in the first available release.  So does a huge function for standalone processors like WDT.  Instead, it's being held aside waiting for a fuse read fix to be tested???

Go Up