"CH340" usb-serial interface chip drivers cause AVR reset problems under Windows / Linux

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?

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.

I solved this by adding a 0.1uF cap between DTR and Gnd. Everything is working fine. On USB power, on external and even on both given together, controller reset behavior is quite normal. Boots up without issue and DTR reset works from the software.

If you are still getting random restarts and suspect that CH340 is playing some tricks because of the absence of any signal on USB D+ and D-, or any burst during enumeration etc, before convicting the innocent 340, first look other causes of reset. Check for WDT resets in your code and also check if the 5V/3.3V regulators aren't cooking. The Chinese board doesn't have power drain protection and simply shuts down the voltage regulator at high temperatures.

After a thorough inspection of one of my commercial products (yeah, I have to use the clone to reduce the cost), it came down to 5V regulator. On high temp, it simply shuts down at high speed, creating spikes. Unlike the conventional 7805 which starts to reduce Vcc less exponentially on high temps. It even crashes the program sometimes if the additional Cap between Gnd and Vcc isn't enough because of these spikes. So I have come to the conclusion that a 0.1uF cap on DTR to GND, one 220uF cap on 5Vcc of the controller to Gnd, and a 7805 to power-up everything else (SD card, LCD, camera etc) solves everything. Don't forget the heat sink and caps needed adjacent to 7805 otherwise, it will also start to heat up.

• In my design, I've actually wired DTR using the cap to the RESET pin of ATmega328p to use the Optiboot functionality, even though I don't use Arduino's toolchain. Seems more reasonable to me to disable the misbehavior in the driver-side instead of removing this feature 1/2 Feb 5 '18 at 1:18
• 2/2 since WCH340G is perfectly capable of NOT making DTR active during a new connection – in fact, I use the same functionality to avoid auto-reset in Arduinos from software, without having to manually modify the board. Feb 5 '18 at 1:20