mir kommt ein sehr seltsames Verhalten unter, für das ich keine Lösung finde. Eventuell kann mir hier jemand weiterhelfen?
Ich besitze seit kurzem ein Arduino-Derivat (Mojo V3) mit
- ATmega32U4 (nein, kein ftDuino und auch kein Leonardo) auf 8 MHz
- einem Caterina-Bootlader (Hersteller-Original) - VID/PID 0x29DD/0x0001
- einem User-Programm (Hersteller-Demo) - VID/PID 0x29DD/0x8001
- der Eigenschaft Bus-powered mit bis zu 500 mA
Zuerst dachte ich an einen Fehler im Bootlader (dass gar keiner drin wäre) und habe heute fleißig gewerkelt um den ATmega32U4 per ISP an ein STK500 anzuschliessen. Und dazu brauchte ich auch meinen alten WinXP-PC. Das Ende vom Lied:
Am WinXP bekomme ich Lebenszeichen sowohl vom Bootlader (!) als auch vom User-Programm. Am Win10 PC stellt sich der Bootlader (und nur der) tot. Am Bootlader oder am Arduino kann es also eher nicht liegen sonst ginge auch auf dem WinXP nichts.
Die Sourcecodes der Programmteile habe ich analysiert, abgesehen von der VID/PID ist der Bootlader exakt identisch mit jedem Arduino-Leonardo oder Sparkfun ProMicro Bootlader. Letztere arbeiten in allen Lebenslagen auch am Win10 PC.
Was mir noch auffiel: Am Win10-PC kommt der Bootlader nicht nach dem Timeout zurück (hier 16 s anstelle der üblichen 8 s weil der Hersteller nicht an die 8 MHz anstelle der üblichen 16 MHz gedacht hat = Fehler #1), der µC scheint komplett "tot" zu sein. Am WinXP-PC läuft der Timeout dagegen ab und das User-Programm startet wieder. Explizit geprüft habe ich auch die Falle mit der Taktfrequenz. Laut Sourcecode (makefile) ist da korrekt 8 MHz vorgegeben. Auch das deckt sich mit meiner WinXP-Erfahrung. Um am Win10-PC das Teil wieder ans Leben zu bringen ist definitiv ein Ziehen des USB-Steckers erforderlich (leider gibt es keinen RESET-Knopf auf der Platine). Auch die diversen Fuses des ATmega32U4 sind überprüft und insbesondere Brown-Out ist auf 2.7 V eingestellt. Die USB-Spannung vom PC steht mit dem "toten" Bootlader bei etwa 4.85V, wenn das User-Programm läuft sind es 4.77 V. Das ist plausibel weil das User-Programm ein paar LEDs erleuchtet und daher mehr Stromverbrauch aufweist.
Ich habe keinen zweiten Win10-PC um eine Gegenprobe zu machen. Auf WinXP funktioniert die Maschinerie. Also liegt es am Win10-PC, oder? Das OS ist recht aktuell, damit scheiden veraltete Treiber aus. Auch der Umstand, dass andere USB-CDC-Klasse Geräte einwandfrei arbeiten spricht gegen ein Treiberproblem. Der Fehler mit der doppelten Timeout-Länge ist unschön aber eher die Rubrik "it's a feature" weil ich hier mehr Zeit hätte den avrdude zu starten.
Im Netzt habe ich herumgesucht aber leider nicht wirklich Ergebnisse gefunden die mir weiterhelfen. Im Arduino-Mikrokosmos ist das Problem anscheinend noch nie aufgetreten - es wollte wohl noch niemand den ATmega32U4 auf dem Board unter Win10 umprogrammieren.
- Unter welchem Stichwort könnte ich fündig werden?
- Könnte es sein, dass aus unerfindlichen Gründen mein Win10-PC die VID/PID des Bootladers verweigert? Gibt es solche selektiven Sperren im Windows (Windows-Defender oder wie das heißt)? USB-Sticks lassen sich als Klasse sperren, aber einzelne VID/PIDs?
- Ist es eine zu niedrig eingestellte Stromaufnahme im Bootlader (Hersteller-Fehler #2: 100 mA im Bootlader aber nicht umsonst 500 mA im User-Programm) die der Win10 PC penibler überprüft und bei Überschreiten sang- und klanglos abwürgt?
Grüße
H.A.R.R.Y.