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

[Wastl (hartundweichware)]

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.

[Flip B. (frickelfreak)]

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

[Dieter S. (ds1)]

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

[Nemopuk (nemopuk)]

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

[Wastl (hartundweichware)]

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.

[Wastl (hartundweichware)]

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.

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

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.

[Marc X. (marc_x)]

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.

[Niklas G. (erlkoenig)]

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.

[Harald K. (kirnbichler)]

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

[Wastl (hartundweichware)]

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.

[Niklas G. (erlkoenig)]

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.

[Thomas Z. (usbman)]

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

[Niklas G. (erlkoenig)]

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

Wo steht das?

[Thomas Z. (usbman)]

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

[Niklas G. (erlkoenig)]

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?

[Thomas Z. (usbman)]

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

[Niklas G. (erlkoenig)]

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?

[Rainer W. (rawi)]

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

[Wastl (hartundweichware)]

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.

[Malte _. (malte)]

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.

lsusb -v -d 0483:374b


Bus 001 Device 006: ID 0483:374b STMicroelectronics ST-LINK/V2.1
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x0483 STMicroelectronics
  idProduct          0x374b ST-LINK/V2.1
  bcdDevice            1.00
  iManufacturer           1 STMicroelectronics
  iProduct                2 STM32 STLink
  iSerial                 3 0669FF515055657867174849
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0080
    bNumInterfaces          4
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              300mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              4 ST-Link Debug
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              5 ST-Link mass storage
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         2
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       2 Abstract (modem)
      bFunctionProtocol       1 AT-commands (v.25ter)
      iFunction               6 ST-Link VCP Ctrl
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              6 ST-Link VCP Ctrl
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          3
      CDC ACM:
        bmCapabilities       0x06
          sends break
          line coding and serial state
      CDC Union:
        bMasterInterface        2
        bSlaveInterface         3 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval             255
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              7 ST-Link VCP Data
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x05  EP 5 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)

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

[Wastl (hartundweichware)]

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.

[Nemopuk (nemopuk)]

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?