Need help with 16U2 serial interface and DFU mode (MEGA2560)

Hi all,

Well I think I screwed up one of my MEGA R3 boards. I wanted to download the firmware from the 16U2 chip using my AVRISPMKII, Avrdude and a small script I use that reads the device and creates dump files for the fuses, the program memory and eeprom. The script is named, of course, "readhex". I also have a complementary script called "writehex".

That's where my problem came in. I connected the ICSP to the 6 pin header for the 16U2 chip and by mistake ran "writehex" instead of "readhex".

Now, the board does not show up as a serial device. In Linux, the board usually came up as /dev/ttyACM0 and I could also see the board VID and PID by using the "lsusb" command.

Now, nothing happens. The board doesn't show up in lsusb and it doesn't get assigned a serial port.

I tried to read the data from my other (good) MEGA board (being careful to use READHEX this time) and then burn that same code into the bricked board.

Well, it doesn't work, Avrdude just comes back with this error message:

avrdude: stk500v2_command(): command failed
avrdude: stk500v2_program_enable(): bad AVRISPmkII connection status: Unknown status 0x00
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

Well now what do I do? I've been reading about "DFU mode", but I don't want to mess with it until I know what I'm doing and I'm hoping for some expert guidance from here......

I wrecked my board.

Huh. That's odd. I'm fairly certain others have reported success reburning the 16U2 firmware. I believe I have even recommended it a few times. I can't recall having to do anything special.

How are you powering the target? USB port?

If the target is just connected to a USB port, does clicking the reset button run the bootloader (L should flash three times)?

DFU mode only works if the 16U2 has it's own bootloader flash still intact. If the 16U2 chip is damaged then chances of recovery is slim. But first you should be able to determine if the 16U2 is readable via ISP or not.

One thing to check is pin 1 on the 16U2 ICSP header is facing the shield headers, so make sure your programmer is in the right orientation. What is bad about the ICSP header placement is most 2x3 header cables have a key that sticks into the shield headers. I had to shave off the key on my cable to make it fit. If you are sure you have the right orientation then you should be able to at least read the m16U2 signature and fuse bits.

Reading the m16U2 on my Mega2560:

> avrdude -cavrisp2 -Pusb -pm16U2 -v

avrdude: Version 6.1, compiled on Sep  8 2014 at 19:26:57
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Documents and Settings\User\My Documents\Downloads\Arduino\arduino-1.0.
4\hardware\tools\avr\etc\avrdude.conf"

         Using Port                    : usb
         Using Programmer              : avrisp2
avrdude: usbdev_open(): Found AVRISP mkII, serno: 000200212345
         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 : STK500V2
         Description     : Atmel AVR ISP mkII
         Programmer Model: AVRISP mkII
         Hardware Version: 0
         Firmware Version Master : 1.25
         Vtarget         : 3.3 V
         SCK period      : 10.37 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9489
avrdude: safemode: lfuse reads as EF
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as F4

avrdude: safemode: lfuse reads as EF
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as F4
avrdude: safemode: Fuses OK (L:EF, H:D9, E:F4)

avrdude done.  Thank you.

If your 16U2 is readable like this then it may be recoverable. We can go thru the steps later if you can get this far.

Power for the target while trying to re-flash the firmware on the 16u2 is coming from the avrispmkii which I have hacked with a 1N4001 diode sending 5V usb power to the ICSP header (I get about a 0.7V drop of course, which gives me VTarget of about 4.3V).

I also tried flashing it with an external power supply plugged into the power connector so that VTarget was an actual 5.0 volts... made no difference.

I don't know if hitting reset runs the bootloader... never thought to look (and I can't right now since I'm at the office).

hiduino:
DFU mode only works if the 16U2 has it's own bootloader flash still intact. If the 16U2 chip is damaged then chances of recovery is slim. But first you should be able to determine if the 16U2 is readable via ISP or not.

One thing to check is pin 1 on the 16U2 ICSP header is facing the shield headers, so make sure your programmer is in the right orientation. What is bad about the ICSP header placement is most 2x3 header cables have a key that sticks into the shield headers. I had to shave off the key on my cable to make it fit. If you are sure you have the right orientation then you should be able to at least read the m16U2 signature and fuse bits.

If your 16U2 is readable like this then it may be recoverable. We can go thru the steps later if you can get this far.

Unfortunately, my 16U2 is not readable This is what I get when I try to read it:

avrdude: stk500v2_command(): command failed
avrdude: stk500v2_program_enable(): bad AVRISPmkII connection status: Unknown status 0x00
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

And I know that the ICSP connector is plugged in correctly, I have a paint pen mark on the connector to denote Pin 1 and also a dot on the board itself to show Pin 1.

I did, quite a while ago, have to cut off the keyway on the 6 pin connector because it got in the way and made it almost impossible to plug into the 16u2 header.

I even tried the "close the jumper" then "use dfu-programmer" and that didn't work either. No matter what I do, the port doesn't show up in the list of serial devices (i.e. "lsusb"). The chip may be hosed for good.

I get about a 0.7V drop of course, which gives me VTarget of about 4.3V

If the BOD fuses are set for the 16U2 that may be below the threshold (4.3V is the typical threshold for BODLEVEL = b100).

If you can, power it from something that can deliver 4.5 volts to 5.5 volts.

Edit...

I also tried flashing it with an external power supply plugged into the power connector so that VTarget was an actual 5.0 volts... made no difference.

Never mind.

:grin:

Try setting the AVRISPMKII to a bit rate of 5461 or lower. Maybe the 16U2 is running from the watchdog oscillator.

Hey THAT'S an idea I haven't tried yet... dang I have to wait another 1-1/2 hours to try it out! (still at the office!).

I'll let you know if it works.

(edit to add): didn't work.

Would the initial (accidental) write have set the fuses and disabled reset pin and ICSP?

Riva:
Would the initial (accidental) write have set the fuses and disabled reset pin and ICSP?

Well, my "writehex" script has a section where it reads the contents of "filename.efu" for the extended fuse, "filename.hfu" for the high fuse, etc... and if those are not found then default values (also in the script) are used.

The "readhex" script, of course, generates all those files when it reads a chip (all fuses, flash and eeprom).

Problem is, I hadn't put in default fuse settings for the 8U2 and 16U2 parts yet, and foolishly I didn't have a bail-out if the chip type couldn't be matched at all, so I THINK I wrote the value of empty variables (obviously 0) to every fuse.

I'm sure the chip is bricked and the only way to get it back (if it even SUPPORTS this) is to use the "high voltage" programming method. Since the chip is a BGA device, I'll have to be able to access all the pin(s) required to do a HV programming cycle (if it even supports that (which I don't know yet 'cause I haven't looked at the data sheet yet).

If that doesn't do it, then I guess I'll use the board for some SMD soldering practice.......

Going by this example (I know it's for a tiny but...) all the pins you need to do HVP apart from 1 are broken out on the 6 pin header. Maybe the other one can be accessed on the board.

Riva:
Going by this example (I know it's for a tiny but...) all the pins you need to do HVP apart from 1 are broken out on the 6 pin header. Maybe the other one can be accessed on the board.

Thanks for the info. Actually, what I tried yesterday was this: I had an old Arduino UNO that was bad (I don't remember why but I ruined it somehow by soldering on the same spots too much and not carefully enough).

Anyway I got the idea that I could remove the 16u2 from that board and put it on my MEGA board, then just re-flash it with the MEGA's serial code.

Well, for some reason it didn't work (I could read the chip, but it wouldn't take writes - strange). Maybe I overheated it with my hot air gun. It took several tries to get it aligned just right. Invariably, one spot would melt a millisecond before another and pull the chip out of alignment by 1 pin's worth in a random direction. I then had to give it a gentle nudge to get it to snap into the right spot (which it would sometimes overshoot and go 1 pin's worth too far).

I finally gave up, removed the 16U2 entirely and made a little cable to connect a Sparkfun FTDI USB to serial breakout board to the MEGA (using RX, TX, GND, 5V, and DTR).

It works fine now, so I'll just use this board first when I need to build a project where the Arduino is permanently installed, burn the code and forget about it. Problem solved (sorta).