Ist es möglich, den virtuellen COM-Port von ST-LINK zum Laufen zu bringen, ohne ein Programm in Ubuntu zu starten?

Ich habe einige Entwicklungen auf einem Nucleo-64-Board (insbesondere dem NUCLEO-F303RE mit dem STM32F303RE-Mikrocontroller) durchgeführt und OpenOCD und GDB mit verwendet, target remote :3333um meinen Code (mit load) auf meinen Mikrocontroller zu flashen.

Während dieser Zeit habe ich den virtuellen COM-Port des ST-LINK auf meinem Linux-Rechner (Ubuntu 16.04 (Xenial Xerus)) verwendet, um mit dem USART des Mikrocontrollers zu sprechen. Jetzt möchte ich einfach den virtuellen COM-Port verwenden, um mit dem Mikrocontroller zu sprechen, ohne OpenOCD oder GDB starten zu müssen.

Ich war überrascht zu entdecken, dass dies nicht nur funktioniert. Die Symptome sind, dass mein Gerät weder vom Host gesendete Bytes noch umgekehrt empfängt. (Ich erkenne Bytes, die am Zielgerät ankommen, indem ich eine LED blinken lasse.) Daher scheint es, dass der Status des ST-LINK-Mikrocontrollers oder vielleicht des Linux-Kernels auf meinem Host-Computer irgendwie durch den Verbindungsvorgang über OpenOCD und geändert wird Flashen des Programms.

Meine Hauptfrage ist: Ist es möglich, auf meinem Ubuntu 16.04-Rechner zu diesem virtuellen COM-Port-Arbeitszustand zu gelangen, ohne OpenOCD oder GDB zu starten? Im Idealfall müsste ich kein zusätzliches Programm verwenden, sondern vielleicht nur einige Konfigurationseinstellungen ändern.

Meine zweite Frage ist: Warum passiert das? Ändert das ST-LINK-Gerät selbst hier den Modus?

Und meine dritte Frage: Warum passiert folgendes und was kann ich dagegen tun? Manchmal kann der Ziel-Mikrocontroller auch nach erfolgreichem Flashen Bytes erfolgreich senden, aber nicht empfangen. Außerdem glaube ich, dass eines meiner Boards mit dieser Methode weder Bytes senden noch empfangen kann, obwohl die Firmware anscheinend problemlos hochgeladen wird.

Unter MacOS 10.12.1 ist mein Ziel-Mikrocontroller sofort verbunden und wie gewünscht (ohne weitere Befehlsausführung oder Firmware-Flashing) über den virtuellen COM-Port unter z. B. /dev/tty.usbmodem1423. Daher vermute ich jetzt, dass das Problem bei der Linux-Kernel-Seite und dem Treiber liegt, der /dev/ttyACM0.

Sie sollten nur den Treiber installieren können und er verhält sich wie ein COM-Port.
Ja, das Board/die Familie wird funktionieren. einige der Kerne nein einige ja, sagt die Dokumentation. Kein Grund, openocd oder gdb zu verwenden, diese Typen werden als virtuelle Flash-Laufwerke bereitgestellt. Sie kopieren einfach die .bin-Datei auf das virtuelle Flash-Laufwerk, um die Binärdatei in den Flash auf der Ziel-MCU herunterzuladen / zu programmieren. Die Debug-MCU bietet zusammen mit der Bereitstellung von Stlink einen virtuellen USB-COM-Port, der eine Verbindung zum RX/TX auf der Ziel-MCU herstellt. Für Ubuntu nein müssen Sie nichts installieren, nur minicom nach /dev/ttyACM0 und Ihre .bin-Datei in das gemountete virtuelle Dateisystem kopieren.
Jetzt sagen Sie, dass Sie je nach Alter Ihres Boards möglicherweise die Firmware auf dem Debug-MCU aktualisieren müssen, der Stlink von Ihnen wird. Es gibt ein Java-basiertes Tool, das unter Ubuntu/Linux einwandfrei funktioniert und mit dem Sie Ihr Board aktualisieren können. Es hilft bei Problemen, z. B. kann die .bin-Datei nur einige Male geschrieben werden, dann heißt es, sie sei voll, muss ausgesteckt und wieder eingesteckt werden. Die Tafel. Wenn Sie minicom mit ACM0 verbunden lassen, selbst mit der neuesten Firmware, kann es manchmal stören und Ihnen zunächst nicht die richtigen Daten liefern. Ich neige dazu, minicom zu schließen, bevor Sie den Stecker ziehen, wenn es notwendig ist.
Wie ich oben versucht habe zu erklären, habe ich keine Probleme, das Board zu flashen. Mein Problem ist die Kommunikation mit dem STM32F303RE über den virtuellen COM-Port.
Es ist möglich, dass der Modemmanager den virtuellen seriellen Port abgreift und versucht, Befehle zu senden, um herauszufinden, um welche Art von Modem es sich handelt. Der Empfang dieser unerwarteten Befehle kann den Status Ihres Programms beeinträchtigen, wenn Sie sich endlich mit ihm verbinden, sodass es so aussieht, als ob die virtuelle serielle Schnittstelle nicht richtig funktioniert. Die Verwendung von gdb/openocd zum Zurücksetzen des Mikrocontrollers würde dann dazu führen, dass diese Symptome verschwinden. Wenn das manuelle Zurücksetzen des Mikrocontrollers das Problem behebt, versuchen Sie, eine udev-Regel hinzuzufügen, um zu verhindern, dass der Modemmanager den virtuellen seriellen Port des STLink erfasst.
@Devan gute Idee, aber leider ist das nicht der Fall - es werden keine Bytes empfangen, was ich weiß, weil mein Programm die LED für jedes empfangene Byte einschaltet und die LED nicht aufleuchtet, wenn ich das USB-Gerät anschließe.

Antworten (1)

Es sollte keine wirkliche Interaktion zwischen GDB oder OpenOCD und dem virtuellen seriellen Anschluss eines STM32 Discovery- oder Nucleo-Boards geben, jedoch verzögert das modemmanagerstandardmäßig in Ubuntu und abgeleiteten Distributionen installierte Paket die Verfügbarkeit des CDC/ACM-Geräts nach jedem Zurücksetzen erheblich, was normalerweise der Fall ist enthält nicht nur Verbindungen, sondern einige Programmieroperationen (zumindest diejenigen, die die Massenspeicheremulation verwenden).

Die Dinge werden viel besser funktionieren, wenn sie modemmangerdeinstalliert sind. Bitte argumentieren Sie nicht darüber, bis Sie tatsächlich versucht haben, es zu entfernen - das Problem liegt hinter den Kulissen, eine Verzögerung im Betriebssystem, die den Port für Benutzerprogramme verfügbar macht. Es macht den Unterschied zwischen den Boards, die im Wesentlichen nutzlos sind und ziemlich gut funktionieren (eine udev-Regel oder Treiber-Blacklist, um die geringfügig defekte Massenspeicher-Emulation zu ignorieren, ist auch eine gute Idee).

Sie müssen jedoch wahrscheinlich immer noch geeignete Einstellungen für die serielle Leitung vornehmen, mit so etwas wie sttyeinem tatsächlichen Terminalprogramm - ohne das (und möglicherweise sogar danach) können Sie nicht einfach so etwas verwenden, ohne catdie Details der seriellen Schnittstelle zu kennen, mit denen Sie interagieren können den Port (obwohl Sie häufig, wenn Sie ein Terminalprogramm ausführen, echooder catund eine Shell-Umleitung daneben verwenden können, um bestimmte Zeilen dorthin zu schreiben)

Die Deinstallation von Modemmanager schien tatsächlich alles zum Laufen zu bringen. Es wurde bisher nur leicht getestet, aber vielen Dank, dass Sie mich überzeugt haben, dies gründlicher zu versuchen.
Nach weiteren Tests nach der Deinstallation des Modemmanager-Pakets habe ich immer noch zeitweilige Verbindungsprobleme. Normalerweise funktionieren die Dinge nach ein paar Minuten des Probierens und Wiederholens. Aber insgesamt bin ich ziemlich frustriert, dass ich mit Ubuntu immer noch keine zuverlässige Kommunikation zu meinem Gerät über /dev/ttyACM0 bekommen kann.
Ist es möglich, den virtuellen COM-Port von ST-LINK zum Laufen zu bringen, ohne ein Programm in Ubuntu zu starten?
AntwortenHierDatenschutz-Bestimmungen1y, 0v