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¤tviews=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.
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?
Gast
#5714754
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
Gast
#5715656
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.
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.)