ATmega16U2 chip caught fire

[Old-Grey]

The 16U2 exploded on my MEGA2560. The MEGA was controlling a car EFI shield and some large current decided to GND through the USB into a laptop that was being powered by the same car battery.

I don't have much experience and don't know what I'm doing - only 2 years as a hobby - so I search errors, and what I can think of, and this is where I'm up to.

Not knowing what a 16U2 was - I found out latter it was a micro - I soldered in a new one.
I plugged it into a PC and nothing in Device Manager.
More reading and I found out it needed a driver so I loaded one - it says libusb0 - and now it sees it as ATmega16U2 device in Device Manager, but not as a MEGA driver in COM.
After more reading it looked like the 16U2 needed firmware so I used FLIP to load "MEGA-dfu_and_usbserial_combined.hex" - it was the only COMBINED listed in the IDE install that worked - on the chip, and now it comes up as MEGA on COM20.

Going to IDE it seams to see it - Board Info comes up -, but it doesn't seam to actually communicate.
I tried to load Blink, but it says :-

Code: [Select]

avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer

More reading and I try the Loopback test, and whatever I type in Serial Monitor comes back to the box below. I assume that the 16U2 is doing what it's supposed to do.

Any ideas what to try next.

I'm not good with technical terms or aberrations because I'm a relative beginner

Thanks

[sterretje]

If you managed to literally blow up the 16U2, you might also have damaged other components. In this case the main micro (2560) might also be gone to heaven.

The message that you get seems to indicate that the boot loader in the 2560 is not responding. You can try to burn the boot loader again via ICSP, but I would throw away the board as I would no longer trust it.

[Old-Grey]

I'm banking on it just being the 16U2 because it is the only thing with a crater in it   , and that that is the shortest path to GND, but yeah I was also thinking about the MEGA2560 IC. By coincidence I have another chip from something that fell through   .

That gives me something to look at, even though I don't know much about it.

I was playing with the ICSP on the 16U2, so I have minutes of experience   , but I remember reading that the MEGA2560 IC also has another ICSP near it. Will do some research and see what happens, because I have plenty of time and no $  .

[sterretje]

The ICSP for the 2560 is roughly in the middle of the board.

[Old-Grey]

Damn now there is a problem.

After more reading, some failed attempts, and more mucking around, I used Arduino as ISP through a UNO and the IDE reported that the bootloader loaded into the MEGA2560. I also noted the LED started a slow blink. I assume it worked.

Next I got a blink sketch and moded the blink time down to 100, but when I tried to upload through the USB I get a fail.

Code: [Select]

avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer
An error occurred while uploading the sketch

Had an idea to check the 2560 chip by uploading a blink sketch through the ISP, and more reading, it seamed to work because the LED blinks very fast.

If the 16U2 loopbacks, and the 2560 programs, I'm thinking something between them is blown.

EDIT
I did it all again, set Arduino to ISP, set COM to UNO COM, directed it to the MEGA, Burn Bootloader and IDE says ok and the LED does the slow blink. Plug in MEGA, set to MEGA COM, change to USBasp, upload fast blink and it fails to load.

[sterretje]

There are two resistors between the USB-to-TTL chip and the 2560 chip, one for RX and one for TX; maybe one of them? Although I think that it's a far fetch, you can check them.

I think that you also took out the serial port on the 2560. Measure the voltage on the RX and TX pins; they both should be high if there is no serial communication.

Load (via ICSP) a simple serial sketch to write the serial port and check with serial monitor. If it works, the TX is fine and you can concentrate on RX.

If it does not work, you can measure the TX pin again. A scope would be useful for that but a multimeter might indicate an average voltage of around 2.5 volt if you e.g. continuously send a byte with the same number of zeroes and ones (e.g. 0xAA).

To test RX, you might want to use a terminal program that can send files to the Arduino. Use a big file (containing binary 0xAA; you probably need an hex editor to create it) and repeat the test now measuring the RX pin.
 
If needed, you can find a link to the schematic on the product page.

[Old-Grey]

I was thinking about that in my sleep last night    about whether you could loopback the 2560 chip itself, before I start trudging through Eagle files that I don't understand.

The 2560 has a few TXs and RXs, but I think the ones I want are pin2 RX0 and pin3 TX0. I will have to read what you said a few times before it sinks in  , and do some more reading, and we will see what happens.

EDIT
RX0 and TX0 show 5V

I checked quad resistor pack RN4 and all 4 show 1K. I even tried pin8 on the 16U2 to pin3 on the 2560 and it was 1K, and pin9 16U2 to pin2 2560 and 1K. Looks like they are connected.

I don't know if this is right, but I Arduino as ISP through a UNO on COM 18, short 2560 pin 2 to pin3, start Serial Mon and type letters in, and it outputs square box symbols in the SM. Even with not shorting pin2 to 3 it outputs squares. I tried another MEGA2560 and it puts out rubbish, so maybe that's normal?

[sterretje]

On a Mega board, RX0 and TX0 are on board pins 0 and 1.

To test the Mega TX functionality, you can load the following code in the Mega (adjust baudrate to your needs).

Code: [Select]

void setup()
{
  Serial.begin(57600);
}

void loop()
{
  Serial.println("Hello world");
}


Place a wire between the reset pin of the Uno and GND; this keeps the Uno's main processor in reset and the Uno acts as a USB-to-TTL converter.

1)
Connect the grounds of the Uno and The Mega and next connect both to the PC so they are powered.
2)
Connect TX of the Mega to TX of the Uno.
)
Open serial monitor on the Uno's COM port.

You should see hello world continuously coming in on Serial monitor if the Mega's TX is still OK.

[Old-Grey]

I thought I bricked this thing but finally got that sketch uploaded - the ISP connect wiring on the Ard site doesn't work -.

More mucking around and yes I see the Hello World streaming. Yay

Back to a USB upload and I set MEGA2560, COM20, USBasp, upload Blink, see the TX LED light, watch it hang, get upload error.

Does that mean I'm in trouble, because the 2560 TXs, the 16u2 seams to loop, and there is a verified connection between both chips with a DMM yet no USB upload.

EDIT
I open Serial MON with only the MEGA connected, and only using it's USB, and got a stream of garbled characters. I try all the speeds and finally at 500000, and I suddenly get Hello World. What does that mean?

EDIT EDIT
I try for another USB upload but this time Burn Boot through ISP first, because I think it needs that for USB upload. Again timeout.

I don't know where we are at, but the only thing we don't know is if RX works.

[sterretje]

I miss the exact poit what you did with your "edit edit".

You uploaded the bootloader via ICSP? And it timed out?

I don't know where we are at, but the only thing we don't know is if RX works.

I also don't know as I don't have the faulty board.

Below a short sketch that you might be able to use to test RX

Code: [Select]

void setup()
{
  Serial.begin(57600);
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, HIGH);
  delay(3000);
  digitalWrite(LED_BUILTIN, LOW);
}

void loop()
{
  if(Serial.available()>0)
  {
    Serial.read();
    digitalWrite(LED_BUILTIN, digitalRead(LED_BUILTIN));
  }
}

Use the Arduino as USB-to-TTL adapter. Set serial monitor to "no line ending". Any character that is received should toggle the pin 13 led (of/off/on/...). Send one character, the led should switch on, send another character, the led should switch off.

[Old-Grey]

The EDIT EDIT is that I Burn Bootloader through ISCP first, and then try to load a Blink through the std USB.

I had a thought last night, did I firmware the wrong hex to the 16U2?

I'm getting Hello World through USB with Serial Mon at 500000, but I don't remember any MEGAs at 500000 std. So is it actually communicating through the USB but doesn't understand it because it's the wrong speed.

Is "MEGA-dfu_and_usbserial_combined.hex" the correct one?, because there is a bunch of hex files to choose from in the IDE install.

[sterretje]

I have no idea about the files, sorry.

Guess that I'm out of options, sorry again.

[Old-Grey]

The README say to use that one, but only mentions 8u2. It could be old and not be about the 16u2 - I assumed all MEGA are 16u2 but maybe old ones were 8u2 - because there are other hex files in :-

Program Files(86)/Arduino/hardware/arduino/avr/firmwares/atmegaxxu2

These
Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex
Genuino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-R3.hex
and the one I used
MEGA-dfu_and_usbserial_combined.hex

If that is for the 8u2 I think I try the top one.

EDIT
Trying different 16u2 FW made no difference, even though the Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex is weird because it shows 1kb.
I might try your RX sketch next

EDIT EDIT
Tried your RX sketch through the USB and every entered character makes the RX LED flash. It doesn't toggle but I think that's probably ok.

Everything(TX, RX) is coming through the USB, so it's proven to all be connected. The only thing that might be weird is the baud rate of 500000.

[Old-Grey]

I've just realised you meant the on-board LED latching on.

So the RX LED blink is my command going through the 16u2, and since we know the RX track is connected to the 2560 from the DMM the on-board LED not latching means the RX on the 2560 is blown, because the sketch in the 2560 is not reacting.

Oh well, mystery solved.