Atmel DFU xMega256A3U Bootloader Error 43 unter Windows 10

[Emanuel L. (eleicht)]

Hallo zusammen,

ihr seid die letzte Bastion vor dem Atmel-Support.

Ich nutze den Atmel DFU Bootloader am xMega256-A3U. Über einen SW-Reset 
springt er in den Bootloader, von dort kann ich mit dem Flip-Tool neue 
Firmware aufspielen.

*Kurz der Code der Reset-Routine:*

usb_puts("Entering bootloader of control unit.\nClose this connection and use Flip tool or restart control unit.");
_delay_ms(10);
        
udc_detach();
udc_stop();
        
// From: https://www.mikrocontroller.net/topic/417749?reply_to=4880265#postform
// Before entering bootloader, the internal 32 kHz calibration for 32 MHz oscilloscope has to be switched off,
// otherwise bootloader won't be able to connect via USB. Don't know why this happens, seems to be hardware bug.
DFLLRC32M.CTRL &= ~(DFLL_ENABLE_bm);
        
EIND = BOOT_SECTION_START>>17;
jump_to_bootloader();

*Das Problem:*
Unter Windows 7 funktioniert das einwandfrei und robust, der Bootloader 
meldet sich quasi instant an.
Unter Windows 10 erhalte ich einen "Error 43" bzw. im Geräte-Manager:
"Unbekanntes USB-Gerät (Fehler beim Anfordern einer 
Gerätebeschreibung)".

*Auch wichtig zu wissen:*
- Wenn der Controller außer dem BL noch keine Software drauf hat, 
erkennt das Flip tool und Geräte-Manager ihn wunderbar und ich kann das 
1. mal meine Firmware drauf flashen.
- Um den Controller in den BL springen zu lassen, muss über ein offenes 
Terminal der Befehl "boot" eingegeben werden. Logischerweise erhalte ich 
dann eine Fehlermeldung, dass der eben noch offene Port einen "Fatal 
error" hat. Das hat bei Windows 7 aber nichts gemacht, d.h. Port 
schließen und Flip-tool öffnen. Unter Windows 10 wird der Port 
automatisch geschlossen --> kann es irgendwie mit einem fehlenden, 
korrekt durchgeführtem "Auswerfen" zu tun haben?
- Der Fehler erscheint jedes 25. Mal (ca.) -nicht-. Diese Quote ist 
allerdings etwas gering, um damit leben zu können. Eines Tages soll das 
Ding zum Kunden, d.h. "mit Windows 10 läufts nicht" wäre ungünstig.
- An beiden Rechnern am USB 3.0-Port angeschlossen.
- USB-Kabel getauscht, mit identischen Konfigurationen jeweils 
ausprobiert, Win 7 okay, Win 10 nicht.

[Jim M. (turboj)]

Klingt nach Timing beim USB Reset.

Vor dem Wechsel in den Bootloader beide USB Pins auf GPIO schalten und 
aktiv auf Masse (Low) für >= 1 Sekunde ziehen. Damit wird das USB Gerät 
sicher als "abgesteckt" erkannt.

Wenn der Bootloader eigene Software im Flash ist könnte er das auch 
selbst machen.

[Emanuel L. (eleicht)]

Jim M. schrieb:
> Klingt nach Timing beim USB Reset.
>
> Vor dem Wechsel in den Bootloader beide USB Pins auf GPIO schalten und
> aktiv auf Masse (Low) für >= 1 Sekunde ziehen. Damit wird das USB Gerät
> sicher als "abgesteckt" erkannt.

Danke für den Tipp, aber es hat nicht geholfen.
Über Oszi geprüft, riesen Delay eingebaut (variiert), keine Änderung. 
Windows schließt auch sofort wieder die Terminal-Verbindung.

[Jim M. (turboj)]

Tja, dann wird man sich das wohl mit einem Logic Analyser auf 
Signalebene anschauen müssen.

Oder mit dem Microsoft Message Analyser auf Windows Ebene.

Meine Vermutung wäre dass der Bootloader manchmal ein paar ms zuviel 
zum Initialisieren braucht - und dabei den USB Reset und ein paar Pakete 
verschläft.

Es kann durchaus sein dass MS da mit Windows 10 was am Timing gedreht 
hat.

[Emanuel L. (eleicht)]

Jim M. schrieb:
> Es kann durchaus sein dass MS da mit Windows 10 was am Timing gedreht
> hat.

Das ist offenbar der Fall, ich habe auf einer anderen Seite gelesen, 
dass das Device sich innerhalb von 20 ms anmelden muss, was zuvor anders 
war - die Angabe ist aber ohne Gewähr.
Allerdings meldet sich der Bootloader von alleine korrekt an, wenn nur 
er auf dem Controller ist. Sobald ich aus meiner Firmware dort 
reinspringe, erhalte ich die Fehlermeldung eines nicht korrekt 
abgemeldeten Devices. Ich kann doch da nicht der einzige sein, der mit 
Windows 10 Probleme hat.
Das komische vor allem: Auf einem anderen Windows 10 Laptop funktioniert 
es. Meine Treiber sind alle aktuell, die Maschine auch (Acer Predator 
G1). Was könnte hier HW-seitig anders sein, dass die Abmeldung nicht 
klappt? Ich habe auch schon alle USB-Anschlüsse durch, d.h. ein 
nativ-USB/interhal-hub-USB-Problem wie ich mal bei Windows 7 hatte, ist 
wohl auszuschließen.
Testweise habe ich zwischen alle Befehle im obigen Code (1. Beitrag) ein

_delay_ms(1000);

eingebaut, leider mit selbem Ergebnis.

Vielleicht liegt die Antwort irgendwo darin vergraben, weshalb Windows 
den Port automatisch schließt, was bei Windows 7 nicht passiert ist. 
Also der Knopf in meinem Terminal (UWTerminal von Laird) schaltet sogar 
um von "Close" auf "Open", weil der Port plötzlich geschlossen ist. Das 
ist bei Windows 7 nicht passiert.