Mega 2560 refuses to respond - bootloader problem?

Using Arduino IDE 1.x
1

Good afternoon everyone.

I have a Mega 2560 (with a RAMPS 1.4 shield) controlling a 3D printer. The board was running Marlin firmware fine - the motors the Mega was controlling were all working as intended. I believe a wire physically pulled a fuse on the shield, and something...bad...happened.

A MacBook (OS X 10.7.5) that was connected to the Mega at the time shutdown (possibly from current rushing to the USB port?). At that point, I could no longer connect to the board using the laptop as a few moments before. I tried another computer (an iMac), thinking the laptop may have been the issue, but there were no devices were created in the /dev directory after connecting the Mega (note: this second computer did not have Arduino IDE installed, but that wouldn't make a difference, unless I'm missing something). I booted my MacBook to Linux Mint, and there were still no devices created in the /dev directory (also no Arduino IDE installed).
I ran through the troubleshooting guide, which states:

Make sure there's a bootloader burned on your Arduino board. To check, reset the board. The built-in L LED (which is connected to pin 13) should blink. If it doesn't, there may not be a bootloader on your board.

The L LED doesn't light up when I press reset, but the power LED stays on steadily. Does this mean that the memory containing the bootloader may have been corrupted? Is there anything else I could do to test the board since in will not connect to the computer?

Thanks in advance for any help.

2

To add... I've also tried the loop-back test as stated in a sticky in this forum to no avail. I suppose the Mega is gone. What would have caused this? Could a rush of current corrupt the boot loader?

Also, I am getting another Mega. I know there are ways of reloading the bootloader onto a dead board. Is there anything I can do just with the two Megas and some jumper wires (e.g. without a special programming board)?

3

It is a genuine mega? I had a lot of bad experiences with chinese ones, very unreliable. The way I get these cheap ones to work is flashing the bootloader on the 8u2 and atmega (using a $3 usd avr programmer from ebay and the 2 2x3 pins connectors) and then loading the sketch. It works properly for a few loads.

With the 1280 and 2560 genuine ones I never had any problem. But the price difference is massive so for a semi-permanent setup I just test in the genuine and then use the clone for the final upload.

4

It was a genuine 2560. This was my first experience with any Arduino, so I'm sort of clueless. However, the replacement will probably be a Chinese knockoff. I almost bought a knockoff first in case something like this happened...

For $3, the avr programmer sounds like it's more than worth the tiny investment if it fixes the board.

Do you have a clue what could have caused the problem or what could prevent it from happening again? With most devices I've dealt with, I've only had bootloader problems during flashing or something similar...not during usage.

5

I can't say, I have a similar setup running for years now (old makerbot with mega2560). If is not detected by the pc (trying other usb cables/ports) in any mean, that can be a dead 8u2 or 16u2 (the small one near the usb).

6

Just a thought, would using DFU mode to re-install the firmware have a chance of working? Or is using a programmer board the only way to go here?
(I'm will probably get a programmer board anyway, but just trying to see all my options while learning).

7

If you can switch to DFU, the chip is still alive so that's good. If not, the programmer (you can use another arduino too, the cheap programmer is just a convenience) can load the fw with dfu and serial again, if the chip is alive.

If you need the programmer for less than $3 hahah:
http://www.icstation.com/product_info.php?products_id=1432
Code:erwics
Discount Amount: 10%

And this is useful: http://www.icstation.com/product_info.php?products_id=2196

8

Well, as far as I could tell, the chip never entered DFU mode. However, I should have a replacement Mega 2560 waiting for me when I get home. The first thing I'm going to do is try to revive my first one.

Am I correct in thinking I will follow the Arduino as ISP guide, BUT instead of wiring as pictured, wire the pins as stated in the ArduinoISP example sketch?

// pin name:    not-mega:         mega(1280 and 2560)
// slave reset: 10:               53 
// MOSI:        11:               51 
// MISO:        12:               50 
// SCK:         13:               52

In other words, I'd wire from pin 53 to 53, 51 to 51, etc. instead of using pins 10-13.

Then, I'd just

  • select Tools > Programmer > Arduino as ISP
  • upload the ArduinoISP example sketch to the working board like any other sketch
  • click Tools > Burn Bootloader

Also, am I correct in assuming the "Burn Bootloader" menu item flashes the currently unusable board with a fresh boot loader? I mean it sounds too easy after everything I've read.

I don't want to sound like I'm getting my hand held through this, but I really don't want to end up with two boards I can't communicate with. By the way, thanks for all the great help so far, eried.

9

Okay, last night I tried to use a replacement Mega to revive the old one.
Here is the wiring scheme I used. I don't think there were any problems with that

However, when I go to burn the boot loader, I get this error:

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x1e000
         0xff != 0x0d
avrdude: verification error; content mismatch
avrdude: Send: Q [51]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [10]

Again, I don't know, but it looks to me as if avrdude is sending the messages faster than the Mega's software can respond. I know a lot of other people have had problems using the Mega as an ISP, but many were saying the problems were alleviated by either the new IDE or adding a capacitor. Is there something else I'm missing?

If you want more detail, here is the complete output of one of my attempts to burn the bootloader.

10

Remember that the mega has 2 programmable chips, there are 2 connections, the one near the mega2560 is the one where you upload the bootloader, the other needs the serial+dfu firmware

11

So, on my Linux machine, avrdude doesn't complain when verifying after uploading the bootloader, but the rest of the output looks almost identical to what avrdude on my Mac says. There's still nothing happening on the first mega, though.

eried:
Remember that the mega has 2 programmable chips, there are 2 connections, the one near the mega2560 is the one where you upload the bootloader, the other needs the serial+dfu firmware

Am I trying to upload the bootloader wrong? Do I need to connect to the board over the ICSP pins instead? I'm becoming more lost the more information I read.

12

I am just saying the ICSP near the usb port is for the 8u2/16u2 and the other one is for the mega2560. The bootloader goes into the 2nd one. The first one: http://arduino.cc/en/Hacking/DFUProgramming8U2

To fix mine, I use avrdudess and that cheap avrasp, first plugging it into:

Without connecting the usb or power (only the power provided by avrasp)

Then:

673×517 34.3 KB

(This is if the serial port isn't working properly)

Later on, if the serial port is present but I can't send a Sketch, use this other connector with the avrasp:

Now:

Wait 1-2 mins and the board starts to blink and everything is ready.