"CH340" USB-Serial-Interface-Chip-Treiber verursachen AVR-Reset-Probleme unter Windows / Linux

Das Anschließen eines „Nano V3.0“-Arduino-Klongeräts an den USB-Anschluss eines Windows 7-PCs führt dazu, dass sich der ATMega328P auf dem Gerät falsch verhält und abstürzt.

Wir verwenden bewusst NICHT die Arduino-Toolchain - wir verwenden Atmel Studio und ein JTAGICE 3-Programmiergerät, der AVR hat NICHT den Standard-Bootloader installiert. Wir brauchen Hardwaresteuerung auf niedriger Ebene und schreiben die Firmware so, dass sie keinen Bootloader hat.

Das Anschließen des Nano an einen USB-Anschluss einer Linux-Box (CentOS / Android usw.) führte ebenfalls dazu, dass das Gerät in einem unbekannten Zustand blockierte.

Das Ausführen von diesem von einem "dummen" USB-Netzteil war jedoch erfolgreich.

Was könnte dies verursachen?

Antworten (2)

Nach einigen Untersuchungen mit einem Oszilloskop stellten wir fest, dass der USB-Seriell-Schnittstellenchip CH340 auf diesem Nano V3.0-Gerät (ein gängiger Chip für billige Arduino-Klone) während der USB-Enumeration von seinem Windows-Gerätetreiber 5 Mal zurückgesetzt werden muss.

Der Linux-Gerätetreiber bewirkt auch, dass er bei der USB-Enumeration zurückgesetzt wird, sendet jedoch nur einen Reset-Impuls.

Der dumme Akku hat keine Datenleitungen und kein Aufzählungskonzept, und folglich wird kein Reset durchgeführt - so dass der Nano normal hochfahren und korrekt laufen kann.

Hier ist ein Vergleich des seriellen "DTR"-Pins des CH340 einige Sekunden nach dem Einstecken des USB-Kabels sowohl unter Windows als auch unter Linux ...

Geben Sie hier die Bildbeschreibung ein

Beim Nano V3.0 ist das DTR-Signal AC-gekoppelt mit dem Reset-Pin des ATMega328P. Für jede fallende Flanke auf diesen Spuren wird also der ATMega328P-Chip zurückgesetzt! Aus irgendeinem Grund versetzte das Durchlaufen dieser Resets den Nano in einen unbekannten Zustand

Die Problemumgehung für diejenigen von uns, die einen Nano V3.0 verwenden möchten, OHNE Arduino IDE-Kompatibilität zu benötigen, besteht darin, einfach den kleinen Oberflächenmontagekondensator zu entlöten, der an Pin 13 des CH340 des Nano V3.0-Geräts angeschlossen ist . Das ist es.

Dadurch können Windows und Linux weiterhin über die serielle Schnittstelle mit dem Gerät kommunizieren, und Sie können das Gerät über eine externe 5-V-Versorgung mit Strom versorgen und an einen PC anschließen, ohne dass sich der Nano selbst zurücksetzt.

Für uns funktionieren unsere Geräte jetzt einwandfrei mit Atmel Studio + JTAGICE 3 und booten korrekt, egal woran wir sie anschließen.

Fazit: Es kann für einige Anwendungen wünschenswert sein, dass sich der Nano selbst zurücksetzt, wenn Sie ihn an einen PC anschließen, aber es scheint, dass diese „Funktion“ in unserem Fall einen unerwünschten Betrieb des Geräts verursacht. Die Tatsache, dass sich der Windows-Treiber so anders verhält als der Linux-Treiber, ist interessant und ich würde Meinungen dazu einholen.

Mir ist klar, dass ein Nano-Gerät sehr oft nur über das USB-Kabel mit Strom versorgt wird, und das ist in Ordnung, aber nur, wenn Sie eine Art Bootloader auf dem AVR haben, der weiß, wie man mit diesen sporadischen Resets umgeht, und es vermeidet, es selbst zu bekommen ( und wahrscheinlich auch der CH340) in einen unbekannten, kaputten Zustand.

Weitere Informationen zur wahrscheinlichen Ursache für das Fehlverhalten des Windows-Treibers während der Aufzählung: stackoverflow.com/a/25992097/1454514

Ich habe dies gelöst, indem ich eine 0,1uF-Kappe zwischen DTR und Gnd hinzugefügt habe. Alles funktioniert gut. Bei USB-Stromversorgung, bei externer Stromversorgung und sogar bei beiden zusammen ist das Reset-Verhalten des Controllers ganz normal. Ohne Probleme hochgefahren und DTR-Reset funktioniert über die Software.

Wenn Sie immer noch zufällige Neustarts erhalten und vermuten, dass CH340 wegen des Fehlens eines Signals auf USB D+ und D- oder eines Bursts während der Aufzählung usw. einen Streich spielt, bevor Sie den unschuldigen 340 überführen, suchen Sie zuerst nach anderen Ursachen für das Zurücksetzen. Suchen Sie in Ihrem Code nach WDT-Resets und prüfen Sie auch, ob die 5-V / 3,3-V-Regler nicht kochen. Das chinesische Board hat keinen Power-Drain-Schutz und schaltet den Spannungsregler bei hohen Temperaturen einfach ab.

Nach einer gründlichen Inspektion eines meiner kommerziellen Produkte (ja, ich muss den Klon verwenden, um die Kosten zu senken), kam es auf den 5-V-Regler an. Bei hoher Temperatur schaltet es sich einfach mit hoher Geschwindigkeit ab und erzeugt Spitzen. Im Gegensatz zum herkömmlichen 7805, der bei hohen Temperaturen beginnt, Vcc weniger exponentiell zu reduzieren. Es stürzt das Programm manchmal sogar ab, wenn der zusätzliche Cap zwischen Gnd und Vcc wegen dieser Spikes nicht ausreicht. Ich bin also zu dem Schluss gekommen, dass eine 0,1-uF-Kappe auf DTR zu GND, eine 220-uF-Kappe auf 5 Vcc des Controllers zu Gnd und ein 7805 zum Einschalten alles anderen (SD-Karte, LCD, Kamera usw.) alles lösen. Vergessen Sie nicht den Kühlkörper und die Kappen, die neben 7805 benötigt werden, sonst beginnt es sich auch zu erwärmen.

In meinem Design habe ich tatsächlich DTRdie Kappe mit dem RESETPin von ATmega328p verdrahtet, um die Optiboot-Funktionalität zu verwenden, obwohl ich die Toolchain von Arduino nicht verwende. Es erscheint mir sinnvoller, das Fehlverhalten auf der Treiberseite zu deaktivieren, anstatt diese Funktion 1/2 zu entfernen
2/2, da WCH340G perfekt in der Lage ist, DTRwährend einer neuen Verbindung NICHT aktiv zu werden – tatsächlich verwende ich dieselbe Funktionalität, um ein automatisches Zurücksetzen in Arduinos von der Software zu vermeiden, ohne das Board manuell ändern zu müssen.