Bricked another arduino mega. How? How do I recover it?

Development Tools IDE 1.x
1

Actually it was a seeeduino mega but the same problem I experienced with an arduino mega a couple of weeks ago.

Everything was working great. Made some changes to my sketch -- it's a little over 40000 bytes --and uploaded it. Now all that happens is the LED on pin 13 flashes EXTREMELY rapidly. Can no longer upload to the board. Problem persists even if I unhook all external circuitry from the board.

I'm not drawing a lot of power for external circuitry from the board -- maybe about 150ma tops. The external hardware comprises a WIZNET ethernet board (not the shield), a couple of magnetic card readers (8 ma/ea) , 8 M95512-W SPI EEPROM chips, a Maxim real-time-clock chip,a few LEDs and some push buttons.

I'm an experienced hardware and embedded processor software engineer (40 years) so I'm not making a newbie mistake here. I've been working with Arduino megas for about a year now with no problems. Written dozens of (complicated) sketches. Designed a circuit board using a Mega1280 processor, laid it out with Eagle, and had a dozen made. Burned bootloaders in all of them and installed code in them with and without the bootloader.

Tried burning the bootloader with my USBTinyISP. Appeared to succeed -- actually got the same error I always get when burning mega1280 chips. Still has the rapidly blinking pin13 light after the attempt.

Bootloader report:

USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
USB write error: expected 128, got -116
avrdude: verification error, first mismatch at byte 0x1f000
         0x0c != 0xff
avrdude: verification error; content mismatch

This is crazy. Any ideas as to what's happening here and what I can do about it? I can't keep buying new boards every couple of weeks.

2

Hard to say without a schematic to look at.

Byte 0x1f000 = decimal 126976. How much memory do you have there?

3

Its an atmega1280 so that would be 128k

4

Seems odd that your 40,000 bytes would be running up against where your bootloader would be.

5

What does the memory map of the program memory flash look like?

6

Not 100% sure, but I thought the program memory started at 0 and went up, and the bootloader was at the top of memory.
The Boot Loader Support section of the datasheet has more details - I haven't looked at for the 1280 device.

7

Crazy!
You're right on the bootloader location.

What's crazy is that the thing started working again. I unhooked the +5v connection between the Seeeduino and my protoboard to measure the power consumption of my external stuff. I was close - it measured 147ma. When I hooked it back up and powered it up again (its running on USB power) the pin13 LED was no longer rapidly flashing but in the slow blink of a new board. I was able to upload my sketch with no errors and its running fine. The only thing I notice is that a bunch of configuration info that I had programmed into the Mega1280 EEPROM had been corrupted and everything was running on their defaults. I assume that the bootloader upload did indeed work and the EEPROM was reset in the process. But why unhooking the power connection to the protoboard and putting it back made a difference I have no clue.

Thanks for your help.

8

Even more crazy! I pulled the Arduino Mega that had exhibited the same problem a couple of weeks ago out of the drawer and hooked it up just for grins. It was no longer doing the ultra fast pin 13 blink thing. I couldn't upload to it so I again uploaded the bootloader with my USBTinyISP. Got the same error in the same place on the bootloader burn BTW.

Anyhow it worked and I can upload and run sketches on it again.

That board had the fast blinks for DAYS every time I plugged in the USB cable with nothing else connected to the board.

It's almost like someone healed it by laying on hands......

Roy

9

I unhooked the +5v connection between the Seeeduino and my protoboard to measure the power consumption of my external stuff. I was close - it measured 147ma. When I hooked it back up and powered it up again (its running on USB power) the pin13 LED was no longer rapidly flashing but in the slow blink of a new board.

This sounds a lot like the "amnesia" problems seen in the optiboot bootloader on Uno, caused by not initializing the "known zero" register (R1) before using it to clear the watchdog timer (as a result, watchdog timeouts occur when they shouldn't, or don't occur when they should, preventing the bootloader from starting the user sketch.)

But as far as I know, the 1280 and 2650 use an entirely different bootloader that shouldn't have this problem. (are you using the standard bootloader? You probably want to omit any "-nostartfiles" switch from your link command if you're building your own; the minimum bootloader size on 1280 is big enough that this shouldn't be needed, and it is what prevents the registers from being properly initialized.)

I'm not quite sure how to suck the bootloader out of the chip to confirm...

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1293529218/37#37

10

If a 1280/2560 (or any other chip for that matter) is really bricked AFAIK the only way to get it back is with high voltage programming.

Given that it's well nigh impossible to removed and reprogram the chip maybe an HV adaptor could be made. I think all the pins are available on various headers, you would just have to isolate RST because that gets 12v under HV programming.

I suppose there would still be the usual contention issues depending on what's connected to the various pins.

Rob

11

BTW, I claim that if the pin13 LED flashes continuously, the chip is not "bricked." A lot has to be working for that LED to be flashing...

12

After a quick glance at the Mega schematic it seems that all the pins needed for HV programming are not dedicated to any function on the Mega. So by adding jumper to RST (even that may not be required) it should be quite practical to HV program an on-board 1280/2560.

So there's a project for a bright young lad.

Rob