USB-Sticks an STM32

[Michael (Gast)]

Hallo zusammen,
wir haben hier ein Design mit dem STM32 entwickelt, welches die 
USB-Host-Lib v2.1 von STM verwendet. Compiler ist der GCC.

Leider funktionieren ca. 1/3 der hier rumliegenden USB-Sticks damit 
nicht.
Es scheint laut Debugger schon bei der grundsätzlichen Initialisierung, 
also weit vor dem Auslesen des Dateisystems einen Timeout zu geben.

Vom Routing her haben wir ca. 3 cm vom Controller zur USB-Buchse. Die 
beiden Leitungen werden durchgehend parallel geführt, direkt darunter 
ist eine durchgänge GND-Plane auf der Innenlage, rechts und links sind 
die Signale auch von Masse eingeschlossen, keine weiteren 
Signale/Leiterbahnen laufen parallel dazu. Auf Impedanzanpassung 
aufgrund der kurzen Leitung haben wir erstmal nicht geachtet. Mit dem 
Oszi angeschaut sehen die Signale sauber aus, ohne Überschwinger und 
irgendwelche Anzeichen von Reflexionen.
In Serie zu den Datenleitungen sind 2x 33R. Aber auch Ersatz mit 0R 
ändert das Verhalten nicht. Die 5V sind während der Initialisierung 
stabil. Auch zusätzliche Kapazität (220µF) direkt an der Buchse ändert 
nichts.

Bei allen Sticks (funktionierende und nichtfunktionierende) wird die 
Verbindung laut Debugger mit Fullspeed aufgebaut. Ein Zurückschalten auf 
Lowspeed habe ich auch bei den funktionierenden Sticks erstmal nicht 
hinbekommen, dann geht gar nichts mehr.

Sonstige Ideen?

Michael

[Jim M. (turboj)]

Michael schrieb:
> Es scheint laut Debugger schon bei der grundsätzlichen Initialisierung,
> also weit vor dem Auslesen des Dateisystems einen Timeout zu geben.

Viel zu ungenaue Fehlerbeschreibung. Mit dem Debugger müsste man 
rausbekommen, was genau nicht klappt. Eventuell lohnt es sich die 
Deskriptoren der Sticks genauer unter die Lupe zu nehmen.

Michael schrieb:
> Ein Zurückschalten auf
> Lowspeed habe ich auch bei den funktionierenden Sticks erstmal nicht
> hinbekommen

Mal die USB Specs gelesen? Das Device entscheidet ob Full- oder 
Lowspeed, nicht der Host.

[Michael (Gast)]

Hallo,
ist etwas schwierig zu debuggen, weil das Debuggen selbst scheinbar 
timeouts auslöst.
Kennst Du Dich mit der USB-Lib von ST aus?
Der interne Fehler ist USBH_BUSY, nachdem die Statemachine einige Male 
hin- und her kommuniziert hat.

Ich habe den Verlauf mal in einem Array aufgezeichnet:

"phost->gState"  HOST_CLASS  
"phost->Control.state"  CTRL_IDLE  
"phost->EnumState"  ENUM_DEV_CONFIGURED  
"StateCnt"  32  
"StateMem"  0x200064e4  
  [0...99]  
    StateMem[0]  CTRL_SETUP  
    StateMem[1]  CTRL_SETUP_WAIT  
    StateMem[2]  CTRL_DATA_IN  
    StateMem[3]  CTRL_DATA_IN_WAIT  
    StateMem[4]  CTRL_STATUS_OUT  
    StateMem[5]  CTRL_STATUS_OUT_WAIT  
    StateMem[6]  CTRL_SETUP  
    StateMem[7]  CTRL_SETUP_WAIT  
    StateMem[8]  CTRL_DATA_IN  
    StateMem[9]  CTRL_DATA_IN_WAIT  
    StateMem[10]  CTRL_STATUS_OUT  
    StateMem[11]  CTRL_STATUS_OUT_WAIT  
    StateMem[12]  CTRL_SETUP  
    StateMem[13]  CTRL_SETUP_WAIT  
    StateMem[14]  CTRL_STATUS_IN  
    StateMem[15]  CTRL_STATUS_IN_WAIT  
    StateMem[16]  CTRL_SETUP  
    StateMem[17]  CTRL_SETUP_WAIT  
    StateMem[18]  CTRL_DATA_IN  
    StateMem[19]  CTRL_DATA_IN_WAIT  
    StateMem[20]  CTRL_STATUS_OUT  
    StateMem[21]  CTRL_STATUS_OUT_WAIT  
    StateMem[22]  CTRL_SETUP  
    StateMem[23]  CTRL_SETUP_WAIT  
    StateMem[24]  CTRL_DATA_IN  
    StateMem[25]  CTRL_DATA_IN_WAIT  
    StateMem[26]  CTRL_STATUS_OUT  
    StateMem[27]  CTRL_STATUS_OUT_WAIT  
    StateMem[28]  CTRL_SETUP  
    StateMem[29]  CTRL_SETUP_WAIT  
    StateMem[30]  CTRL_STATUS_IN  
    StateMem[31]  CTRL_STATUS_IN_WAIT

Bei State 31 entsteht dann der Fehler USBH_BUSY.

Michael

[Potter (Gast)]

Michael schrieb:
> Ein Zurückschalten auf
> Lowspeed habe ich auch bei den funktionierenden Sticks erstmal nicht
> hinbekommen, dann geht gar nichts mehr.

Weil Dein MSD Bulk-Transfer verwendet - also >= Full-Speed.