next topic »

[Reply #15 on:]

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.

[Reply #16 on:]

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.

[Reply #17 on:]

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

[Reply #18 on:]

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

Code:

:020000023000CC

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

Code:

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

[Reply #19 on:]

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/

[Reply #20 on:]

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

Eeek! I ordered a real programmer (Atmel AVRISP mkII) last night hoping this would fix my problem. Perhaps its the board or MCU. Anyway the programmer won't go to waste.

[Reply #21 on:]

I think it probably will fix the problem. There have been quite a few reports of things that work fine on the smaller boards (the Atmega328 ones) which don't work on the larger ones due to addressing issues.

After all, you've done nothing obviously wrong here.

[Reply #22 on:]

After all, you've done nothing obviously wrong here.

Except mess with the bootloader when I didn't quite know what I was doing. Perhaps avrdude/something could test the programmers and ensure they can program the complete memory address range of the device before allowing programming. This would stop or slow down clowns like me from destroying their bootloaders.

I have a Arduino Uno - R3 on it's way and I'm likely to receive it before the real programmer (Atmel AVRISP mkII). I'm considering using as a ISP (eg http://arduino.cc/en/Tutorial/ArduinoISP) and trying to read the flash on the Mega only. But I might just get myself into more trouble with the Uno. The document I've read only talks about uploading bootloader from Uno to Uno.

I really appreciate your time and effort on this Nick, if nothing else hopefully this thread might serve as a cautionary tail for others.

[Reply #23 on:]

I think it probably will fix the problem. There have been quite a few reports of things that work fine on the smaller boards (the Atmega328 ones) which don't work on the larger ones due to addressing issues.

Being restless I dusted off an EPROM programmer (MCUmall GQ-4X) I had to discover it does AVR ISP. The GQ software does not list the Mega2560 as a supported device so I tried the Mega128 and dumped the contents. I found the bootloader twice in the dump at two different addresses (0000 E000 and 0002 E000) - nether of them at the end of the address space.

I also found that the programmer is USB native (I think this was one of the reasons I bought it), it does not install a com port and avrdude could not find it. So I was stuck with the GQ software. I tried modifying the "device.txt" and copied and modified the entry for the Mega128, I renamed it and increased the code size to 262144 and added a device ID. Reading contents seemed fine and there was no sign of the bootloader in the correct address (should be 0003 E000?). Feeling confident I loaded the "stk500boot_v2_mega2560.hex" and hit the write button not really knowing the fuse state. The write worked and the "Verify Failed, Address=0x01E000, Device=0x0D, Buffer=0xFF". I'd assumed it didn't work again.

Upon disconnecting the programmer I discovered the L pin 13 LED started to blink. Had I breath life back into this thing? Or was there a different problem like a hardware fault or the bootloader looping? Anyway it seemed like progress. I plugged the Mega 2560 in via USB and attempted to upload a sketch. It worked! I reconnected my LCD module and tried another sketch it worked without fault. I'm very happy.

So the moral of the story is:

• Don't assume just because it's easy to pick in the IDE menu that it won't render your Arduino board difficult to recover (or impossible without a different programmer)
• Don't assume that $2 eBay/Deal Extreme/GoodLuckBuy programmer can restore your bootloader especially on boards with larger flash memory
• If you cheap out on a programmer you might spend hours trying to work out what's going on- buy a decent one
• Assume any programmer can erase your bootloader regardless of the limited size it can read/write
• AVRdude does not seem to tell you what your ISP can and cannot do- dumping first might give you some idea
• Failing verification does not mean it didn't work, disconnect programmers and test boards

Things I still don't fully understand:

• Why does it appear the bootloader is in more than one memory location?
• Why didn't something stop me or warn me a little better about irrecoverably wiping bootloader (at least with the USBasp I have)?
• A check of the programmers capabilities and it's appropriateness to the board you're trying to program might have prevented a clown like me doing this

Thank you Nick for all of your time and effort. I owe you one.

[Reply #24 on:]

Why does it appear the bootloader is in more than one memory location?

My guess here is that you tried a number of different things (eg. install bootloader from the IDE, install from avrdude) and they failed in different ways (the ways being the incorrect address).

As for the rest, congratulations on sticking with the problem solving. Many people would give up. I suspect that the cheap programmers are not necessarily fully tested on every board, and who wants to advertise that their board doesn't work with some things?

Probably the AVRISP will work simply because it comes from the manufacturers and they - if no-one else - has a vested interest in being able to program their own chips.

[Reply #25 on:]

My guess here is that you tried a number of different things (eg. install bootloader from the IDE, install from avrdude) and they failed in different ways (the ways being the incorrect address).

About the duplicate bootloader- I gained more confidence with the programmer and board so I tried to get the verify to work. I performed an erase (doesn't most programming do this?) and verified the erase. Everything was filled with ‘FF’ and it worked without reporting any errors. So I reprogrammed the bootloader and again the verify failed. Again I dumped the contents and again found the bootloader in two locations. 0001E000 and the correct one 0003E000. The board tested and worked without fault. I don’t really care because the board works but it would be nice to better understand this stuff.

On an earlier post you found the bootloader in an unexpected address- could your board also have a duplicate bootloader?

Your right about programmers and from what I’ve read the firmware in the USBasp can be upgraded (program the programmer), it would just prevent a whole lot of trouble if avrdude or something could test the limitations of programmers and inform users. But this ordeal was really my own silly fault.

Anyway I’ve learned lots from the experience.  Thanks again Nick.

[Reply #26 on:]

This exchange gave me the confidence to try restoring my 'bricked' atMEGA2560.  Using Atmel Studio v6.1 programmer tool and a avrispmkII programmer, I located the file "stk500boot_v2_mega2560.hex" in my arduino/bootloaders directory.  After feeding that to the programmer and writing it to the atMEGA2560 board, I fired up the Arduino application and sent the Blink application to the board ... I now have a happy, blinking LED!

My thanks to both of you for your previous efforts!

Now to try ONCE AGAIN to install Amforth on the atMEGA2560.  Knowing that I can recover from a bad programming session, perhaps I'll prove successful, at some point, in getting the Amforth development system up and running! 

[Reply #27 on:]

That's great news mpicco. I hope it helps out more people and serves as a bit of a cautionary tail for beginners (like me).