Mega 2560 bootloader revised?

Progress !!!

Careful with those exclamation marks :slight_smile:


Rob

Ok, got a chance to test it. I used a USBtinyISP and loaded the file indicated above. With the test sketch:

void setup(){
  Serial.begin(57600);
  Serial.println("Hello World !!!");
}
void loop(){
}

The new bootloader loaded and executed the file just fine. However, the sketch:

#include <avr/wdt.h>

void setup(){

  wdt_reset();   // First thing, turn it off
  wdt_disable();
  Serial.begin(57600);
  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
}

this one loaded and then hung up in a loop. I had to power down and reload a new script after holding the reset button until the compile finished to get the board back.

looking around I came across these two pages.....

http://code.google.com/p/arduino/issues/detail?id=392
http://code.google.com/p/arduino/issues/detail?id=459

anyway. on the 392 link is a fix for the firmware which stops the !!! bug.

so people you can request the code from the developer, or patch your own local code, compile and burn a new hex file.

Yes, that will probably work for the "!!!" problem if you want to get into the bootloader code and hope you can figure out where to put the changes. The link I posted above GitHub - arduino/Arduino-stk500v2-bootloader: STk500v2 bootloader for AVR 2560 and otherchips also works for the "!!!" changes and is a hex file that you can just burn to the board.

I have tested this hex file quite a bit, but it may still have problems since, to the best of my knowledge, I'm only one of two people that has. I'm currently running this file on a 2560 that is in service, doing stuff.

Remember though, this hex file and the links you cited don't do a thing for the watchdog timer problem. We're still waiting on that.

I've been using the bootloader above extensively and have encountered zero problems loading the 2560 board. However, this bootloader doesn't fix the watchdog timer problem and the board WILL hang up in a loop until you power cycle it; nope, reset won't do it. I have been using timer three as a pseudo watchdog, but I hate having to use up one of my timers for this when the watchdog is there. So, I was reading another thread on this board and came up with a solution. It's not as elegant as a simple watchdog, but it works and also allows a watchdog timer of virtually any length. The code is below, and following the example, you can have as short or as long a watchdog timer as you need and not tie up one of the other timers. This will probably work on the 1260 and lower boards as well (I haven't tested it on other boards). Now, I don't have to wait for the developers to fix it anymore.

So, use it in good health and have fun.

#include <avr/wdt.h>

unsigned long resetTime = 0;
#define TIMEOUTPERIOD 5000             // You can make this time as long as you want,
                                       // it's not limited to 8 seconds like the normal
                                       // watchdog
#define doggieTickle() resetTime = millis();  // This macro will reset the timer
void(* resetFunc) (void) = 0; //declare reset function @ address 0

void watchdogSetup()
{
cli();  // disable all interrupts
wdt_reset(); // reset the WDT timer
MCUSR &= ~(1<<WDRF);  // because the data sheet said to
/*
WDTCSR configuration:
WDIE = 1 :Interrupt Enable
WDE = 1  :Reset Enable - I won't be using this on the 2560
WDP3 = 0 :For 1000ms Time-out
WDP2 = 1 :bit pattern is 
WDP1 = 1 :0110  change this for a different
WDP0 = 0 :timeout period.
*/
// Enter Watchdog Configuration mode:
WDTCSR = (1<<WDCE) | (1<<WDE);
// Set Watchdog settings: interrupte enable, 0110 for timer
WDTCSR = (1<<WDIE) | (0<<WDP3) | (1<<WDP2) | (1<<WDP1) | (0<<WDP0);
sei();
Serial.println("finished watchdog setup");  // just here for testing
}


ISR(WDT_vect) // Watchdog timer interrupt.
{ 
  if(millis() - resetTime > TIMEOUTPERIOD){
    Serial.println("This is where it would have rebooted");  // just here for testing
    doggieTickle();                                          // take these lines out
//  resetFunc();     // This will call location zero and cause a reboot.
  }
  else                                                       // these lines should
    Serial.println("Howdy");                                 // be removed also
}


void setup(){
  watchdogSetup();
  Serial.begin(57600);
  Serial.println("Hello, in setup");
}

int firstTime = true;

void loop() {
  if (firstTime){
    firstTime = false;
    Serial.println("In loop waiting for Watchdog");
  }
  if(millis() - resetTime > 2000){
    //doggieTickle();  // if you uncomment this line, it will keep resetting the timer.
  }
}

edit: Yes, yes I know all about the millisecond timer rolling over. That is left as an exercise for the student.

This problem is very, very near being resolved. There is new source and a hex file that works; I tried it.

So, those of you that have been working around this problem will soon have a solution available. However, the existing boards won't fix themselves, you'll have to burn a new bootloader on the board. The latest software fixes both the exclamation point problem and the watchdog timer problem.

Hooray !!! (the exclamation points are intentional)

That's certainly good news. Are we waiting for an official announcement and code clean up or is what you have been testing the done deal? What makes it "very near being resolved", versus actually done?

Have any links you can share? Hex files, etc? Will this be as simple as burning a new boot loader or will the IDE environment need to change too?

We're working on testing the bootloader here: GitHub - arduino/Arduino-stk500v2-bootloader: STk500v2 bootloader for AVR 2560 and otherchips (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 Arduino-stk500v2-bootloader/goodHexFiles at master · arduino/Arduino-stk500v2-bootloader · GitHub 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:

http://code.google.com/p/optiboot/issues/attachmentText?id=50&aid=500005000&name=stk500boot_v2_mega2560.hex&token=wYbxgcUg2eOVF841vNLu2xsd2Kg%3A1360548051878

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:

#include <avr/wdt.h>

void setup(){

  wdt_reset();   // First thing, turn it off
  wdt_disable();
  Serial.begin(57600);
  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.

Lefty

(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: GitHub - msproul/Arduino-stk500v2-bootloader: STk500v2 bootloader for AVR 2560 and otherchips
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?

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