STM32 USB: Erkennung von Verbindung und Trennung

Wie erkennen Sie am Beispiel des USB-Massenspeicher-Controllers STM32F4 im Gerätemodus Verbindungen und Trennungen mit einem Host-Controller?

Ich habe versucht, den VBUS-Pin-Status abzufragen, aber er könnte von einem Wandadapter hoch oder ohne Kommunikation mit dem Host hoch sein.

Gibt es ein Register zu überprüfen? Ich habe DSTS (Status, schätze ich?) in den USB-Bibliotheksstrukturen bemerkt, konnte aber weder seine Dokumentation noch nützliche Kommentare im Code finden.

Wenden Sie sich mit dieser Frage an das STM-Forum, senden Sie eine E-Mail an den technischen Support. Ist dies eine benutzerdefinierte Platine mit STM32 darauf oder eine Entdeckungs-/andere Entwicklungsplatine?
Das Sehen der USB-Bus-Aktivität wäre ein starker Hinweis.

Antworten (7)

Sie können die Verbindung und Trennung anhand dieser Datei erkennen:

usbd_core.c

und die API dafür ist diese

USBD_StatusTypeDef USBD_LL_DevConnected(USBD_HandleTypeDef  *pdev)
USBD_StatusTypeDef USBD_LL_DevDisconnected(USBD_HandleTypeDef  *pdev)

Ich bin mir bei der USB-Massenspeicherklasse nicht sicher, aber in der CDC-Klasse erkennen die beiden oben genannten APIs die USB-Verbindung und -Trennung, vielleicht hilft das

Dinge zu beachten:

  • Verbindung > wenn das physische USB-Kabel an den USB-Anschluss angeschlossen ist
  • Trennung > wenn das physische USB-Kabel vom USB-Anschluss getrennt wird

Ich habe STMCubeMX verwendet, um die USB-CDC-Klasse zu generieren.

usbd_core.chat USBD_StatusTypeDef USBD_LL_DevConnected(USBD_HandleTypeDef *pdev) { return USBD_OK; }...Wie funktioniert das?
OP fragt, wie die Verbindung erkannt werden soll, nicht, was zu tun ist, nachdem sie erkannt wurde.
Dies scheint die richtige Antwort zu sein, aber AFAICS dieser Code ist nur aktiv, wenn USB OTG ist.
Aber diese Rückrufe sind bereits in usbd_core.c implementiert und Sie können dort keinen Benutzercode hinzufügen. Wie kann das Ereignis also vom Benutzer behandelt werden?
Ich meine, wenn Sie CubeMx verwenden, wird Ihr Code jedes Mal überschrieben, wenn Sie auf die Schaltfläche "Generieren" klicken.
Um das erwähnte Problem zu lösen, können Sie die Datei bearbeiten C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeMX\db\templates\usbdconf_f7_c.ftl(abhängig von Ihrem Boardnamen) und einfach die Implementierung der Callbacks in dieser Datei löschen. Jetzt können Sie Ihre eigene Implementierung in Ihre Dateien einfügen und CubeMx wird Ihren Code nicht überschreiben.
void HAL_PCD_SuspendCallback(PCD_HandleTypeDef *hpcd)
{
  /* Inform USB library that core enters in suspend Mode. */
  USBD_LL_Suspend((USBD_HandleTypeDef*)hpcd->pData);
......

in usbd_conf.c

Funktion ruft beim Trennen des USB-Kabels auf

(getestet auf Massenspeichergerät, CubeMX)

Für die Leute, die die von CubeMX hergestellten "User Code" -Teile verwenden möchten, wird dieser Callback aufgerufen, wenn USB an das System angeschlossen wird.

void HAL_PCD_ResumeCallback(PCD_HandleTypeDef *hpcd)

Und dieser wird aufgerufen, wenn USB vom System getrennt wird.

void HAL_PCD_SuspendCallback(PCD_HandleTypeDef *hpcd)

Beide Funktionen befinden sich in usbd_conf.c

Der beste Weg, der in den Software-Stack von ST passt, ist die Implementierung dieser Funktionen:

void HAL_PCD_ConnectCallback(PCD_HandleTypeDef *hpcd);
void HAL_PCD_DisconnectCallback(PCD_HandleTypeDef *hpcd);

Diese werden mit schwacher Verknüpfung im HAL-Stack deklariert, sodass Ihre Implementierungen die HAL-Do-Nothing-Stubs außer Kraft setzen.

Wenn Sie jedoch Cube verwenden, finden Sie diese bereits implementiert usbd_conf.cund aus unbekannten Gründen gibt es keine /* USER CODE BEGIN */Abschnitte in diesen Funktionen, sodass Cube Ihren Code beim nächsten Speichern überschreibt. Bis ST dies behebt, müssen Sie Cube entweder nicht verwenden (ich verwende es, um ein Projekt zu booten, dann höre ich auf, es zu verwenden und übernehme die Kontrolle), oder Sie können die Cube-Vorlage für diese Datei ändern.

Suchen Sie im [CUBE-INSTALL-DIR]/db/templatesVerzeichnis die usbdconf_XX.ftlDatei für Ihre MCU. zB für das f4 wird es sein usbdconf_f4_c.ftl. Bearbeiten Sie diese Datei nun so, dass sie eindeutige Blöcke USER CODE BEGINund USER CODE ENDKommentarblöcke enthält. Wenn Sie das nächste Mal Quellcode generieren, haben Sie einen Abschnitt, in dem Sie Ihren Code platzieren können.

Ich verwende STM32F767ZI und hatte das gleiche Problem, dass USB nicht als virtueller COM-Port erkannt wurde, also habe ich den minimalen Heap-Stack 2000 und die maximale Heap-Größe von 4000 und Boom hinzugefügt !! Es fing an zu arbeiten.

In meinem Projekt verwende ich die Callbacks, die in der folgenden Struktur initialisiert / registriert werden:

typedef struct _USBD_CDC_Itf
{
  int8_t (* Init)(void);   // <- triggered on connection
  int8_t (* DeInit)(void); // <- triggered on disconnection

  int8_t (* Control)(uint8_t cmd, uint8_t *pbuf, uint16_t length);
  int8_t (* Receive)(uint8_t *Buf, uint32_t *Len);
  int8_t (* TransmitCplt)(uint8_t *Buf, uint32_t *Len, uint8_t epnum);
} USBD_CDC_ItfTypeDef;

Die Antwort ist sehr einfach. Genauso wie Sie es mit VBUS versucht haben, versuchen Sie es mit DSTS und sehen Sie, was passiert! Viel Glück.

Das ist kaum eine Antwort. Die Frage besagt, dass DSTS nicht eindeutig dokumentiert ist. Haben Sie irgendwelche Erkenntnisse hinzuzufügen? Oder schlagen Sie vor, den Wert einfach zu protokollieren, um zu sehen, was passiert, ohne sich die Mühe zu machen, zu verstehen, was er darstellt?
Vermutlich spricht @Guill darüber: „Bit0 SUSPSTS:Suspendstatus Im Gerätemodus ist dieses Bit gesetzt, solange ein Suspend-Zustand auf dem USB erkannt wird. Der Kern wechselt in den Suspended-Zustand, wenn keine Aktivität auf den USB-Datenleitungen für einen Zeitraum von 3 ms. Der Core kommt aus dem Suspend: – Bei Aktivität auf den USB-Datenleitungen"
Einverstanden, aber als Profi, der mit diesem schrecklichen USB-Kern und der zugehörigen Dokumentation zu kämpfen hat, ist dies unnötig ärgerlich.