Help! Bricked my Ardunio Mega2560 Rev 3

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

  • 0xff != 0x0d*
    avrdude: verification error; content mismatch

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.

This is what I get verifying the fuses:

avrdude -c usbtiny -p m2560 -v

avrdude: Version 5.8cvs, compiled on Jan 15 2010 at 17:27:01
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/usr/local/CrossPack-AVR-20100115/etc/avrdude.conf"
         User configuration file is "/Users/nick/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : unknown
         Using Programmer              : usbtiny
         AVR Part                      : ATMEGA2560
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    10     8    0 no       4096    8      0  9000  9000 0x00 0x00
           flash         65    10   256    0 yes    262144  256   1024  4500  4500 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : USBtiny
         Description     : USBtiny simple USB programmer, http://www.ladyada.net/make/usbtinyisp/
avrdude: programmer operation not supported

avrdude: Using SCK period of 10 usec
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9801
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D8
avrdude: safemode: efuse reads as FD

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D8
avrdude: safemode: efuse reads as FD
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Thanks for such a fast reply Nick.

My fuses match perfectly. The only difference in my output is from the USBasp programmer. So one part down, my fuses are correct.

The big one is how do I restore this board? What am I doing wrong?

This is how long it took me to read the device to disk:

avrdude -c usbtiny -p m2560 -U flash:r:mega2560_firmware.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9801
avrdude: reading flash memory:

Reading | ################################################## | 100% 487.96s



avrdude: writing output file "mega2560_firmware.hex"

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

(Over 8 minutes). So the times don't seem excessive.

The resulting file was one byte long, which is rather puzzling, to say the least.

This was using USBtinyISP. Looks like I will have to try something different. I'll get back to you.

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 do NOT appear to have the Rev 3 Mega2560, which may be important. However the start of my firmware appears to differ from the file you mentioned:

:10E000000D9489F10D94B2F10D94B2F10D94B2F129
:10E010000D94B2F10D94B2F10D94B2F10D94B2F1F0
:10E020000D94B2F10D94B2F10D94B2F10D94B2F1E0
:10E030000D94B2F10D94B2F10D94B2F10D94B2F1D0
:10E040000D94B2F10D94B2F10D94B2F10D94B2F1C0
:10E050000D94B2F10D94B2F10D94B2F10D94B2F1B0
:10E060000D94B2F10D94B2F10D94B2F10D94B2F1A0
:10E070000D94B2F10D94B2F10D94B2F10D94B2F190
:10E080000D94B2F10D94B2F10D94B2F10D94B2F180
:10E090000D94B2F10D94B2F10D94B2F10D94B2F170
:10E0A0000D94B2F10D94B2F10D94B2F10D94B2F160
:10E0B0000D94B2F10D94B2F10D94B2F10D94B2F150
:10E0C0000D94B2F10D94B2F10D94B2F10D94B2F140
:10E0D0000D94B2F10D94B2F10D94B2F10D94B2F130
:10E0E0000D94B2F141546D656761323536300041AF
:10E0F000726475696E6F206578706C6F72657220DE
:10E1000073746B3530305632206279204D4C530099
:10E11000426F6F746C6F616465723E004875683F52
:10E1200000436F6D70696C6564206F6E203D200048
:10E130004350552054797065202020203D20005FF9
:10E140005F4156525F415243485F5F3D2000415658
:10E1500052204C696243205665723D20004743437C
:10E160002056657273696F6E203D20004350552024
:10E1700049442020202020203D20004C6F7720663D
...

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.

andrew-d:

  • 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”:

:020000023000CC
:10E000000D94F6F20D941FF30D941FF30D941FF36E
:10E010000D941FF30D941FF30D941FF30D941FF334
:10E020000D941FF30D941FF30D941FF30D941FF324
:10E030000D941FF30D941FF30D941FF30D941FF314
:10E040000D941FF30D941FF30D941FF30D941FF304
:10E050000D941FF30D941FF30D941FF30D941FF3F4
:10E060000D941FF30D941FF30D941FF30D941FF3E4
:10E070000D941FF30D941FF30D941FF30D941FF3D4
:10E080000D941FF30D941FF30D941FF30D941FF3C4
:10E090000D941FF30D941FF30D941FF30D941FF3B4
:10E0A0000D941FF30D941FF30D941FF30D941FF3A4
:10E0B0000D941FF30D941FF30D941FF30D941FF394
:10E0C0000D941FF30D941FF30D941FF30D941FF384
:10E0D0000D941FF30D941FF30D941FF30D941FF374
:10E0E0000D941FF341546D65676132353630004140
:10E0F000726475696E6F206578706C6F72657220DE
:10E1000073746B3530305632206279204D4C530099
:10E11000426F6F746C6F616465723E004875683F52
:10E1200000436F6D70696C6564206F6E20203D2028
:10E1300000435055205479706520202020203D2038

And here’s the first lines of the dumped file:

:20000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:20002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:20004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0
:20006000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA0
:20008000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF80
:2000A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF60
:2000C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF40
:2000E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF20
:20010000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
:20012000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDF
:20014000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBF

And moving down in the dumped file:

:20DFE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF41
:20E000000D94F6F20D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF392
:20E020000D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF348
:20E040000D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF328
:20E060000D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF308
:20E080000D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF3E8
:20E0A0000D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF3C8
:20E0C0000D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF3A8
:20E0E0000D941FF341546D656761323536300041726475696E6F206578706C6F72657220EE
:20E1000073746B3530305632206279204D4C5300426F6F746C6F616465723E004875683FDC
:20E1200000436F6D70696C6564206F6E20203D2000435055205479706520202020203D2071
:20E14000005F5F4156525F415243485F5F203D2000415652204C69624320566572203D2033

And further down to a part that seems to begin a repeat:

:20FF200077FD04D02ED006D000201AF4709561957F4F0895F6F7909581959F4F0895A1E2DB
:20FF40001A2EAA1BBB1BFD010DC0AA1FBB1FEE1FFF1FA217B307E407F50720F0A21BB30B40
:20FF6000E40BF50B661F771F881F991F1A9469F760957095809590959B01AC01BD01CF01FF
:20FF80000895AA1BBB1B51E107C0AA1FBB1FA617B70710F0A61BB70B881F991F5A95A9F7A1
:20FFA00080959095BC01CD010895F999FECF92BD81BDF89A992780B50895262FF999FECF1B
:20FFC0001FBA92BD81BD20BD0FB6F894FA9AF99A0FBE01960895F894FFCFFFFFFFFFFFFF11
:20FFE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF21
:020000040003F7
:20000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:20002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:20004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0

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:

:20000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:20002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0

Since "FF" is "not programmed" that would appear to indicate the memory was cleared, and is now FFs. So, no great problem there.

The part to compare is the bootloader part, namely:

:10E000000D94F6F20D941FF30D941FF30D941FF36E

So I would look at what you extracted at that address.

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!

Yes that happens to me a lot. I think in this case I found a local supplier (Element14).

Forgive me I might not be following the addressing correctly.

The dumped code:

:20E000000D94F6F20D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF392

Does sort of look like this from “stk500boot_v2_mega2560.hex”.

:10E000000D94F6F20D941FF30D941FF30D941FF36E
:10E010000D941FF30D941FF30D941FF30D941FF334

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.

Yes, they look the same. Strip out the :xx (length) at the start. Strip out the checksum at the end. Wrap the 16-byte lines. You then get:

E00000 0D94F6F20D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF3
E00000 0D94F6F20D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF3

I don't know if there is an easy way but some text munging program that does that automatically should let you directly compare them.

When you start up the Mega with the debug monitor open, do you see "stkv2" appear on the screen?

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.

Try doing this:

avr-objdump -j .sec1 -d -m avr5 stk500boot_v2_mega2560.hex > somefile.txt

That disassembles it. Then do it to the code you downloaded from the board. Then do a file compare (eg. diff).

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)

   3e0e0:	0d 94 1f f3 	jmp	0x3e63e	;  0x3e63e
   3e0e4:	41 54       	subi	r20, 0x41	; 65
   3e0e6:	6d 65       	ori	r22, 0x5D	; 93
   3e0e8:	67 61       	ori	r22, 0x17	; 23
   3e0ea:	32 35       	cpi	r19, 0x52	; 82
   3e0ec:	36 30       	cpi	r19, 0x06	; 6
   3e0ee:	00 41       	sbci	r16, 0x10	; 16
   3e0f0:	72 64       	ori	r23, 0x42	; 66

From the dump (again I've skipped the first part because it's repetitive)

    e0e0:	0d 94 1f f3 	jmp	0x3e63e	;  0x3e63e
    e0e4:	41 54       	subi	r20, 0x41	; 65
    e0e6:	6d 65       	ori	r22, 0x5D	; 93
    e0e8:	67 61       	ori	r22, 0x17	; 23
    e0ea:	32 35       	cpi	r19, 0x52	; 82
    e0ec:	36 30       	cpi	r19, 0x06	; 6
    e0ee:	00 41       	sbci	r16, 0x10	; 16
    e0f0:	72 64       	ori	r23, 0x42	; 66

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.

Update: The output from my AVRISP2 also seems to start at E000 ... there must be more to this than meets the eye.

The first line in the .hex file must set the start address. The firmware file has this as line 1:

:020000023000CC

If you open up the downloaded file and add that as line 1, then disassemble it, it changes the start address:

Mega2560.hex:     file format ihex


Disassembly of section .sec1:

0003e000 <.sec1>:
   3e000:   0d 94 89 f1     jmp 0x3e312 ;  0x3e312
   3e004:   0d 94 b2 f1     jmp 0x3e364 ;  0x3e364
   3e008:   0d 94 b2 f1     jmp 0x3e364 ;  0x3e364
   3e00c:   0d 94 b2 f1     jmp 0x3e364 ;  0x3e364
   3e010:   0d 94 b2 f1     jmp 0x3e364 ;  0x3e364
...
   3e0e4:   41 54           subi    r20, 0x41   ; 65
   3e0e6:   6d 65           ori r22, 0x5D   ; 93
   3e0e8:   67 61           ori r22, 0x17   ; 23
   3e0ea:   32 35           cpi r19, 0x52   ; 82
   3e0ec:   36 30           cpi r19, 0x06   ; 6
   3e0ee:   00 41           sbci    r16, 0x10   ; 16
   3e0f0:   72 64           ori r23, 0x42   ; 66
   3e0f2:   75 69           ori r23, 0x95   ; 149
   3e0f4:   6e 6f           ori r22, 0xFE   ; 254
   3e0f6:   20 65           ori r18, 0x50   ; 80
   3e0f8:   78 70           andi    r23, 0x08   ; 8
   3e0fa:   6c 6f           ori r22, 0xFC   ; 252
   3e0fc:   72 65           ori r23, 0x52   ; 82
   3e0fe:   72 20           and r7, r2
   3e100:   73 74           andi    r23, 0x43   ; 67
   3e102:   6b 35           cpi r22, 0x5B   ; 91
   3e104:   30 30           cpi r19, 0x00   ; 0

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:

https://americanhobbyistblog.wordpress.com/mcu-development/aceduino-mega/