STM32 USB CDC will nicht mehr nach Kernel Update

Hans W. OP (Firma: Wilhelm.Consulting) #6666048
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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Arno Gast #6666104
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Hans W. OP (Firma: Wilhelm.Consulting) #6666235
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan F. Gast #6666259
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Hans W. OP (Firma: Wilhelm.Consulting) #6666290
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Gerd E. #6666486
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Hans W. OP (Firma: Wilhelm.Consulting) #6666802
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren