What next? Mega2560r3 ATmega16U2 DFU Win8 USB

The short version: www.arduino.cc is out-of-date, Mega 2560 Rev 3 info is spread across creation, RESET does not blink LED "L", Blink won't upload, and I'm stuck.


The TL;DR version:

I'm writing this out of frustration with hope that it might save others some time, and that someone (hint, hint) will review and update the "official" web pages that are supposed to "help."

Here's what I have:- Windows 8 OS (yucch)- GIGABYTE GA-B75M-D3H motherboard (8 USB 2.0 and 4 USB 3.0)- Arduino Mega 2560 rev 3

Before plugging anything in, I went to the Official Getting Started page. Read the whole thing top-to-bottom. I noticed that Step 4, Installing Drivers does not mention Mega. Hmmm. And it does not mention Windows 8. Double Hmmm.

Here's what I recall to the best of my frazzled ability:

  1. Follow steps 1, 2 and 3. After I plugged the board in, green LED comes on... good. It's labelled ON, not PWR, but I can cope with that. What's this yellow LED by the ATmega16u2 chip, though? Labelled "L". Schematic isn't much help: PWM 13 is low? Thanks for that info. (see step 11)

  2. Reading Step 4, I expected a driver installation process to begin, and a port to appear called "Arduino UNO (COMxx)". Ok, maybe it would say "Arduino Mega (COMxx)" instead. Nada. No dialogs, no nothin'.

A peek at Device Manager shows "ATMega16U2 DFU" in "Other Devices", with yellow exclamation. Properties shows no device drivers. Okay...

  1. I tried to load the 2560 drivers in the 1.0.3 distribution, from the "drivers" subdirectory. (right click -> Update Drivers -> Specific Location -> Have Disk -> Browse). Oh, the driver isn't signed. Read this.

  2. Booted with "Install unsigned drivers" allowed, and the wizard reports the driver "Could not start (Code 10)". Really? Now there's an entry in Ports for "Arduino Mega 2560 R3" with a yellow exclamation mark.

  3. google, google, google, google... read Troubleshooting guide. Could be cable? Swapped. Uninstall, reinstall, No change.

  4. Could it be the FTDI drivers? Step 4 said "not the 'FTDI USB Drivers' sub-directory", but I think that meant don't use them for the main processor. They're for the FTDI USB interface. Ooo, the VCP drivers from FTDI (CDM 2.08.24 WHQL Certified) are nice and signed. They install successfully, and Device manager shows a new entry "ATmega16U2" under a new class "Atmel USB Devices". No yellow exclamation mark, and its properties look good. (I think... it may have had "DFU" in the name. Also, that entry in Device Manager disappeared when I successfully installed the 2560 driver in step 11 below.)

  5. Tried installing the 2560 driver again. No joy. The 2560 entry has the same yellow exclamation mark, and no COM assignment. google, read, google, read...

8 ) Here's an excerpt from the Programming section from the Official 2560 Description:

The ATmega16U2 (or 8U2 in the rev1 and rev2 boards) firmware source code is available in the Arduino repository. The ATmega16U2/8U2 is loaded with a DFU bootloader, which can be activated by:- On Rev1 boards: connecting the solder jumper on the back of the board (near the map of Italy) and then resetting the 8U2.- On Rev2 or later boards: there is a resistor that pulling the 8U2/16U2 HWB line to ground, making it easier to put into DFU mode. You can then use Atmel's FLIP software (Windows) or the DFU programmer (Mac OS X and Linux) to load a new firmware. Or you can use the ISP header with an external programmer (overwriting the DFU bootloader). See this user-contributed tutorial for more information.

I wonder if the ATmega16u2 chip is in DFU mode? Why would a new board be in DFU mode? Whatev. I'll reload it with FLIP as suggested. What exactly should I reload into the ATmega16u2 chip? google, read, read... Obviously the firmwares from the dist down in the firmwares subdirectory. According to the README, I should load MEGA-dfu_and_usbserial_combined.hex, although Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex is notable.

9 ) In FLIP 3.4.7, I choose ATmega16u2 from the Select Device, choose USB from Communications, then load MEGA...hex. I seem to recall having some "invalid address" errors pop up. I tried to Read the device and got all FFs. After that, I think I was able load the hex file.

  1. In FLIP, I press Run and it performs the Erase, but fails to Program. (I forget the error.) I decide to try the steps manually: Erase, OK. Run again (maybe Erase unchecked). It works. Whaaaat? After that, I think the entry in Device Manager changed slightly, maybe to add the COM3 port assignment. I seem to remember a "Device protect is on." error at some point. Sorry.

  2. Back in Device Manager, I try to load the 2560 again, and it works! In Device Manager, there is a new Port entry called "Arduino Mega 2560 R3 (COM4)". Finally! However, I had forgotton to delete the bad 2560 device, so I do it now. I also notice that the Device Manager entry for "ATmega16u2" has disappeared!

  3. Back to the "Getting Started" guide, I perform step 5, Launch the Arduino app. Under Tools, I select COM4 and 2560 board. Under File, I load Examples -> 01.Basics -> Blink. The infamous Blink. From the code, I see a comment that "Pin 13 has an LED connected on most Arduino boards". So... I guess that would be the yellow LED labelled "L" attached to PWM13. Gotcha. (Do I hear a collective "duh" in the force? As if a thousand facepalms happened at once?)

  4. I press Upload, and it compiles and says

Binary sketch size: 1,632 bytes (of a 258,048 byte maximum)

Then it begins to upload. I notice the "RX" light blinks ON for 5 or 6 times, then the Arduino app status box says:

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

If I hold the SHIFT key down when I press Upload, I only get one error message:

avrdude: usbdev_open(): did not find any USB device "usb"

Hmph. I expected more from a verbose mode. google, read, google, read...

  1. Perhaps the auto-reset isn't working for my board. I'll try connecting pins 5 & 6 on the ICSP connector to do a reset. As the Troubleshooting Guide says, "[press the reset button at] different intervals of time between the two, up to 10 seconds or more."

With an interval of 4 seconds (too late?) I got this message:

avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: ser_send(): write error: sorry no info avail

I notice that I can't upload again, because there is no COM4 port any more. Resetting the board removed the 2560 COM port from Device Manager?!? Oh, the "ATmega16U2" reappeared in Device Manager under "Atmel USB Devices". Unplugging the USB and plugging it back removes the 16U2 and restores the 2560 COM4 entries in Device Manager. What?

  1. The Troubleshooting Guide says

"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."

When I connect pins 5 & 6, LED "L" does not blink. I guess I don't have a bootloader, but danged if I know why not.


Final Questions:

Q1: In the menus for Arduino.exe, I see there's a choice for programmer. Mine is currently set to "avrisp mkii". Is that correct?

Q2: I wonder if I need to force the HWB line to ground before going back to step 8 and re-loading MEGA...hex? Incidentally, this is what my RESET-EN trace looks like:

Is the trace under the mask? It doesn't look like it has been cut, but I'm not sure it was there to begin with.

(14) I'll connect those two during an upload... Oh well, no difference.

(15) This seems to suggest that an old avrdude may be the solution... However, the old avrdude complains about programmer id "wiring".

Perhaps I'm stuck (like many others) at the "timeout" issue. I just got to experience all the problems in one sitting. =( I'm most suspicious of its reset behavior: "L" doesn't blink and the entries change in Device Manager. :astonished:

Thanks in advance for any clarifications or suggestions,
/dev

There is no FTDI chip on the Mega2560 (any version).

That's why there is a ATmega16u2. It replaced the FTDI FT232.

Q1: In the menus for Arduino.exe, I see there's a choice for programmer. Mine is currently set to "avrisp mkii". Is that correct?

Only if you are using "Upload Using Programmer" which you don't normally have to do. And if you have that particular programmer.

I wonder if the FTDI chip is in DFU mode? Why would a new board be in DFU mode? Whatev. I'll reload it with FLIP as suggested.

What FTDI chip? To be honest, I would have asked here before you started erasing the code on the USB interface chip.

When I connect pins 5 & 6, LED "L" does not blink. I guess I don't have a bootloader, but danged if I know why not.

Why are you connecting pins 5 and 6?

I'll try connecting pins 5 & 6 on the ICSP connector to do a reset.

Isn't there a reset button?


I'm bemused by this post. They ship thousands of these boards. You shouldn't have to go through all this rather complex process.

I guess I don't have a bootloader, but danged if I know why not.

Where did you buy this board from?

This page:

http://www.arduino.cc/en/Guide/Troubleshooting#upload

says:

The Arduino Uno and Mega 2560 use standard drivers (USB CDC) provided by the operating system to communicate with the ATmega8U2 on the board.

Duh, in loading "FTDI" drivers on win8 to communicate with the ATmega16u2, I incorrectly associated FTDI with what's on the board. :blush: FTDI is on the PC. ATmega16u2 is on the Mega 2560. Thanks for that!

I edited the OP to keep from cornfusing any other readers. "Stupid" can't be fixed, while "ignorance" can. I hope I'm the latter; my OP certainly is. :wink:

Cheers,
/dev

See this post for DFU mode:

The short answer is that if your 16U2 came un-programmed, there is a good chance the 2560 is un-programmed as well.
So even if you are able to reprogram the 16U2, you still need to figure out a way to program the 2560.

I would take it back and see if you can get a replacement.

Thanks, I wondered when I saw the two Upload choices in the File menu.

I wonder if the FTDI chip is in DFU mode? Why would a new board be in DFU mode? Whatev. I'll reload it with FLIP as suggested.

What FTDI chip? To be honest, I would have asked here before you started erasing the code on the USB interface chip.

Right, see reply to James above. :blush: The Device Manager originally said "ATmega16u2 DFU", but now it just says "ATmega16u2".

This page says:

The Arduino Uno and Mega 2560 use standard drivers (USB CDC) provided by the operating system to communicate with the ATmega8U2 on the board.

This is actually an example of the mish-mash of product references in the Guide. A different chip is on Rev 3. And if the chip is in DFU mode, Windows won't see it as a COM port device.

Correct me if I'm wrong, but I think that the (unsigned) Mega 2560 driver for Windows expects to find an "appropriate" board plugged into one of the COM ports. And the COM ports are controlled the standard drivers. However, if the ATmega16u2 is in DFU mode, you'll need the FTDIchip.com drivers in order to load the ATmega16u2. Then the board will be recognized as a COM port device, and you can load the 2560 driver.

I'll try connecting pins 5 & 6 on the ICSP connector to do a reset.
When I connect pins 5 & 6, LED "L" does not blink.

Why are you connecting pins 5 and 6?

Isn't there a reset button?

Umm... er... is this the reset button? :blush: I thought that was just hooked to one of the digital inputs, because when I pressed it, nothing blinked. The screened "RESET" is partially obscured by the button case. Yeah. Plenty of facepalms goin' on out there...

I guess I don't have a bootloader, but danged if I know why not.

Where did you buy this board from?

Digi-Key. I'm starting to wonder if this unit was returned from someone more ignorant than me. Is that even possible? :smiley:

I'm bemused by this post. They ship thousands of these boards. You shouldn't have to go through all this rather complex process.

This experience certainly wasn't what I expected. I'm not new to the field, but I am totally new to the Arduino product line. At the risk of looking foolish, I decided to document what an newb might go through. After all, I'll never be a first-time Arduino user again. Maybe it will help clarify something in some other newb's mind.

I do think that the Windows VCP drivers from FTDIchip.com and the Arduino.cc driver signatures under Windows 8 ought to be addressed in the official pages, though. It would have been nice if the official pages were duplicated and tailored for each board, rather than having to skip sections and go to other pages for all the info.

So. I still have a board that doesn't blink "L" when reset. Any opinions on what to try next? I'm leaning towards making sure the ATmega16u2 is properly loaded. The FLIP process was fraught with oddness. Other suggestions, anybody?

Thanks again,
/dev

However, if the ATmega16u2 is in DFU mode, you'll need the FTDIchip.com drivers in order to load the ATmega16u2.

Yes but FTDIchip drivers only talk to FTDI chips. So I fail to see how this changed anything in your situation.

Although I'm clueless as to why, I can only tell you how it changed my situation: After installing the drivers, the board showed up (enumerated?) in Device Manager as "Ports -> ATmega16u2 DFU".

At the time, I guessed that out-of-date (plain vanilla? non-VCP?) drivers for my PC's FTDI chips originally made the board show up in Device Manager as "Other Devices -> ATmega16u2 DFU". I don't think it was a PC/FTDI-to-Arduino/FTDI fix, because, as you note, there is no FTDI chip on the board. I'm guessing it was more of a PC/FTDI VCP or device enumeration fix. Is there something about VCP that is USB protocol-oriented rather than chip-oriented? I could be remembering wrong, but that was the first step of progress after hours of flailing.

Still clueless,
/dev

[quote author=Louis Davis link=topic=146049.msg1097876#msg1097876 date=1359648476]
See this post for DFU mode.[/quote]

Thanks, Louis! I see that you posted while I was editing my previous reply. I'm sure many people appreciate the time you take on many different forums.

Aaaand this is another example of an official page that can be used for Rev 3, if you know it's safe (thanks!). Even the Hacking Home Page omits 16u2 and Rev 3. Here's what the DFUProgramming8u2 page says:

choose the version suitable for your board, either arduino-usbserial/Arduino-usbserial-uno.hex or arduino-usbserial/Arduino-usbserial-mega.hex

Previously, I had read the README one directory up, in atmegaxxu2, which says to use MEGA-dfu_and_usbserial_combined.hex. I suspected Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex was the correct one, and that the README just didn't have a section for Mega 2560 Rev 3. It kinda worked. The "DFU" part of the device name went away, anyhow.

Per your suggestion, I'll use arduino-usbserial/Arduino-usbserial-atmega16u2-Mega2560-Rev3.hex...

...Ok, I feel better, because the FLIP load went flawlessly. Nothing else has changed, though: "L" doesn't blink in reset, and uploading Blink fails. Which probably means I'm back to this:

The short answer is that if your 16U2 came un-programmed, there is a good chance the 2560 is un-programmed as well.
So even if you are able to reprogram the 16U2, you still need to figure out a way to program the 2560.

I would take it back and see if you can get a replacement.

Yeah, it's been too long for me to return it... but I didn't expect this kind of problem. Oh well, programming the 2560 from scratch is something I should probably know how to do anyway. Is the only way to do this with an ICSP programmer? Or is there some approach with the COMBINED hex files (hinted at here), which seem to contain both 2560 bits and 16u2 bits? Or maybe a 2560 bootstrapper for the 16u2?

Cheers,
/dev

Oh well, programming the 2560 from scratch is something I should probably know how to do anyway. Is the only way to do this with an ICSP programmer?

Correct me if I'm wrong, but I think I just found the answer on the official Hacking Bootloader page:

To burn the bootloader, you'll need to buy an AVR-ISP (in-system programmer), USBtinyISP or build a ParallelProgrammer. The programmer should be connected to the ICSP pins

Cheers,
/dev

What I would do is get a Uno (or similar), or at least a second board. They are extremely useful to have around.

See my post here about programming a bootloader using one: Gammon Forum : Electronics : Microprocessors : Atmega bootloader programmer

This shows how to detect what is loaded onto your main chip (ie. bootloader or not): Gammon Forum : Electronics : Microprocessors : Sketch to detect Atmega chip types

With a little extra hardware (an SD card board) you can upload sketches or bootloaders without using avrdude: Gammon Forum : Electronics : Microprocessors : Atmega chip stand-alone programmer to upload .hex files

Or you can just set it up as an Arduino as ISP and program using the IDE.

This lets you rule in/out things like fuse settings, missing bootloader, etc.

As for the documentation, so many different Arduinos are being released that the site may be lagging behind a bit in places regarding that. You have the Leonardo (completely different main chip), the Mega (different chip from the Uno), and the different USB interface chips they have been using. And now they are releasing the Due. It is exciting and interesting stuff, but updating all of the "getting started" pages may perhaps not always be the highest priority of the developers.

Also they support Windows, Mac, Linux. Plus you have the confusion of the different versions of Windows OS, Mac OS, and different flavours of Linux.

Generally this forum will be able so assist as there are likely to be people with a similar setup to yours, who can help you.

Here's a quick follow-up to all the great suggestions:

I now have extra boards (there will be several in my project) and an AVRISP mkii. I decided to start with the mkii to see if I could read what, if anything, is on the 2560 rev3 board. A few days ago, I downloaded and installed Atmel Studio 6, which installs Atmel USB. According to the Atmel documentation, the next step is simply to plug in the mkii and wait for the magic to happen.

Nothin'. :0 The green USB LED flicks on when I plug it in, then goes off.

A check of Device Manager showed "Jungo -> WinDriver". I also saw an entry for "Other Devices -> AVRISP mkii" with the dreaded yellow exclamation mark. @#$&!!! Suspecting another Win8/x64 problem, I did a little digging around, but I didn't see anything conclusive for Atmel Studio 6. I will have to investigate that later, unless somebody has a suggestion.

However, I remembered reading some of your (Nick's) posts about similiar "missing bootloader" problems, and you had asked about getting a dump with avrdude. Of course, that requires a different USB driver, which also has the digital signature problem. Sigh. Long story short: I have successfully installed the libusb0 drivers and used the avrdude included in WinAVR to get a dump:

avrdude: Version 5.10, compiled on Jan 19 2010 at 10:45:23
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "D:\Program Files\WinAVR\bin\avrdude.conf"

         Using Port                    : usb
         Using Programmer              : avrispmkII
avrdude: usbdev_open(): Found AVRISP mkII, serno: 000200151366
         AVR Part                      : ATMEGA2560
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         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    10     8    0 no       4096    8      0  9000  9000 0x00 0x00
           flash         65    10   256    0 yes    262144  256   1024  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: 1
         Firmware Version Master : 1.10
         Vtarget         : 5.0 V
         SCK period      : 8.00 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9801
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as 99
avrdude: safemode: efuse reads as FF

avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as 99
avrdude: safemode: efuse reads as FF
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Using the -U switch, it looks like the EEPROM is all 0xFF, but the flash dump only shows one S-record: S9030000FC. Anything else I should try with avrdude?

BTW, when I open the Arduino IDE, it seems to correctly select the mkii programmer, so I was hoping that I will be able to choose the "Burn Bootloader" item and get this baby running again. If that doesn't work, I'll try your suggestions for reading/programming the board with another Arduino.

Cheers,
/dev

Using the -U switch, it looks like the EEPROM is all 0xFF, but the flash dump only shows one S-record: S9030000FC. Anything else I should try with avrdude?

Since the default state of EEPROM (and flash) is 0xFF they may well be not saving any bytes that are just that.

It's alive!

After much fiddling, I think it's finally up and running. As I suspected, the lack of "official" documentation made this much more difficult than it had to be. Although the information is out there, trying to find similar symptoms and their solutions is very inefficient and sketchy. It really was like finding 3 needles in 3 haystacks. I would like to suggest a few things to the powers that be:

  • Document the Windows 8 driver instructions. Make sure the Digital Signature issue has been addressed.

  • Mention the Virtual COM port drivers from FTDI. (These are for the PC side of things, not the Mega2560.) Update: Local expert Louis Davis insists here that these are not necessary for non-FTDI boards, and that some side-effect of the install caused the proper drivers to be found by Windows. Apparently, there is an alternative IDE installer here that is much more intelligent about the required drivers. I have not tried it, but it looks outstanding!

  • If you see "ATmega16u2 DFU" anywhere in Device Manager, the ATmega16u2 chip has not been loaded. This chip controls the USB interface for the 2560, and nothing else will work until it is loaded. Along with this, the "Arduino Mega 2560 R3" entry in Device Manager will have a yellow exclamation mark and no COM port will be associated (i.e., it will be in "Other Devices", not "Ports"). See "Restore" section.

  • "Getting Started" should include a step for making sure that the board is properly loaded before you do anything: LED "ON" is green, LED "L" is yellow and blinking, and LED "L" is stopped by pressing RESET and then resumes. If that doesn't work, try to load the Blink example. If that doesn't work, then go to the "Restore" section.

  • Document a from-the-metal process, something like this:


  • Restore Mega2560r3 to the Factory State*

If your device is uninitialized, or you suspect it has been "bricked", please try the following to initialize the ATmega2560 rev 3 to its fresh-from-the-factory state:

  1. Use an ISP to load the ATmega16u2 chip. You must use the unlabelled ICSP header next to the AREF socket and the ATmega16u2 chip (identified as ICSP1 on the schematic). Do not use the "ICSP" header over by the reset switch.

The program to be uploaded is called

  • Arduino-usbserial-atmega16u2-Mega2560-Rev3.hex*
    and can be found in this subdirectory of the Arduino distribution:
  • hardware\arduino\firmwares\atmegaxxu2\arduino-usbserial*

For example, if you use an AVRISPMKii and avrdude 5.11 from here, you should issue this command:

  • avrdude -p m16u2 -e -P usb -c avrispmkii -U flash:w:"%ARDUINO_DIR%\hardware\arduino\firmwares\atmegaxxu2\arduino-usbserial\Arduino-usbserial-atmega16u2-Mega2560-Rev3.hex":i -u -U lfuse:w:0xEF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0x0F:m*

Note: Earlier versions of avrdude do not support the ATmega16u2.

Substitute %ARDUINO_DIR% with the location of the Arduino tool suite (typically something like "C:\Program Files\arduino-1.0.3-windows").

  1. Load the ATmega2560 bootloader using an ISP connected to the ICSP header by the reset switch. If the ATmega16u2 had to be loaded, it is likely that the ATmega2560 will also have to be loaded. This requires an ISP because the ATmega16u2 does not use MISO/MOSI to program the ATmega2560. Rather, the ATmega16u2 uses the STK500v2 protocol over the RX0/TX0 lines, and tells the ATmega2560 to program itself. Unless the ATmega2560 is empty, in which case it will be much too busy staring at its own navel (aka the "Index corner") to be bothered with STK500v2 packets.

The program to be uploaded is called

  • stk500boot_v2_mega2560.hex*
    and can be found in this subdirectory of the Arduino distribution:
  • hardware\arduino\bootloaders\stk500v2*

For example, if you use an AVRISPMKii and avrdude, you should issue this command:

  • avrdude -p m2560 -e -P usb -c avrispmkii -U flash:w:"%ARDUINO_DIR%\hardware\arduino\bootloaders\stk500v2\stk500boot_v2_mega2560.hex":i -u -U lfuse:w:0xFF:m -U hfuse:w:0xD8:m -U efuse:w:0xFD:m -U lock:w:0x3F:m*

If the ATmega2560 was programmed correctly, LED "L" should begin to blink.


And blob's yer uncle. :wink:

Along the path to this enlightenment, I encountered a few things:

  • I could not program the ATmega16u2 LOCK fuse with the suggested value of 0xCF (the -u option had no effect). I had to use 0x0F, even though the ATmega16u2 documentation states:

it is also recommended to set bits 7, 6, 1, and 0 in R0 to “1” when writing the Lock bits.

(section 23.8.7, p. 235). This was also suggested by Mozart in reply #6 of ATmega16u2 problem?

When programmed via ISP, I could even upload ASCIITest or a simple Serial echo program. Using the Serial Monitor, I could type chars to send, but only garbage came back. I tried several different baud rates on the PC, but it was always garbled. After attaching a Logic Analyzer to RX0 and TX0, I could see that the baudrate from the ATmega16u2 was 1200, not 9600. =(

After a little more investigation (e.g., Strange error with mega2560 R3), I wondered if the clock scaler in the ATmega16u2 was not set correctly. Sure enough, that lfuse did not get set correctly until sometime after I successfully wrote the Lock fuse. Why? I don't know any more. Pfft. Setting the fuse was the last hurdle. Everything worked after that.

So there ya' go. Now I'll go drop a note in some of those posts if I think this info might help. Sheesh!

Cheers,
/dev

Sure enough, that lfuse did not get set correctly until sometime after I successfully wrote the Lock fuse.

The fuses are latched according to the datasheet. It has to leave programming mode for them to take effect.

Just use Linux, I don't have to worry about drivers. B-)