Go Down

Topic: What next? Mega2560r3 ATmega16U2 DFU Win8 USB (Read 8 times) previous topic - next topic

/dev

#15
Mar 15, 2013, 06:08 am Last Edit: Mar 16, 2013, 07:11 pm by /dev Reason: 1
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").

    2) 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.  ;)

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:
    Quote
    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?



  • At one point, I tried the loopback test and it worked, proving that the ATmega16u2 and PC USB drivers were correctly installed.  However, I still could not program the ATmega2560 via USB.  I was still getting this error: stk500_2_ReceiveMessage(): timeout.  It was the same symptom described in Help! Bricked, Mega 2560 R3 not uploading any sketch, Arduino uno rev3 board came unprogrammed; and    
    Arduino Mega 2560 Bootloader (apparently) burnt correctly but not working
    .

    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

Nick Gammon

Quote

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.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

Go Up