Device Not Recognized

Out of 15 Arduino Uno custom boards, I have 2 where Windows does not recognize the device as an Arduino port or (after resetting the 16U2 manually) a DFU port.

In all 15 cases, I programmed the boards using the ICSP with Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex, and set the fuses to low FF, high D9 and extended F4. The crystal oscillators are working at 16 MHz and I have checked continuity between the USB port and the 16u2 (RD+,RD- and VUSB). I replaced the 16u2's but the same problem remains, so it must be something else.

I read somewhere that the oscillator frequency is very critical to USB connection. This is one of the reasons I decided to use a crystal and not a resonator. Other than that, the circuit is identical to the standard Uno Rev 3.

There appears to be activity on RD+ and possibly RD- when I connect the USB or manually reset the 16U2, but without a USB analyzer I cannot tell what it is doing.

There's probably not many responses to your posts because not many people are doing what you are doing. It is interesting, though, so I'm watching your posts. Just as in the other thread, you may have a small solder problem, short, or open somewhere. Check for shorts and opens with an ohm meter and visual inspection. Check for continuity all the way to the computer end of the USB cable, in case you have problems with the soldering on the USB connector (or USB cable going bad).

dmjlambert-I have done what you suggested for the main signals RD+, RD-, VUSB & NRESET and found no shorts or opens. However, it is possible that two adjacent pins on the package might be shorted that are otherwise not connected to anything, for example pins 18-19. I am using an ATMEGA16U2-AU (TQFP-32 package) so it is not easy to probe adjacent pins with an ohmmeter. But since the problem persisted after having the ICs replaced, that would seem to eliminate a solder ball hiding between adjacent pins. Next step if I don't get another idea is to replace the crystal oscillator which appears to be working fine - but maybe there is something marginal about its amplitude or frequency.

Last week I had access to a USB monitor (USB Beagle) so checked the USB message. During initialization, all messages from the two bad boards showed a SYNC error. Also checked all pins on the 16U2 with a binocular microscope for opens and used a DVM with beeper to verify that there were no shorts between any two pins on the 16U2. Used a better scope to verify the frequency and amplitude of the crystal oscillator.

I tried one other test. With the USB port connected to a USB charger so as to eliminate any PC USB activity I applied a reset to the 16U2. Both data lines go low while nreset is low than both go high when nreset goes high. I believe this is the correct behavior.

Rereading the data sheet on the 16U2, I found where the 1M resistor across the crystal is not required so I removed it. No change. Then I decided to try putting the crystal in the Full Swing mode instead of the Low Power mode. Low fuse = E7. Now the oscillator sits at 2.5 VDC and does not oscillate at all. I tried putting it back in low power mode (Low Fuse = EF or FF) but with the oscillator not running, I cannot reprogram the fuse.

I have read stuff on line that says the Full Swing mode was eliminated and other stuff that says it was not. But the Atmel data sheet (7799E–AVR–09/2012) still shows it. I could try putting a good board in Full Swing mode but hate to brick another board.

There is information in the errata section of the data sheet that says not to use full swing with crystal over 8MHz for certain revisions of the chip. In online fuse calculators I do not see full swing options mentioned and E7 fuse is for low frequency crystal. I have seen and used versions of the Arduino as ISP sketch that provide a clock signal on port 9 that you can hook up to XTAL1 of the target to get it going. I used one a long time ago, I think it was this one:

Have you made and uploaded a blink sketch to the ATmega16u2 to blink some pins on that bad chip to see if it actually runs a sketch at the expected rate? i.e. 1 second on and 1 second off.

Thanks dmj.

I see the errata. But why did they not change section 8.5 to reflect this? Anyway, now I understand why the online calculators do not include this. The low fuse setting E7 comes from their table 8-1 on page 29.

I seem to have found an easy way to brick the chip as the 16 MHz oscillator no longer runs and with it not running, I cannot change the fuses back to where it does run. I will replace the 16U2s on these two boards (again) but that will just bring me back to where I started - oscillators running, chips load with Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex but Device Not Recognized in Windows.

I would simply trash these two boards except for the fact that they represent a 14% failure rate on what I hope to be a production unit. That is way too high. I need to figure out what I am doing wrong.

Since replacing the 16u2's previously did not fix my USB problem, it seems likely that it must be due either to a bad component or connection to the USB connector or to some dynamic problem with the crystal oscillator. Both circuits are identical to those used in the standard UNOs. The USB path checks out with an ohmmeter and the crystal oscillator looks good on the scope. I like your idea of loading a blink hex into the 16u2 via the ICSP. If it runs, the problem must be in the USB connection. If it doesn't, it suggests an oscillator problem.

PROBLEM SOLVED! For anyone following this post, I thought I would give you the good news that I found the cause of my marginal USB problem. By marginal, I mean that most of the boards worked but about 14% did not. It turns out that I selected an ESD limiter that protects the USB data lines that has a "working voltage" of 5VDC. The Arduino reference design uses ESD protectors with a working voltage of 24 VDC which seems way to high since USB is all 5 VDC. Replacing my 5 VDC parts with 12 VDC devices having otherwise identical characteristics fixed the problem.