Go Down

Topic: Help! Bricked my Ardunio Mega2560 Rev 3 (Read 18685 times) previous topic - next topic

andrew-d

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.

nickgammon

This is what I get verifying the fuses:

Code: [Select]
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.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

andrew-d

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?

nickgammon

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

Code: [Select]
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.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

andrew-d

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.

Code: [Select]

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.

nickgammon

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:

Code: [Select]

: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.

Quote
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.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

nickgammon


-   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.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

andrew-d

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":
Code: [Select]

: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:
Code: [Select]

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




And moving down in the dumped file:
Code: [Select]

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


And further down to a part that seems to begin a repeat:
Code: [Select]

: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!

nickgammon

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:

[font=Courier]:20000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:20002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0[/font]

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:

[font=Courier]:10E000000D94F6F20D941FF30D941FF30D941FF36E[/font]

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

Quote
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).
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

andrew-d

Forgive me I might not be following the addressing correctly.

The dumped code:
Code: [Select]
:20E000000D94F6F20D941FF30D941FF30D941FF30D941FF30D941FF30D941FF30D941FF392

Does sort of look like this from "stk500boot_v2_mega2560.hex".
Code: [Select]

: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.

nickgammon

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:

Code: [Select]
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?

Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

andrew-d


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.

nickgammon

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.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

nickgammon

Try doing this:

Code: [Select]
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).
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

andrew-d


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)
Code: [Select]
   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)
Code: [Select]
    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?

Go Up