Well I did something stupid and managed to make my Arduino Mega 2560 Rev 3 unusable.
I was trying to learn about the bootloader and altering it to make the board appear as a HID device. So I connected up a cheap USBasp programmer to the ICSP socket nearest to the mega2560 on the board and in the Arduino 1.0 IDE selected the board (Tools -> Board -> Ardunio Mega 2560 or Mega ADK), then the programmer (Tools -> Programmer -> USBasp) and then hit Tools -> Burn Bootloader. I was trying to ensure I could restore my boardloader when I needed too.
After around three minutes the error displayed is: avrdude: warning: cannot set sck period. please check for usbasp firmware update. avrdude: verification error, first mismatch at byte 0xe000
The result is a board that times-out when I attempt to program it via the USB port (COM3 in my case) and when the board is reset it does not blink the pin 13 LED. Here’s the error:
avrdude: stk500_2_ReceiveMessage(): timeout
Things I’ve tried:
Repeating the process and re-burning the bootloader using Arduino 1.0 IDE- Same error
Re-burning the bootloader using avrdude CLI
Set the fuses: avrdude -v -v -v -v -p atmega2560 -c usbasp -P usb -e –U lock:w:0x3F:m –U efuse:w:0xFD:m –U hfuse:w:0xD8:m –U lfuse:w:0xFF:m
Burn the bootloader: avrdude -v -v -v -v -p atmega2560 -c usbasp -P usb –U flash:w:stk500boot_v2_mega2560.hex:i –U lock:w:0x0F:m
Uploading a blink.cpp.hex file (and other .hex files) using the USBasp adaptor, LED 13 does not blink code does not appear to work
Using Arduino 0023- to upload sketches and burning the bootloader (added lines to programmers.txt to support USBasp) - same errors
Loopback test- This works fine (shorted TX0 with RX0 and held down the reset button) and TX and RX LEDs flash and the board echos back what I type
Reading the Troubleshooting guide and searching the forums- I hope people can see I’ve put some effort into this before posting and that I’m new to all this. There’s lots of info and I’m at a bit of a loss as I don’t know what will and won’t work
I can still set the fuses and upload .hex files and the loopback test works so I don’t believe the board is beyond repair.
Help I’m after
Can someone confirm I’m using the correct bootloader hex file “stk500boot_v2_mega2560.hex” for the Ardunio Mega 2560 Rev 3?
Can someone confirm the fuses are correct for the Rev 3. I used boards.txt as a reference but does this cover Rev 3?
What exactly is the correct process for restoring the bootloader for the Mega 2560 Rev 3? Is there specific instructions?
The upload of the bootloader takes around 143 seconds (and same again to verify), it’s a 2K file and this seems very slow. Is this part of the problem?
From my research I’m guessing my USBasp may not support the larger memory address of the Arduino Mega 2560 Rev 3. Before I buy another programmer can anyone confirm this?
My experience using the Ardunio platform was brilliant up to this point, if anyone could point me in the right direction to fix my stuff up it would be greatly appreciated.
I can’t thank you enough for investigating this Nick.
My USBasp programmer powers the Mega 2560 R3 while programming, but to ensure it wasn’t a power issue I’ve also powered the Mega via its USB port too. No difference.
For what it’s worth here’s the last part of avrdude’s output while attempting to program.
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "stk500boot_v2_mega2560.hex"
avrdude: writing flash (262106 bytes):
Writing | ################################################## | 100% 155.82s
avrdude: 262106 bytes of flash written
avrdude: verifying flash memory against stk500boot_v2_mega2560.hex:
avrdude: load data flash data from input file stk500boot_v2_mega2560.hex:
avrdude: input file stk500boot_v2_mega2560.hex contains 262106 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 142.29s
[b]avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0xe000
0xff != 0x0d
avrdude: verification error; content mismatch[/b]
avrdude: safemode read 1, lfuse value: ff
avrdude: safemode read 2, lfuse value: ff
avrdude: safemode read 3, lfuse value: ff
avrdude: safemode: lfuse reads as FF
avrdude: safemode read 1, hfuse value: d8
avrdude: safemode read 2, hfuse value: d8
avrdude: safemode read 3, hfuse value: d8
avrdude: safemode: hfuse reads as D8
avrdude: safemode read 1, efuse value: fd
avrdude: safemode read 2, efuse value: fd
avrdude: safemode read 3, efuse value: fd
avrdude: safemode: efuse reads as FD
avrdude: safemode: Fuses OK
avrdude done. Thank you.
I was able to read it using the AVRISP Mk II which I recently purchased. In fact that gave me an excuse to fire it up, because I hadn't been able to get it to work on the Mac, so I used my Windows XP machine. It was somewhat faster to read as well than the USBtinyISP.
I suspect the programmer is to blame, that's my gut feeling.
Digi-key have the AVRISP2 for around $36. It is probably a good investment to get that, after all if you can't program the thing with the manufacturer's device there is something wrong.
My USBasp programmer powers the Mega 2560 R3 while programming, but to ensure it wasn’t a power issue I’ve also powered the Mega via its USB port too.
I needed to power the Mega separately when using the AVRISP.
Also the AVR Studio (I suggest staying with version 4) confirmed the fuse settings I posted.
What exactly is the correct process for restoring the bootloader for the Mega 2560 Rev 3? Is there specific instructions?
If I had to do it ... and after what you posted I am reluctant to put myself in the position of needing to ... I would get the file you mentioned, use the AVR Studio: Tools -> Program AVR dialog thing, and use the Program tab -> Program Flash to upload that file. I would then cross my fingers. But honestly, that should work.
Sorry Nick you are too fast. I start typing this before you posted.
I’ve also dumped the flash using your method but I’ve noticed we are using different versions of avrdude. I’m using “Version 5.11-Patch#7610, compiled on Aug 31 2011 at 08:02:19” (on a Win7 x64 PC). The file size for me was 630,759 bytes this seems too large? I’ve used notepad to compare the dumped file with the “stk500boot_v2_mega2560.hex” and if I understood anything about the addressing, I’d be guessing the USBasp is putting the bootloader in the wrong address- as you stated. The dump also appears to repeat and I’m guessing that can’t be good.
Here’s the first lines of “stk500boot_v2_mega2560.hex”:
The first thing I noticed was how different the format is, but perhaps that’s just cosmetic. Perhaps the above code can confirm that the USBasp is or is not writing to the correct addresses?
I do think I need to buy a decent programmer and toss this USBasp in the bin. My only problem with buying a AVRISP Mk II was last time I checked the shipping was going to cost me more than the device!
Right, first things first. I guess that the 20 at the start of the line is the length (0x20) being 32 bytes, whereas the other ones are 16 bytes (0x10). So that accounts for the cosmetic difference.
Also I think the next few digits are the address, and the last two a sumcheck.
Your dumped file is likely to include any code (ie. low memory) which is confirmed by the address:
As you stated the first byte appears to be the length and the last byte perhaps a checksum. I've tried various avrdude dump formats to try and made the dump directly comparable without success. I used Intel hex (:i) option. I found a trial version of "Fairdell HexCmp2" and I've attached a screen dump of a file comparison. The results don't look the same.
If I'm doing it right nope. I'm assuming you mean monitor the serial port (COM3 in my case) while powering on the Mega? Or is there a different debug method?
Using the serial monitor in IDE shows nothing on connection or reset. I can attempt to send characters and the RX LED on the board does flicker. Also on reset the pin 13 LED does not blink.
The loopback test works (tried that before posting) and the ICSP header near the Mega16U2 has not been touched.
Since the fuses looked OK I would be verifying that the bootloader "on board" agrees to the last byte with the file you had there. A verify should do that, but probably safer to compare the files as we discussed. You will need to do the line-combining trick unless you can find a way of changing the hex file.
Thanks heaps Nick. I've done that to both but diff doesn't help me as the dump is much larger (it starts at 0) and I really don't know how to use it properly.
Here's a small example: provided the addressing translates and is correct, they are the same:
From the original 'stk500boot_v2_mega2560.hex' (I've skipped the first part because it's repetitive)
Note the very different addressing 'e0e4' on the dump and '3e0e4'. Is the bootloader simply in the wrong address because of the crappy USBasp programmer?
Please note that the adafruit usbtiny isp doesn't work with devices over 64K.
You will need to use a 'real' atmel avrispmkII, an avr dragon, or an avrjtagmkII.
There is a clone of the avrispmkII that does work, this clone uses an atmega32U2 or atmega32U4 device and is based on LUFA.
andrew-d:
Note the very different addressing 'e0e4' on the dump and '3e0e4'. Is the bootloader simply in the wrong address because of the crappy USBasp programmer?
Well e0e4 just looks wrong. The Mega has 256 K of program memory which is 0x40000. Since the bootloader takes up to 8192 bytes, then the correct start address would be 0x3E000. If the programmer is putting it at 0xE000, well that would explain a lot.
So if the reported addresses and contents are right (and who knows?) then it has put the right code in the wrong place. But I think that would explain the behaviour. I would hunt around for the AVRISP MkII from somewhere that will ship it cheaply, or reasonably cheaply.
After all you need to do two things: recover this device, and do future programming the way you originally intended.
scharkalvin:
Please note that the adafruit usbtiny isp doesn't work with devices over 64K.
Thanks for your reply scharkalvin.
I'm with you. While I'm using a USBasp programmer it's probably the same issue, but I cannot find specific specs that say the USBasp cannot do it. I'm found a page showing an "ACEduino Mega 2560" and a USBasp being used but the information suggests perhaps he only performed a backup- not a restore. For those interested:
