Forum: Mikrocontroller und Digitale Elektronik STM32 USB CDC will nicht mehr nach Kernel Update


von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Hi!

Habe gerade ein Kernel update gemacht und nun will der STM32 CDC Stack 
nicht mehr (bzw. linux mag ihn nicht mehr).


Beim öffnen des devices bekomme ich folgenden Fehler:
1
[ 1325.109770] cdc_acm 1-10:1.0: ttyACM0: USB ACM device
2
[ 1333.790160] cdc_acm 1-10:1.0: acm_port_activate - usb_submit_urb(ctrl irq) failed

Die Änderungen im Kernel-Source sehen für mich gut aus und der STM32 USB 
Stack hatte in der Vergangenheit immer wieder Macken.

Hat da jemand eine Idee dazu?

Der dump von lsusb:
1
Bus 001 Device 016: ID 0483:5740 STMicroelectronics Virtual COM Port
2
Device Descriptor:
3
  bLength                18
4
  bDescriptorType         1
5
  bcdUSB               2.00
6
  bDeviceClass            2 Communications
7
  bDeviceSubClass         2 Abstract (modem)
8
  bDeviceProtocol         0 
9
  bMaxPacketSize0        64
10
  idVendor           0x0483 STMicroelectronics
11
  idProduct          0x5740 Virtual COM Port
12
  bcdDevice            2.00
13
  iManufacturer           1 STMicroelectronics
14
  iProduct                2 STM32 Virtual ComPort
15
  iSerial                 3 204E37773453
16
  bNumConfigurations      1
17
  Configuration Descriptor:
18
    bLength                 9
19
    bDescriptorType         2
20
    wTotalLength       0x0043
21
    bNumInterfaces          2
22
    bConfigurationValue     1
23
    iConfiguration          0 
24
    bmAttributes         0xc0
25
      Self Powered
26
    MaxPower              100mA
27
    Interface Descriptor:
28
      bLength                 9
29
      bDescriptorType         4
30
      bInterfaceNumber        0
31
      bAlternateSetting       0
32
      bNumEndpoints           1
33
      bInterfaceClass         2 Communications
34
      bInterfaceSubClass      2 Abstract (modem)
35
      bInterfaceProtocol      1 AT-commands (v.25ter)
36
      iInterface              0 
37
      CDC Header:
38
        bcdCDC               1.10
39
      CDC Call Management:
40
        bmCapabilities       0x00
41
        bDataInterface          1
42
      CDC ACM:
43
        bmCapabilities       0x02
44
          line coding and serial state
45
      CDC Union:
46
        bMasterInterface        0
47
        bSlaveInterface         1 
48
      Endpoint Descriptor:
49
        bLength                 7
50
        bDescriptorType         5
51
        bEndpointAddress     0x82  EP 2 IN
52
        bmAttributes            3
53
          Transfer Type            Interrupt
54
          Synch Type               None
55
          Usage Type               Data
56
        wMaxPacketSize     0x0008  1x 8 bytes
57
        bInterval              16
58
    Interface Descriptor:
59
      bLength                 9
60
      bDescriptorType         4
61
      bInterfaceNumber        1
62
      bAlternateSetting       0
63
      bNumEndpoints           2
64
      bInterfaceClass        10 CDC Data
65
      bInterfaceSubClass      0 
66
      bInterfaceProtocol      0 
67
      iInterface              0 
68
      Endpoint Descriptor:
69
        bLength                 7
70
        bDescriptorType         5
71
        bEndpointAddress     0x01  EP 1 OUT
72
        bmAttributes            2
73
          Transfer Type            Bulk
74
          Synch Type               None
75
          Usage Type               Data
76
        wMaxPacketSize     0x0040  1x 64 bytes
77
        bInterval               0
78
      Endpoint Descriptor:
79
        bLength                 7
80
        bDescriptorType         5
81
        bEndpointAddress     0x81  EP 1 IN
82
        bmAttributes            2
83
          Transfer Type            Bulk
84
          Synch Type               None
85
          Usage Type               Data
86
        wMaxPacketSize     0x0040  1x 64 bytes
87
        bInterval               0
88
can't get device qualifier: Resource temporarily unavailable
89
can't get debug descriptor: Resource temporarily unavailable
90
Device Status:     0x0001
91
  Self Powered

von Stefan F. (Gast)


Lesenswert?

Mache mal den Gegentest mit dem alternativen Code von meiner Homepage, 
falls er zu deinem µC kompatibel ist: 
http://stefanfrings.de/stm32/index.html

Zum F4 ist er leider nicht kompatibel.

von Arno (Gast)


Lesenswert?

...und mit einem alten Kernel, um auszuschließen, dass das Zufall war.

Ansonsten ist meine USB-Zeit leider/zum Glück sehr lange her, aber dass 
die Deskriptoren ziemlich weitgehend gelesen werden können, ist 
eigentlich ein gutes Zeichen. Eventuell nimmt der STM32-Code irgendeine 
bestimmte Reihenfolge der Abfrage an, die sich mit neuem Kernel geändert 
hat? Oder manche Abfragen können jetzt parallelisiert werden statt 
vorher sequenziell abgearbeitet zu werden?

Das war vor 15 Jahren in "meinem" Code eine große Fehlerquelle - mit 
Linux gehts, mit Windows nicht, oder umgekehrt.

MfG, Arno

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Naja, ich befürchte auch, dass da ST mal wieder einen Bug drinnen hat.
Ansonsten hätte die Welt das Problem schon lange entdeckt und gefixed 
...

Ich glaube nicht, dass das ein Problem in meinem Code ist und auch 
nicht, dass es an der Hardware liegt.

Nach dem Update und dem Reboot gings nicht mehr. Ich habe noch eine 2. 
Hardware mit Code, der von jemand anderes geschrieben wurde. Selbes 
Problem.

Update der libs durchgeführt und die CubeIDE auf 1.6.1 gehievt -> selbes 
Problem.

Ich glaube, das wird mal wieder eine Mail an die Kernel Mailingliste..

73

von Stefan F. (Gast)


Lesenswert?

Hans W. schrieb:
> Naja, ich befürchte auch, dass da ST mal wieder einen Bug drinnen hat.

Wo, in Linux? Ich bezweifle, dass der CDC Treiber von Linux von ST kommt 
oder überhaupt ST spezifischen Code enthält.

Du solltest wirklich zwei Gegentests machen:

a) Läuft es mit einem älteren Kernel?
b) Läuft es mit einer anderen CDC Implementierung auf dem µC?

Punkt a müsste ganz simpel sein. Bei Debian Linux kann ich im 
Bootloader-Screen die vorherigen 4 oder 5 Kernel auswählen.

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

Zwar nicht genau das Problem des Posters hier, aber: Opensuse KOTD 
(5.12.x) liest ueber ACM-CDC<->Blackmagic<-> SWD mit der ACM-CDC 
Implementierung aus libopencm3/blackmagic nur etwas halb so schnell wie 
5.3.18.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Stefan ⛄ F. schrieb:
> Hans W. schrieb:
>> Naja, ich befürchte auch, dass da ST mal wieder einen Bug drinnen hat.
>
> Wo, in Linux? Ich bezweifle, dass der CDC Treiber von Linux von ST kommt
> oder überhaupt ST spezifischen Code enthält.
>
> Du solltest wirklich zwei Gegentests machen:
>
> a) Läuft es mit einem älteren Kernel?
> b) Läuft es mit einer anderen CDC Implementierung auf dem µC?
>
> Punkt a müsste ganz simpel sein. Bei Debian Linux kann ich im
> Bootloader-Screen die vorherigen 4 oder 5 Kernel auswählen.

Wie oben geschrieben: Es läuft mit 5.10.26 und es läuft nicht mit 
5.10.30.

Es scheint in 5.10.28 ein Problem eingebaut worden zu sein... oder 
irgendetwas in 5.10.28 triggert ein Problem im STM32... wie man's nimmt.

Der CDC Treiber am STM32 kommt von ST und die sind nunja... ähnlicher 
Qualität wie halt der Rest von ST (oder den anderen Embedded Buden).
Sprich: Es läuft bei der Ferialkraft die das verbricht am Tisch und ist 
daher tauglich...


Und ja, ich habe 2x idente Hardware mit 2x Firmware von verschiedenen 
Personen. In 5.10.26 gehen alle Kombinationen und in 5.10.30 keine 
einzige.

73

von Gerd E. (robberknight)


Lesenswert?

Hans W. schrieb:
> Wie oben geschrieben: Es läuft mit 5.10.26 und es läuft nicht mit
> 5.10.30.
>
> Es scheint in 5.10.28 ein Problem eingebaut worden zu sein...

Wenn Du es schon so weit eingegrenzt hast, würde ich vorschlagen den 
letzten Rest des Weges auch noch zu gehen und einen Kernel-bisect zu 
machen. Dann findest du den konkreten Patch der das auslöst. Dank 
binärer Suche dauert das nicht lange.

Mit dem konkreten Patch dürfte es nicht schwer sein die eigentliche 
Ursache zu finden und dann entweder den Code für den Mikrocontroller zu 
fixen oder mit den Linux-Entwicklern auf der kernel-usb-Mailingliste das 
Problem auf Linux-Seite anzugehen.

von Bernd N. (_bn_)


Lesenswert?

Hans W. schrieb:
> Sprich: Es läuft bei der Ferialkraft die das verbricht am Tisch und ist
> daher tauglich...

Wenn das deine Überzeugung ist warum verwendest du dann ST ? Machs doch 
selbst.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Bernd N. schrieb:
> Hans W. schrieb:
>> Sprich: Es läuft bei der Ferialkraft die das verbricht am Tisch und ist
>> daher tauglich...
>
> Wenn das deine Überzeugung ist warum verwendest du dann ST ? Machs doch
> selbst.

Weil die anderen auch keinen besseren Code fabrizieren.

Und ja, ich habe schon haufenweise "Ersatzcode"...

Wie dem auch sei, ein wahrscheinlicher Fix wurde gestern in den usb-next 
branch eingespielt... da war ich anscheinend nicht der allererste, der 
das gemeldet habe aber ganz knapp dran. Es dürfte ausnahmsweise mal nur 
ein Problem im Kernel sein.

Nur falls es jemanden interessiert der Commit ist dieser hier:
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=a8b3b519618f30a87a304c4e120267ce6f8dc68a

Muss den Patch mal auf meinen 5.10.30 anwenden.
73

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Zur Info: Patch ist verifiziert.

73

von Stefan F. (Gast)


Lesenswert?

Hans W. schrieb:
> Zur Info: Patch ist verifiziert.

Was einst du damit. Löst der Patch dein Problem? Oder wolltest du uns 
mitteilen, dass jemand anders ihn als "verifiziert" markiert hat?

von Hans (Gast)


Lesenswert?

Der Patch wurde auf Bugzilla als wahrscheinlicher fix vorgeschlagen.
Verifiziert bezieht sich darauf, dass alle Geräte mit einem STM32 und 
dem USB-CDC Stack von ST bei mir jetzt wieder gehen.

73

von Stefan F. (Gast)


Lesenswert?

Hans schrieb:
> alle Geräte mit einem STM32 und
> dem USB-CDC Stack von ST bei mir jetzt wieder gehen.

Ah OK. Das freut mich für dich.

von Johannes S. (Gast)


Lesenswert?

na für die ST Verdächtigung ist jetzt ja wohl mindestens ein Gang nach 
Canossa nötig :)

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.