Resetting 16U2 Processor on Uno (R3)

Question

This question got me thinking, the OP was wondering about how to "bring back" Leonardo boards connected to a Raspberry Pi via USB. The Leonardos would occasionally drop off line and could not be brought back by resetting the board.

So I got curious and hooked a Uno up to a Pi via USB and started poking around. I had the idea that perhaps resetting the 16U2 would do the trick. It does not. After resetting the 16U2 (by grounding the reset pin in the ICSP connector). This is what I see in the kernel log on the Pi:

[ 6277.570058] usb 1-1.3: USB disconnect, device number 11
[ 6278.576503] usb 1-1.3: new full-speed USB device number 12 using dwc_otg
[ 6278.684793] usb 1-1.3: New USB device found, idVendor=03eb, idProduct=2fef
[ 6278.684823] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 6278.684841] usb 1-1.3: Product: ATmega16U2 DFU

As opposed to this:

[ 6325.960510] usb 1-1.3: USB disconnect, device number 12
[ 6329.267003] usb 1-1.3: new full-speed USB device number 13 using dwc_otg
[ 6329.382675] usb 1-1.3: New USB device found, idVendor=2a03, idProduct=0043
[ 6329.382703] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[ 6329.382720] usb 1-1.3: Product: Arduino Uno
[ 6329.382736] usb 1-1.3: Manufacturer: Arduino Srl 
[ 6329.382753] usb 1-1.3: SerialNumber: 75431343334351F061E2
[ 6329.384088] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device

Which is what I see if I unplug and replug the USB cable.

I'd like to know what happens differently during a 16U2 reset vs. an unplug/replug cycle.

I'd also like to know if there is a way to simulate unplugging and replugging the USB cable. The 16U2 reset comes close (the Pi notices that something happened), but it would be nice if there were a way that either code on the Uno or on the Pi could "wake up" a down USB link.

Answer 1

What I think is happening here is that the HWBE fuse is set (hardware boot enable).

From the datasheet:

The Hardware Boot Enable Fuse (HWBE) can be programmed so that upon special hardware conditions under reset, the bootloader execution is forced after reset.

What this means is that under normal booting (power-on reset) the bootloader is not entered, and the device immediately identifies as a TTY device (ttyACM0) as you saw:

[ 6329.384088] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device

However if you manually reset it, it enters DFU mode with its bootloader, so you can reprogram the main code. Thus it identifies differently:

[ 6278.684841] usb 1-1.3: Product: ATmega16U2 DFU

Thus, a forced reset via the Reset pin acts differently to a power-on rest. By design.

---

If you search for uno enter dfu mode you will get quite a few hits. People use that technique to reprogram their ATmega16U2 (eg. to act as a MIDI interface).

• Heath Raftery: FWIW, this is true on the R3 in particular because the HWB (PD7) pin is pulled low, which is checked on reset (aka. warm boot). In previous revisions you had to do that manually via a jumper on the reverse side of the board. On the other hand, a fresh ATmega16U2 from the factory will boot to DFU mode on cold boot (eg. the cable replug scenario described by the OP) either because the default application code jumps to it (ref. chapter 23.6.1) or (my guess) because the BOOTRST fuse is programmed that way (ref. chapter 23.6.2).