Forum: Mikrocontroller und Digitale Elektronik STM32 USB Device Receive abbrechen


von Sebastian V. (sebi_s)


Lesenswert?

Ich programmiere gerade ein USB MTP Device mit der STM32CubeF4 Firmware 
auf einem STM32F4 Discovery Board. Eigentlich läuft soweit alles, bis 
auf das Abbrechen von Dateitransfers vom PC auf das Discovery Board. 
Wenn man den Transfer abbricht wird ein Cancel Request auf dem Control 
Endpoint gesendet und gleichzeitig wird scheinbar der aktuelle laufende 
USB Transfer auf einem Bulk Endpoint abgebrochen. Genau dieses Abbrechen 
des Transfers auf dem Bulk Endpoint scheint irgendwie Probleme zu 
machen, da das Device danach auf diesem nichts mehr empfängt. Ich habe 
die Vermutung, dass der Endpoint irgendeinen komischen Zustand einnimmt 
wenn ich bereits mit USBD_LL_PrepareReceive den Transfer akzeptiere und 
dieser dann abgebrochen wird. Verzögere ich das USBD_LL_PrepareReceive 
künstlich durch ein Delay scheint es zu funktionieren, aber das ist ja 
keine Lösung. Ich habe bereits von den Code von 
https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Java%2FHow%20to%20cancel%20transfer%20on%20OUT%20pipe%20of%20USB&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&currentviews=57 
ausprobiert, allerdings ohne Erfolg. Ich habe auch schon durch die 
anderen Register geschaut aber nichts hilfreiches gefunden. Wie kann ich 
wieder einen gültigen Zustand des Endpoints herstellen? Es ist keine 
STALL Condition.

von Sebastian V. (sebi_s)


Lesenswert?

Hat niemand eine Idee? Bin für alle Vorschläge offen. Ich habe schon den 
USB Transfer per Software (Wireshark mit USBPcap, USBlyzer) 
mitgeschnitten aber nichts interessantes gefunden. Auch ein Vergleich 
einiger USB Register vom STM32F4 war nicht besonders aufschlussreich. 
Der einzige Unterschied zwischen der Variante mit Delay und der ohne ist 
das OTG_FS_DOEPINTx Register. In der nicht funktionierenden Variante 
ohne Delay sind alle Bits auf 0 und in der funktionierenden Variante mit 
Delay den Wert 0x00002010. Bit 4 (OTEPDIS: OUT token received when 
endpoint disabled) macht ja noch Sinn aber Bit 13 ist laut Datenblatt 
reserviert.

Bin über alle Vorschläge für weitere Möglichkeiten zum Debuggen, 
Hinweise auf ein besser geeignetes Forum für diese Frage oder Sonstiges 
dankbar. Hat vielleicht jemand ein Hardware USB Protocol Analyzer und 
ein STM32F4 Discovery Board (oder ein anderes Discovery Board mit USB) 
und mag mir den kompletten Transfer mitschneiden?

von C.F. (Gast)


Lesenswert?

Hallo, ich weiss ist lange her, aber gibts eine chance dass du das MTP 
Device zum laufe gebracht hast und uns den Code zur verfügung stellst?

gruess C

von avr (Gast)


Lesenswert?

Ich bin nicht der TO, aber habe etwas am Code mitgeschrieben. Das 
MTP-Device war nicht das Problem, sondern nur das Abbrechen des 
Transfers. Soweit ich weiß, besteht das Problem immernoch. Allerdings 
gibt es inzwischen in STM32-Cube ein MTP-Device, das haben wir nicht 
getestet, da es das zur der Zeit noch nicht gab.

von Henrik H. (Firma: TU Chemnitz) (heha)


Lesenswert?

Hallo,
wenn ich den PIMA-Standard richtig gelesen habe, muss man bei 
eingehendem Cancel-Request (über EP0) die Bulk-Pipes (EP1 usw.) 
zurücksetzen, so als würde man einen STALL zurücksetzen oder als würde 
man vom unkonfigurierten in den konfigurierten USB-Zustand übergehen. 
Zumindest den Bulk-Out-Endpoint.

Die Sache mit STALL lösen kann der Host nicht. IMHO können nur Devices 
STALL setzen, um laufende Übertragungen vorzeitig abzuwürgen. Der 
USB-Standard denkt, dass ein Host weiß, was er tut, und niemals 
Transfers abbrechen muss. Andererseits ist MTP ohnehin krankhaft, weil 
es von bis zu 4 Gigabyte ununterbrochenem USB-Transfer ausgeht, nur um 
eine Datei zu ändern.

Ich kenne mich mit Frameworks nicht aus, und Frameworks sind meistens 
unvollständig. Möglicherweise muss man für so ein Vorhaben direkt auf 
Register des USB-Controllers zugreifen, was den Sinn von Frameworks 
umgehend in Frage stellt: Es wäre doppelte Einarbeitung: In die Doku des 
Frameworks UND in die des Mikrocontrollers. (Die Doku von PIMA und USB 
noch nicht eingerechnet.)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.