Attaching a "Nano V3.0" arduino clone device to a Windows 7 PC's USB port causes the ATMega328P on the device to misbehave and lock up.
We are deliberately NOT using the Arduino toolchain – we are using Atmel Studio and a JTAGICE 3 programming device, the AVR does NOT have the standard bootloader installed. We need low level hardware control and so we're writing the firmware to have no bootloader.
Attaching the Nano to a Linux box (CentOS / Android etc) USB port was also causing the device to lock up in an unknown state.
Running this from a "dumb" USB power pack however was successful.
What could be causing this?
Best Answer
After some investigation with an oscilloscope we discovered that the CH340 USB-Serial interface chip on this Nano V3.0 device (a common chip for cheap arduino clones) is forced to reset 5 times by it's Windows device driver during USB enumeration.
The Linux device driver also causes it to reset upon USB enumeration but only sends one reset pulse.
The dumb battery pack has no data lines and no concept of enumeration and consequently no reset is done - allowing the Nano to boot up normally and run correctly.
Here's a comparison of the CH340's serial "DTR" pin a few seconds after inserting the USB cable on both Windows and Linux...
On the Nano V3.0, the DTR signal is AC coupled to the ATMega328P's reset pin. So for every falling edge on those traces the ATMega328P chip is being reset! For some reason, going through these resets was putting the Nano into some unknown state
The Workaround for those of us that want to use a Nano V3.0 WITHOUT needing Arduino IDE compatibility is to simply desolder the small surface mount capacitor attached to pin 13 on the CH340 on the Nano V3.0 device. That's it.
This will still allow Windows and Linux to talk to the device over the serial interface and allows you to power the device from some external 5V supply and attach it to a PC without the Nano resetting itself.
For us, our devices now work just fine with Atmel Studio + JTAGICE 3 and boot up correctly no matter what we plug them into.
Conclusion: It may be desirable for some applications to have the Nano reset itself when you plug it into a PC but it does seem that this "feature" is causing undesired operation of the device in our case. The fact that the windows driver behaves so differently to the Linux one is interesting and I'd invite opinions on that.
I realise that very often a Nano device will only ever get it's power from the USB cable and this is fine but only if you've got some sort of bootloader on the AVR that knows how to handle these sporadic resets and avoids getting it self (and probably the CH340 too) into an unknown, broken state.