STM32 Nucleo Boards können UART Serial I/O und ST-Link debuggen

Ich weiß nicht wie STM das gemacht hat, aber bei Freescale sind UART und Jtag-Debug zwei unabhängige USB-Endpunkte.

Dir ist schon klar dass das ein USB Composite Device mit UART und Debugger ist?

Wastl schrieb:

Wie schafft es der ST-Link auf dem Nucleo-Board zu unterscheiden ob ein Zeichen für der User-UART bestimmt ist oder für den Debug-Kanal?

Weil es ein USB Composite Device ist. Im Gerätemanager erscheinen beim Anschließen zwei Geräte. Zur Unterscheidung der Kanäle dient die "Endpoint" Nummer.

Siehe https://www.mikrocontroller.net/articles/USB-Tutorial_mit_STM32

Nemopuk schrieb:

Weil es ein USB Composite Device ist. Im Gerätemanager erscheinen beim Anschließen zwei Geräte. Zur Unterscheidung der Kanäle dient die "Endpoint" Nummer.

OK, das ist plausibel und verständlich.

Nemopuk schrieb:

Im Gerätemanager erscheinen beim Anschließen zwei Geräte.

... und hier die Bestätigung dafür. Ist mir im Eifer des Gefechts bisher nicht aufgefallen.

Wastl schrieb:

Wie schafft es der ST-Link auf dem Nucleo-Board zu unterscheiden ob ein Zeichen für der User-UART bestimmt ist oder für den Debug-Kanal? Immerhin muss der ST-Link ja die User-Daten durchleiten zum UART auf dem Nutzer-STM32.

Der muss da nichts schaffen, denn der UART-Anschluss des ST-LINK-2V1 ist völlig unabhängig von der Programmier- und Debugverbindung. Es gibt sogar noch eine kleine virtuelle Festplatte, sobald man ein Nucleo-Board an den PC anschließt – da sollte man aber nicht einfach so herumfummeln (ziellos irgendetwas, verändern, abspeichern oder löschen). Soweit ich mich zu meinen Tests erinnern kann, wird die UART-Schnittstelle des STM32F103CB pinmäßig erst dann aktiviert, sobald man versucht, ein Zeichen zu übertragen – vorher ist der Tx-Ausgang noch nicht aktiviert, um möglichst Pinkonflikte zu vermeiden, da hier keinerlei Schutzwiderstände zum Target-STM32 des Boards konzipiert worden sind. In meinem Pro, der als Verbesserung des ST-LINK-2V1-Konzepts fungiert, habe ich unter anderem so einen Pinschutz vorgesehen – ich biete aber nur die Leiterplatte an, die Software für den F103CB muss man sich schon auf eigene Verantwortung selbst besorgen und einspielen. Im Netz findet man dazu die nötigen Informationen – man muss nur suchen.

Gregor J. schrieb:

Der muss da nichts schaffen, denn der UART-Anschluss des ST-LINK-2V1 ist völlig unabhängig von der Programmier- und Debugverbindung. Es gibt sogar noch eine kleine virtuelle Festplatte, sobald man ein Nucleo-Board an den PC anschließt – da sollte man aber nicht einfach so herumfummeln (ziellos irgendetwas abspeichern).

Das ist kein realer Speicher, du kannst ein Binary oder Intel Hex File draufschieben und der ST-Link programmiert den Inhalt auf den Target Controller.

Wastl schrieb:

Am ehesten könnte ich mir eine ESC-Sequenz vorstellen die jedem Datenstrom von der Debugger-Software an die ST-Link-Firmware vorausgeht.

Naja so falsch ist das nicht; jedes USB-Datenpaket hat einen Header, in dem drin steht, an welchen USB-Endpoint es gerichtet ist. Endpoints sind so eine Art virtuelle Kanäle bei USB. An der Stelle hat das noch gar nichts mit UART zu tun. Viele Arten von USB-Geräten haben mehrere Endpoints um alle möglichen Daten nebenläufig zu übertragen. Hier sind es halt Debugging-Daten und UART-Daten auf den unterschiedlichen Endpoints. Unter Linux mit "lsusb -v" kann man sich die Endpoints anzeigen lassen.

Niklas G. schrieb:

Unter Linux mit "lsusb -v" kann man sich die Endpoints anzeigen lassen.

Oder unter Windows mit dem USB Device Tree Viewer von Uwe Sieber:

https://www.uwe-sieber.de/usbtreeview.html

Niklas G. schrieb:

Naja so falsch ist das nicht; ........

Als mir nemopuk um 14:25 schrieb fiel es mir dann doch wie Schuppen von den Haaren. Klaro, die verschiedenen Endpoints machen es möglich, nur der Gesamt-Datenstrom muss zwischen den einzelnen Endpoints "ge-shared" werden. Im Prinzip könnten es noch mehr getrennte logische Datenströme sein.

Wastl schrieb:

nur der Gesamt-Datenstrom muss zwischen den einzelnen Endpoints "ge-shared" werden.

Das Aufteilen erledigt die USB-Hardware des Mikrocontrollers, plus noch mehr Funktionalität wie Flusskontrolle, Prüfsummen, Wiederholungen. Daher ist es auch so schön praktisch Geräte direkt mit nativem USB zu implementieren, anstatt mit dem UART rumzufummeln und das alles selbst zu basteln.

Nemopuk schrieb:

Weil es ein USB Composite Device ist.

Das ist übrigens gar nicht nötig für die Aufteilung auf Endpoints; auch nicht-composite Geräte können mehrere Endpoints haben. CDC-ACM Geräte (die Standardklasse für USB-Serial Adapter) haben 3 Endpoints pro virtueller serieller Schnittstelle.

Ein CDC-ACM Gerät kann dann auch mehrere Schnittstellen zur Verfügung stellen, ohne ein Composite Device zu sein, nur Windows kommt damit nicht klar (Linux schon), weshalb man extra für Windows das Gerät noch als Composite deklarieren muss.

Ein CDC-ACM Gerät kann dann auch mehrere Schnittstellen zur Verfügung stellen, ohne ein Composite Device zu sein, nur Windows kommt damit nicht klar

Windows kann das auch. Es ist aber ganz klar vorgeschrieben, dass eine Funktion die mehrere Eps bedient entsprechende IAD Deskriptoren haben soll, wenn die entsprechende Spec neuer als IAD ist. Leider hält sich auch die usb.org nicht an die eigenen Vorgaben wie man an usbmidi2 sehen kann.

Vermutlich sind die diversen Kompatibilitätsschichten die Ursache für das Durcheinander. Es ist jetzt auch zu spät daran noch was zu ändern. Weshalb vieles in den usb class Specs halt nur noch Flickwerk ist.

Thomas Z. schrieb:

. Es ist aber ganz klar vorgeschrieben, dass eine Funktion die mehrere Eps bedient entsprechende IAD Deskriptoren haben soll

Wo steht das?

Niklas G. schrieb:

Thomas Z. schrieb:

. Es ist aber ganz klar vorgeschrieben, dass eine Funktion die mehrere Eps bedient entsprechende IAD Deskriptoren haben soll

Wo steht das?

mm ich sollte so spät (früh) nicht mehr schreiben.... Das war natütlich Unsinn und sollte heisen:

Es ist aber ganz klar vorgeschrieben, dass eine Funktion die mehrere Interfaces bedient entsprechende IAD Deskriptoren haben soll.

Sorry für die Verwirrung

Thomas Z. schrieb:

Es ist aber ganz klar vorgeschrieben, dass eine Funktion die mehrere Interfaces bedient entsprechende IAD Deskriptoren haben soll.

Aber in welcher Spezifikation steht das?

hier die spec. Das wurde entworfen weil ja vorher die Regel bestand ein Interface-> ein Treiber. Usbaudio 1.0 verletzte das ja schon mit Control und Stream Interface. Ab der Verfügbarkeit von IAD sollte deshalb IAD für Multi Interface verwendet werden. CDC war die erste Class Spec wo das zur anwendung kommen sollte.

vgl auch Jan Axelson Serial Complete / Usb Complete

Thomas Z. schrieb:

CDC war die erste Class Spec wo das zur anwendung kommen sollte.

Tja, gilt für CDC eine völlig separate Spec die in der CDC Spec nicht erwähnt wird?

Wastl schrieb:

Als mir nemopuk um 14:25 schrieb

Die "Markierten Text zitieren"-Funktion kennst du? Dann landet man sogar automatisch auf dem richtigen Tag.

Nemopuk schrieb:

Weil ...

Rainer W. schrieb:

Die "Markierten Text zitieren"-Funktion kennst du?

Die Suchfunktion deines Browsers kennst du? Damit kommt man automagisch zum Beitrag mit der entsprechenden Uhrzeit.

Ich kann keine Verpflichtung zum Verwenden der Zitat-Funktion erkennen.

ST hat sogar gleich vier Devices implementiert: Mein ST Board kann ich auch als Datenträger mounten und dann ein Programm per Dateibrowser übertragen :) Wofür das 4. ist weiß ich gerade nicht.

1

lsusb -v -d 0483:374b

2

3

4

Bus 001 Device 006: ID 0483:374b STMicroelectronics ST-LINK/V2.1

5

Device Descriptor:

6

  bLength                18

7

  bDescriptorType         1

8

  bcdUSB               2.00

9

  bDeviceClass          239 Miscellaneous Device

10

  bDeviceSubClass         2 

11

  bDeviceProtocol         1 Interface Association

12

  bMaxPacketSize0        64

13

  idVendor           0x0483 STMicroelectronics

14

  idProduct          0x374b ST-LINK/V2.1

15

  bcdDevice            1.00

16

  iManufacturer           1 STMicroelectronics

17

  iProduct                2 STM32 STLink

18

  iSerial                 3 0669FF515055657867174849

19

  bNumConfigurations      1

20

  Configuration Descriptor:

21

    bLength                 9

22

    bDescriptorType         2

23

    wTotalLength       0x0080

24

    bNumInterfaces          4

25

    bConfigurationValue     1

26

    iConfiguration          0 

27

    bmAttributes         0x80

28

      (Bus Powered)

29

    MaxPower              300mA

30

    Interface Descriptor:

31

      bLength                 9

32

      bDescriptorType         4

33

      bInterfaceNumber        0

34

      bAlternateSetting       0

35

      bNumEndpoints           3

36

      bInterfaceClass       255 Vendor Specific Class

37

      bInterfaceSubClass    255 Vendor Specific Subclass

38

      bInterfaceProtocol    255 Vendor Specific Protocol

39

      iInterface              4 ST-Link Debug

40

      Endpoint Descriptor:

41

        bLength                 7

42

        bDescriptorType         5

43

        bEndpointAddress     0x81  EP 1 IN

44

        bmAttributes            2

45

          Transfer Type            Bulk

46

          Synch Type               None

47

          Usage Type               Data

48

        wMaxPacketSize     0x0040  1x 64 bytes

49

        bInterval               0

50

      Endpoint Descriptor:

51

        bLength                 7

52

        bDescriptorType         5

53

        bEndpointAddress     0x01  EP 1 OUT

54

        bmAttributes            2

55

          Transfer Type            Bulk

56

          Synch Type               None

57

          Usage Type               Data

58

        wMaxPacketSize     0x0040  1x 64 bytes

59

        bInterval               0

60

      Endpoint Descriptor:

61

        bLength                 7

62

        bDescriptorType         5

63

        bEndpointAddress     0x82  EP 2 IN

64

        bmAttributes            2

65

          Transfer Type            Bulk

66

          Synch Type               None

67

          Usage Type               Data

68

        wMaxPacketSize     0x0020  1x 32 bytes

69

        bInterval               0

70

    Interface Descriptor:

71

      bLength                 9

72

      bDescriptorType         4

73

      bInterfaceNumber        1

74

      bAlternateSetting       0

75

      bNumEndpoints           2

76

      bInterfaceClass         8 Mass Storage

77

      bInterfaceSubClass      6 SCSI

78

      bInterfaceProtocol     80 Bulk-Only

79

      iInterface              5 ST-Link mass storage

80

      Endpoint Descriptor:

81

        bLength                 7

82

        bDescriptorType         5

83

        bEndpointAddress     0x83  EP 3 IN

84

        bmAttributes            2

85

          Transfer Type            Bulk

86

          Synch Type               None

87

          Usage Type               Data

88

        wMaxPacketSize     0x0040  1x 64 bytes

89

        bInterval               0

90

      Endpoint Descriptor:

91

        bLength                 7

92

        bDescriptorType         5

93

        bEndpointAddress     0x03  EP 3 OUT

94

        bmAttributes            2

95

          Transfer Type            Bulk

96

          Synch Type               None

97

          Usage Type               Data

98

        wMaxPacketSize     0x0040  1x 64 bytes

99

        bInterval               0

100

    Interface Association:

101

      bLength                 8

102

      bDescriptorType        11

103

      bFirstInterface         2

104

      bInterfaceCount         2

105

      bFunctionClass          2 Communications

106

      bFunctionSubClass       2 Abstract (modem)

107

      bFunctionProtocol       1 AT-commands (v.25ter)

108

      iFunction               6 ST-Link VCP Ctrl

109

    Interface Descriptor:

110

      bLength                 9

111

      bDescriptorType         4

112

      bInterfaceNumber        2

113

      bAlternateSetting       0

114

      bNumEndpoints           1

115

      bInterfaceClass         2 Communications

116

      bInterfaceSubClass      2 Abstract (modem)

117

      bInterfaceProtocol      1 AT-commands (v.25ter)

118

      iInterface              6 ST-Link VCP Ctrl

119

      CDC Header:

120

        bcdCDC               1.10

121

      CDC Call Management:

122

        bmCapabilities       0x00

123

        bDataInterface          3

124

      CDC ACM:

125

        bmCapabilities       0x06

126

          sends break

127

          line coding and serial state

128

      CDC Union:

129

        bMasterInterface        2

130

        bSlaveInterface         3 

131

      Endpoint Descriptor:

132

        bLength                 7

133

        bDescriptorType         5

134

        bEndpointAddress     0x84  EP 4 IN

135

        bmAttributes            3

136

          Transfer Type            Interrupt

137

          Synch Type               None

138

          Usage Type               Data

139

        wMaxPacketSize     0x0002  1x 2 bytes

140

        bInterval             255

141

    Interface Descriptor:

142

      bLength                 9

143

      bDescriptorType         4

144

      bInterfaceNumber        3

145

      bAlternateSetting       0

146

      bNumEndpoints           2

147

      bInterfaceClass        10 CDC Data

148

      bInterfaceSubClass      0 

149

      bInterfaceProtocol      0 

150

      iInterface              7 ST-Link VCP Data

151

      Endpoint Descriptor:

152

        bLength                 7

153

        bDescriptorType         5

154

        bEndpointAddress     0x05  EP 5 OUT

155

        bmAttributes            2

156

          Transfer Type            Bulk

157

          Synch Type               None

158

          Usage Type               Data

159

        wMaxPacketSize     0x0008  1x 8 bytes

160

        bInterval               0

161

      Endpoint Descriptor:

162

        bLength                 7

163

        bDescriptorType         5

164

        bEndpointAddress     0x85  EP 5 IN

165

        bmAttributes            2

166

          Transfer Type            Bulk

167

          Synch Type               None

168

          Usage Type               Data

169

        wMaxPacketSize     0x0010  1x 16 bytes

170

        bInterval               0

171

Device Status:     0x0000

172

  (Bus Powered)

Edit: Keine Ahnung warum die Forensoftware da jetzt extra Zeilenumbrüche einbaut.

Malte _. schrieb:

Keine Ahnung warum die Forensoftware da jetzt extra Zeilenumbrüche einbaut.

Keine Ahnung warum du es nichst schaffst, die Hinweise zum Posten von langen Codes/Texten zu lesen, zu verstehen und umzusetzen.

Wastl schrieb:

Keine Ahnung warum du es nichst schaffst, die Hinweise zum Posten von langen Codes/Texten zu lesen, zu verstehen und umzusetzen.

Wetten, der Text war im Original viel kürzer?