Forum: Mikrocontroller und Digitale Elektronik STM32 Nucleo Boards können UART Serial I/O und ST-Link debuggen


von Wastl (hartundweichware)


Lesenswert?

Ja, man kann UART Serial I/O betreiben und ST-Link debuggen
über den gleichen USB Connector, und das gleichzeitig!

Manche von euch mögen das bereits herausgefunden haben, ich erst
vor kurzem. Das spart eine Menge an zusätzlicher Verdrahtungs-
arbeit bzw. Logistik. Und einen externen UART wie z.B. den FT232
braucht es auch nicht.

Was mich zu der Frage an euch bringt, vielleicht weiss es jemand
zu erklären. 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. Das auch noch in
beide Richtungen und mit Baudraten die der Nutzer auf seiner
Anwendung eingestellt hat und abweichen können von der Baudrate
die die ST-Link Debugger-Software nutzt.

Am ehesten könnte ich mir eine ESC-Sequenz vorstellen die jedem
Datenstrom von der Debugger-Software an die ST-Link-Firmware
vorausgeht. Ob das Performance- bzw. Geschwindigkeits-relevant
ist liegt jenseits meiner Vorstellungen.

Hab ich was übersehen? Ich wüsste jetzt nicht welches "RTFM" ich
hätte tun müssen.

von Flip B. (frickelfreak)


Lesenswert?

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

von Dieter S. (ds1)


Lesenswert?

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

von Nemopuk (nemopuk)


Lesenswert?

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

: Bearbeitet durch User
von Wastl (hartundweichware)


Lesenswert?

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.

von Wastl (hartundweichware)


Angehängte Dateien:

Lesenswert?

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.

von Gregor J. (Firma: Jasinski) (gregor_jasinski)



Lesenswert?

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.

: Bearbeitet durch User
von Marc X. (marc_x)


Lesenswert?

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.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

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

von Wastl (hartundweichware)


Lesenswert?

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.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

> 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.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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

Wo steht das?

von Thomas Z. (usbman)


Lesenswert?

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

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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?

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

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

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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?

von Rainer W. (rawi)


Lesenswert?

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 ...

von Wastl (hartundweichware)


Lesenswert?

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.

von Malte _. (malte) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von Wastl (hartundweichware)


Lesenswert?

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.

von Nemopuk (nemopuk)


Lesenswert?

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?

: Bearbeitet durch User
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.