HELP REQUIRED!! Arduino Mega not being detected by the computer

Hello All,

I am using an Arduino Mega 2560 R3 (along with RAMPS for building a Prusa i3). So after building it, on powering it on, things worked fine for a while with the motors moving randomly and the arduino being detected as well. However, next time I powered the setup on for calibration, the Arduino board was not getting detected on the computer. I removed the RAMPS and tried to plug the Arduino individually (through USB port), but no success. The Power LED, pin 13 LED , RX and TX LEDs are glowing continously. However, the computer (Windows 7) does not detect the board anymore. When I say "does not detect", I mean that it does not give "Unknown device" error nor does it make a plug-and-play sound. I cant find any devices added in the "device manager".

From a bit research we found out that some of the reasons could be: 1. Either the voltage regulator has burnt out 2. The USB chip has fried 3. The firmware has been corrupted.

Can anybody help us in providing a direction from where and how to start in singling out the correct reasons and possibly how to fix it? Is there a way to find out the possible reason on the basis of status of LEDs? Anyway to debug this?

Thanks in advance for your time and help.

P.S. 1. I am an electronics novice, so please be easy on me :-) 2. There is no abnormal heating in the board which some posts suggest could be a sign of burned up components.


  1. Plug it in with a new/different USB cable.

  2. Plug it into another computer and see if you get at least as much as the plug and play sound or unknown device.

Hello dmjlambert,

Thanks for your reply. I have tried these steps: 1. Tried connecting using different cables. Result: Still not detected. 2. Tried connecting on a different laptop. Result: Still not detected. 3. Tried connecting another board (my previous Arduiino UNO). Result: UNO gets detected.

So this rules out faulty cables. And since my UNO is getting detected on my both laptops but not the Mega 2560, I figure the problem is not with the the USB or my computer.

It looks like either of these has happened: 1. Either the voltage regulator has burnt out 2. The USB chip has fried 3. The firmware has been corrupted.

Can you please help out in confirming any of the above?

I suggest restore the firmware on the ATmega16U2 USB-to-serial chip. This is my recommended method:

Hi dmlambert,

I tried updating the firmware using a method read in some other forums. Nick Gammon’s method . That is also referenced in your instructables’ post.
It looks like it was able to successfully upload the firmware (Have attached the log).
However, when I connect the target board (Mega) to the PC, it fails to detect.

Is there a step I am missing?

If you feel that trying your method over Nick’s could be given a shot, then I can totally try it.
I see that in your most you’ve mentioned something of the effect that the other firmware was more of a complete firmware.

Could that be the reason?

Also I should probably mention that I had tried putting the board in DFU mode, so could that have a part in it?

NickBootloader.txt (2.54 KB)

You uploaded the log showing you loaded the bootloader onto the ATmega2560 using Nick's sketch. So, I am kind of confused, because I thought we were talking about the ATmega16U2. Can you post a photo of your Mega board?

@dmjambert, I am sorry for any confusions. I am new to all this and learning it along.

In brief, My Arduino Mega 2560 is the board that is not being detected in my computer. The Arduino Uno is detected fine, on the other hand.

So as suggested I am trying to load the firmware onto my “Arduino Mega 2560 R3”. And I am trying to do it using my Arduino Uno as an ISP

Attaching the image.

And many thanks for your help and patience with a novice :slight_smile:

Ok,here's the deal. You can't say "the firmware" for that board because it has 2 processors. One processor is the USB-to-serial chip which is the small square chip near the USB port, and it has a 6-pin ICSP header you program it with. It needs the USB-to-serial firmware. It is probably an ATmega16U2 but you should look on it with a magnifier to verify.

The other processor is the ATmega2560 and it is the larger square chip in the middle of the board. It has a separate 6-pin ICSP header to program it with.

If the USB part of your board is not working, you would start with trying to restore the image of the ATmega16U2 using its ICSP header.

Nick's bootloader sketch will load the bootloader on it, and then you would still have to download DFU software to finish putting the USB-to-serial program on it. There is nothing wrong with using Nick's sketch and then upload the USB-to-serial program using a DFU program. Some people prefer to do that.

Or you can use the method in the link I gave you, which loads both the bootloader and the USB-to-serial program onto it all in one whack. The instructable is for restoring an Uno's ATmega16U2. There is mention in it about choosing the Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex file instead for the Mega board's ATmega16U2, and all you would need to do is make adjustments in the procedure a little to restore your board.

@dmjlamber What you posted has helped me immensely in starting to have a better understanding of things.

I would be needing a bit more help though. Here's the pin mapping I had used (from Nick's page):

Arduino Uno Target Mega2560

D10 (SS) Reset D11 (MOSI) D51 D12 (MISO) D50 D13 (SCK) D52

Gnd Gnd +5V +5V

I realize now this was for ATmega2560 and for Atmega16u2, I need to map ICSP 2 (the one near the USB port)on the target (Arduino Mega 2560 in my case) to the ICSP 1 (the other one) on the programmer board (UNO in my case)

You see, I dont have a lot of male-femae pins right now with me, so I cant connect the ICSP headers with them. So if you could help me with what would be the pin mapping (like above), that would be great.

There is no equivalent pin mapping for the 16U2, you must use the ICSP pins. It sounds like you need to get some supplies...

Oh Okay. Thanks.

Did'nt get the connectors in the electronics stores here. So order a few online. Lets see when the connectors turn up.


Okay, so I tried your method using the Arduino IDE and it just gave an error "Problem uploading "

SO I copied the command and executed in "command prompt".

avrdude -C ../etc/avrdude.conf -v -v -v -v -patmega16u2 -cstk500v1 -PCOM38 -b115200 -e -Ulock:w:0x3F:m -Uefuse:w:0xf4:m -Uhfuse:w:0xd9:m -Ulfuse:w:0xff:m

The result was: "ser_recv(): programmer is not responding"

repeated about 10 times.

I searched on various forums about the solution to this and most of them said to press "reset" simultaneously when executing the command/uploading the firmware.

I tried pressing "reset" at different combinations: simultaneously, "just after uploading", just before uploading", "along with plugging the USB".

But none helped.

Then, I came across this post:

And tried the steps under "Test the Atmega16U2 chip"

And I got the message : "Failed to enter programming mode. Double-check wiring!"

So it appears that it is indeed fried.

Would you suggest e another test just to make sure before I order another Arduino?

And indeed if its fried, if possible, can you suggest me wany possible reason why this could have happened?

I don't think any avrdude command line with a setting like -b115200 could possibly have anything to do with the burning bootloader function of the IDE so not sure where you got that command line. The IDE preferences has an option to show verbose output during upload, and that will show you the command line used during the burn bootloader attempt. There is no reset button involved with doing ISP programming. I think it is likely all the problems you are having are related to not having the wiring correct, not having the Arduino as ISP sketch loaded on the Arduino you are using as programmer, or not having the auto reset disabled on the Arduino you are using as programmer. If you follow the instructable closely, I think it is likely to work. Step 3 shows the wiring.

Here are the steps I followed (please note I am trying to restore firmware on Atmega16u2 of my Arduino Mega 2560, using my Arduino UNO as ISP programmer):

First, I created the custom boards.txt file (attached).

Then I launched the Arduino IDE and:

  1. Connected my Arduino UNO to the laptop.
  2. In the ARduino IDE, selected port 38, as the port, “Ardunio/Genuino UNO” as Board", and “AVR ISP” as programmer.
  3. Opened the ArduinoISP sketch from the file menu.
  4. Clicked on “Upload”

The sketch got uploaded successfully. (Attached the log for that “ArduinoISP.txt”)


  1. I connected the boards to each other using the image in your “instructables” tutorial.

  2. Connected the Arduino UNO to the USB port on the laptop.

  3. The IDE still has “ArduinoISP” as the selected sketch. DOnt know whether this comes into pictuure or not, but I did not do anything to it: neither closed it nor opened any other sketch.

  4. In the ARduino IDE, selected port 38, as the port, “MEGA Atmega16U2 Restore Firmware” as Board", and “Arduino as ISP” as programmer

  5. Selected the “Burn Bootloader” option.

This gave an error “Error while burning the bootloader”. Here’s the complete output:

C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega16u2 -cstk500v1 -PCOM38 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0xf4:m -Uhfuse:w:0xd9:m -Ulfuse:w:0xff:m 

avrdude: Version 6.0.1, compiled on Apr 15 2015 at 19:59:58
         Copyright (c) 2000-2005 Brian Dean,
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : COM38
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
         AVR Part                      : ATmega16U2
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC6
         RESET disposition             : possible i/o
         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    20     4    0 no        512    4    128  9000  9000 0x00 0x00
           flash         65     6   128    0 yes     16384  128    128  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 : STK500
         Description     : Atmel STK500 Version 1.x firmware
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0xffffff (retrying)

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0xffffff (retrying)

Error while burning bootloader.
Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0xffffff
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.

avrdude done.  Thank you.

Since the output windows has verbose on, it showed the command executed. So I copied the command and added 3 more “-v-” flags to get more output, and executed it manually on the command window.
It gave the same error (attached error.txt)

I have checked multiple times to make sure that I am not making any mistakes, but the output is the same always.

I have double and triple checked the wiring to ensure that everythings correct.
Only doubt I have is:

  1. Could be that my entried for Arduino Mega could be wrong (its the last section in the attached boards.txt)
  2. In the console output, the executed command looks like:
C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega16u2 -cstk500v1 -PCOM38 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0xf4:m -Uhfuse:w:0xd9:m -Ulfuse:w:0xff:m

I am not sure, but it does not show anywhere the “Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex” as any parameter.
Could that be something?

boards.txt (25.9 KB)

ArduinoISP.txt (4.7 KB)

Error.txt (7.74 KB)

That procedure and the output your are getting looks fine up to the point where you get “Device signature = 0xffffff” which usually indicates a problem with the wiring. Can you upload a photo of the wiring?

Later on in the process if you get a correct signature out of the target chip, the avrdude command will run again with the Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex as a parameter. The first avrdude command it runs it is just trying to unlock and erase the chip, and that is the command that is not working right.

I am using connected wires i.e wires of different colors hacked together to form connectors.
SO aim not sure whether the photo of the wiring will help you.
However, I am attaching these in the hope that if you enlarge the images to the max, then you can make out the connection.

Sorry for the untidy wiring pictures :frowning:

Before doing possible firmware fixes, try doing resets on the 2560. I've found my board to sometime not reset correctly. I believe it is the 16U2 chip because the 2560 will be running my application( I have a display and can see it booted ). I've noticed that the 16U2 is on a crystal, rather than a resonator like the processor. From past experience with processors, I've seen cases where if the crystal has too high a Q, it will take too long to start oscillating at full swing. This can cause the processor to come up in odd states as it needs a clean clock to initialize it self. Looking at the schematics, I don't see a reset capacitor on the 16U2 reset2. It might help to have a small capacitor on it. Dwight

Hey Dwight, thanks for your reply. But I am a complete electronics-novice here. So I could not wat tose tins meant . Like oscillating at full swing, crystal etc?

Also you said :"Looking at the schematics, I don't see a reset capacitor on the 16U2 reset2. It might help to have a small capacitor on it."

Were do I ave to put the capacitor?

Take the led off of pin 10, just connect pin 10 of the uno directly to the reset pin of the atmega16u2 which is the top left pin on the icsp header. You may need to make your connections better and neater, and for that you would need 5 female to female jumpers and 1 male to female jumper.