RUMBA - AT16U2 DFU Mode (How To Please)

[gLoeffler]

The Rumba board is suppose to be able to use the USB Cable and USB PWR jumped pins and allow for DFU mode. Following the Wiki directions, temporarily shorting the GRN/RST pins only resets the AT16U2, does not put it into DFU mode. DFU Programmer says "No Device Present"

Question #1 - is it possible for program the AT16U2 through the USB cable via the computer (PC or Mac)

Question #2 - if it is possible, what is the proper procedure to put the RUMBA board into DFU mode via using a USB Cable and DFU Programmer (PC or Mac)

Thanks.

[Sherry]

i have tested my board and it could enter DFU mode.please try following these steps.
Set the power jumper in "USB powered" position.
Place a jumper slightly on the two pins pointed by the white arrow (see picture below). (These are the Ground and Reset pins of the ISP programming header for the ATMega16u4 chip that handles the USB communication.)
If the board is not mounted on your printer, place it on a clean, dry and insulated surface.
Connect the USB cable on the board, and connect it on your computer
Remove the jumper (be careful not to make short-circuit, do not use metallic tools). The TX and RX leds are flashing: the board is now in DFU mode.

[gLoeffler]

No... this is not working. I have tried using the jumper approach (as described) ... I have now also purchased a usb avr programmer ...

Jumper Approach:
No LED lights on the ISP Port illuminate using the Jumper GND/RST approach. Only shows up as USB Device COM3, and not USBasp.

AVR Programmer Approach:
With the AVR Programmer attached to the ISP programming header and plugged into usb port on the computer, both red LED light up.

Using Windows 10 ... the computer sees the device (USBasp in Windows/DeviceManager) but the programming software [dfu-programmer] does not find the device --- error with "No Device Present"

Have tried ... command-line using dfu-programmer 0.7.2, or GUI program Atmel Flip 3.4.7.112, and Khazama AVR Programmer.

I think the Khazama AVR Programmer "MAY" have written the hex file, but I am not sure... I am lost with this type of programming.

How do I tell if the AT16U2 has the hex code Rev3 on it...?

[gLoeffler]

Could you please provide step-by-step directions for DFU Mode on a Windows 7 computer ... both jumper technique and avr programming technique. I really need to program the ATmega16u2 with the Rev3 firmware code.

Thanks,
Guy

[gLoeffler]

...OK... so I bought another board directly from You (GeeeTech). It arrived the other day. This board also DOES NOT go into DFU mode.

I need help here, or I need to return BOTH boards and buy something that works and does not have USB connection issues.

[gLoeffler]

...have purchased two boards now. Neither will go into DFU mode.

[gLoeffler]

Looks like I am FINALLY back in business (Knock-On-Wood).

K.I.S.S. method ... EVERYTHING has been done on Win7 x64 boxes at this point. **** Mac OS X has been taking completely out of the loop **** I will report on that with a separate continuation thread. But I've muddled through some things, googling a whole heck of a lot about the 16U2 and programming it.

Here's what I've learned and implemented about ATmega16U2 and RUMBA boards:

The 16U2 flashes ONLY with a AVR USB Cable. Have two RUMBA boards and NEITHER go into UBS Powered DFU mode. Shorting the pins per instructions (on WiKi and from GeeeTech) and then removing the short does not make the led lights flash, nor show up in Device Manager (Win7 x64).

My testing setup and what I did ...

Win7 x64 box, the RUMBA TAURINO Win7 driver, Arduino v1.6.45 with Win7 driver ... 1.) first checked that RUMBA is seen and can be FW flashed with Arduino USBtinyISP connection setting (check). 2.) then check that using AVR cable (hence giving you an usbasp port) properly shows up in Device Manager (check). Then try to read the ATmega16U2 chip information (check).


*********** FLASHING 16U2 **********
Flashing the ATmega16U2 is easy as straight up as most online docs show. I had issues with my lock (0xFF instead of 0xCF) and issues with the correct values for the lfuse, hfuse, and efuse. Apparently, not all Atmega16U2 chips are the same when it comes to these values, it depends upon the actual board/processor (based Atmega2560).


FIRST STEP ... with AVR USB Cable properly connected and recognized...
run this command ... avrdude -c usbasp -P usbasp -p m16U2 -v ...
save this information dump output to a screen capture (just in case).

This will tell you that you are connected properly without hosing your board with an attempted flash read or write.

Originally, I just flashed one of the new RUMBA boards like this: avrdude -c usbasp -p m16u2 -F -U flash:w:usb_chip.hex:i But was still having communications / connection issues ... so I wanted to go further in the flash commands.

Found this, but would not program...
avrdude -p m16u2 -e -P usbasp -c usbasp -U flash:w:usb_chip.hex:i -u -U lfuse:w:0xEF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0xCF:m

Went back to the Rapide Lite board and ran avrdude to see what the values were for that board ... used those for the new RUMBA board fuse values.


Then tried this combination of the two (emphasis on fuse values and lock:w:0x0F:m ... to make it successful without errors)...
avrdude -p m16u2 -F -c usbasp -U flash:w:usb_chip.hex -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m -U efuse:w:0xF6:m -U lock:w:0x0F:m

***********************************

Seemed to have worked... now to test it out. Used Arduino v1.6.4 to flash the firmware again - now it should be talking properly to the Win7 USB Intel ICH10-3A39 controller and all that stuff...

ABOUT FIRMWARE - Again, K.I.S.S. approach ... went back to a "known-good" state of affairs. Previously, used Marlin v1.0.2. But now went back to the RL200's v1.0.1 FW with minor tweaks for the RUMBA board consideration (incl. drv8825 step driver tweaks 157 instead of 160).

Now, when I connect with Repetier we no longer get "not end of line" errors... so FW seems to be good.

Using Repetier on the Win7 x64 box, I am able to connect to the RUMBA just fine. No connections errors. Test printed several stl files, longest about 1 hour. At this point, very thing seems normal again... like when the original board "actually worked" (ha ha).

***********************************
TAKING IT ALL BACK HOME ---> TO OS X
***********************************
So, next was to take this configuration back to the original box (OS X Hackintosh, Win7 x64 dual boot) and see if the Win7 can be setup the exact same as the striped down test box. Yep, it worked fine. Once I configured the ports and software same as the test box, Repetier connected just fine and I am printing 1-2 hour jobs.

Pheew. Next up in another thread, why OS X is having issues with USB connections. But that's for later, I've got a lot of printing to day - I'm way behind

[Karrahahu1]

These are the Ground and Reset pins of the ISP programming header for the ATMega16u4 chip that handles the USB communication.???

[gLoeffler]

Yes, when trying to get into DFU mode shorting those pins did not work for me, as the instructions said it would.