Hallo Zusammen, über den VCP eines ST-Link 2.1 möchte ich Debugging Strings an die Konsole am Rechner schicken. Das Funktioniert prinzipiell auch, jedoch spielt die Übertragung immer wieder verrückt und in der Konsole werden wild Zeichen angezeigt, die nicht angezeigt werden sollten (Siehe angehängtes Bild). Der Mikrocontroller sendet zu Testzwecken momentan jede Sekunde "HA" raus. Wie gesagt funktioniert das auch allerdings kommt es immer wieder zu falschen Zeichen. Diese werden auch wesentlich schneller als es der 1Sek-Takt ja eigentlich zulassen sollte übermittelt. Weitere Eckdaten: Baud: 115200 Datenbits: 8 Stopbits: 1 Parity: Keine Zum Übertragen der Bytes verwende ich: HAL_UART_Transmit(&huart1, "HA", 2, 1); Das TX Kabel vom µC zum ST-Link ist relativ lang (~30cm) könnte das eventuell zu Übertragunsgfehlern führen? Ich habe allerdings auch schon kleinere Baudraten ausprobiert. Gruß
Angehängte Dateien:
-
UART.PNG
56 KB
Ist es ein Nucleo Board? Wird SWO benutzt? Ist TX mit etwas anderem verdrahtet?
RH schrieb: > in der Konsole werden > wild Zeichen angezeigt, die nicht angezeigt werden sollten Kenn ich. Ich glaube das ist ein Bug im Hterm. Andere Terminalprogramme sind /zumindest bei mir) nicht betroffen.
pegel schrieb: > Ist es ein Nucleo Board? > Wird SWO benutzt? > Ist TX mit etwas anderem verdrahtet? Nein, es ist ein STM32G071G8 auf einer eigenen Platine. Der STM32G071G8 unterstützt SWO nicht. Der ST-Link v2.1 stammt von irgendeinen NUCLEO Board (welches weiß ich nicht mehr, da er abgetrennt ist). Über CN3 sind RX und TX vom Mikrocontroller an den ST-Link angeschlossen. Mittlerweile hat er sich wieder gefangen und er schreibt und ließt korrekt. Der Bug tritt sehr sporadisch auf. Stefan ⛄ F. schrieb: > RH schrieb: >> in der Konsole werden >> wild Zeichen angezeigt, die nicht angezeigt werden sollten > > Kenn ich. Ich glaube das ist ein Bug im Hterm. Andere Terminalprogramme > sind /zumindest bei mir) nicht betroffen. Ber TeraTerm und bei einem weiterem Terminalprogramm hatte ich ähnliche allerdings immer leicht andere "Artefakte". Eventuell liegt das Problem eher auf der Seite von Windows? Entschuldigt bitte das späte Antworten und erneutes Aufgreifen des Themas. Leider war ich die letzten Tage verhindert. Eine andere Frage bezüglich des ST-Links: Über den ST-Link konnte ich meinen Mikrocontroller auch ganz normal ohne den VCOM debuggen und flashen (alles über die STM32CubeIDE). Alle über den ST-Link programmierten Chips lassen sich jetzt aber nicht mehr mit meinem J-Link flashen. Wisst ihr, ob der ST-Link irgendwas in der Richtung sperrt und wie man das rückgangig machen kann? Über ST-Link Utility mit dem ST-Link lässt sich der Controller problemlos flashen. Gruß :)
RH schrieb: > ein STM32G071G8 auf einer eigenen Platine Ich fürchte - nach deinen recht wilden Symptomen zu urteilen - wir müssten mal einen Blick auf deinen Schaltplan und den Aufbau werfen. Für meinen Teil vermute ich kleine bis mittlere Defizite in deiner Schaltung die zu komischen Effekten führen. Als erstes fiel mir ein dass durch den Nucleo-ST-Link eventuell keine adäquate Masseverbindung für die serielle Verbindung existiert. Ist natürlich erst mal Spekulation meinerseits ....
RH schrieb: > Eine andere Frage bezüglich des ST-Links: Über den ST-Link konnte ich > meinen Mikrocontroller auch ganz normal ohne den VCOM debuggen und > flashen (alles über die STM32CubeIDE). Alle über den ST-Link > programmierten Chips lassen sich jetzt aber nicht mehr mit meinem J-Link > flashen. Wisst ihr, ob der ST-Link irgendwas in der Richtung sperrt und > wie man das rückgangig machen kann? Über ST-Link Utility mit dem ST-Link > lässt sich der Controller problemlos flashen. Die Frage hat sich soeben erledigt. Ich habe bei der ST-Link Utility die Möglichkeit entdeckt einen "full chip erase" durchzuführen. Danach lässt sich der Controller auch wieder über J-Link flashen. Anscheinend wird da also irgendetwas gesperrt. Falls jemand mehr darüber weiß, bin ich aber auch über Information dankbar! jo mei schrieb: > RH schrieb: >> ein STM32G071G8 auf einer eigenen Platine > > Ich fürchte - nach deinen recht wilden Symptomen zu urteilen - wir > müssten mal einen Blick auf deinen Schaltplan und den Aufbau > werfen. Für meinen Teil vermute ich kleine bis mittlere Defizite > in deiner Schaltung die zu komischen Effekten führen. Als erstes > fiel mir ein dass durch den Nucleo-ST-Link eventuell keine > adäquate Masseverbindung für die serielle Verbindung existiert. > > Ist natürlich erst mal Spekulation meinerseits .... Die Verbindung ist natürlich alles andere als Optimal und momentan ziemlich provisorisch, da Debugging über VCOM eigentlich erstmal nicht vorgesehen war. RX- und TX gehen momentan wie erwähnt über 30cm Kabel an die ST-Link Platine. Dazu kommt, dass der STM32 ohne externen Oscillator betrieben wird. Alles bestimmt nicht gerade vorteilhaft bei einem asynchronen Übertragunsgeweg...
jo mei schrieb: > Ich fürchte - nach deinen recht wilden Symptomen zu urteilen - wir > müssten mal einen Blick auf deinen Schaltplan und den Aufbau > werfen. Liefer ich sobald möglich :)
RH schrieb: > Dazu kommt, dass der STM32 ohne externen Oscillator > betrieben wird. Ich habe mir jetzt nicht die Stabilität des internen Oszillators im Datenblatt vorgenommen, aber ich sage mal so aus dem hohlen Bauch heraus dass das für eine saubere Kommunikation nicht vernünftig und zuverlässig funktionieren kann (ich würde mir das für meine Schaltungen jedenfalls nie antun wollen). Die Ungenauigkeit und der (Temperatur-) Drift wird immer wieder Probleme bereiten. So sind wir auch wieder bei einem alten leidigen Thema: wenn man nicht das gesamte Umfeld kennt ist es schwer eine vernünftige Ferndiagnose oder Hilfestellung zu geben. In deinem Fall wage ich jetzt die Vorhersage dass deine Fähig- keiten und Tätigkeiten eher auf der Softwareseite liegen und die Hardware bei dir einfach "zu funktionieren hat", Hauptsache die Drähte sind verbunden.
RH schrieb: > Ber TeraTerm und bei einem weiterem Terminalprogramm hatte ich ähnliche > allerdings immer leicht andere "Artefakte". Eventuell liegt das Problem > eher auf der Seite von Windows? Eher nicht. setze mal deine UART Einstellung auf 2 Stopbits. Danach sollte es 100% ordentlich funktionieren. Ich habe es bei einigen USB/Serial Adaptern schon gehabt, daß man da gelegentlich die Synchronisation verliert, wenn nur mit nur einem Stopbit gesendet wird. RH schrieb: > Danach lässt > sich der Controller auch wieder über J-Link flashen. Die Software von Segger bietet Entsperren und Bulkerase an, damit funktioniert das alles auch ohne einen STLink. W.S.
W.S. schrieb: > Die Software von Segger bietet Entsperren und Bulkerase an Wie heißt denn diese Software? Funktioniert die auch mit dem EDU? Irgendwie bin ich noch nicht fündig geworden, ob es auch für das EDU ein ähnliches Werkzeug wie das ST-Link-Utility gibt.
W.S. schrieb: > Eher nicht. setze mal deine UART Einstellung auf 2 Stopbits. Danach > sollte es 100% ordentlich funktionieren. Ich habe es bei einigen > USB/Serial Adaptern schon gehabt, daß man da gelegentlich die > Synchronisation verliert, wenn nur mit nur einem Stopbit gesendet wird. Werde ich machen. Momentan funktioniert die Kommunikation wieder einwandfrei. W.S. schrieb: > Die Software von Segger bietet Entsperren und Bulkerase an, damit > funktioniert das alles auch ohne einen STLink. Der Name der Software würde mich auch interessieren. J-Flash Lite bietet diese Funktion nicht. jo mei schrieb: > In deinem Fall wage ich jetzt die Vorhersage dass deine Fähig- > keiten und Tätigkeiten eher auf der Softwareseite liegen und > die Hardware bei dir einfach "zu funktionieren hat", Hauptsache > die Drähte sind verbunden. Wie bereits erwähnt ist das ganze recht provisorisch. Mit deiner Vermutung hast du recht. Ich bin kein Elektroingenieur und daher bedarf es in einigen Hardware-Angelegenheiten Nachhilfe.
RH schrieb: > Die Frage hat sich soeben erledigt. Ich habe bei der ST-Link Utility die > Möglichkeit entdeckt einen "full chip erase" durchzuführen. Danach lässt > sich der Controller auch wieder über J-Link flashen. Anscheinend wird da > also irgendetwas gesperrt. Falls jemand mehr darüber weiß, bin ich aber > auch über Information dankbar! Hast Du evtl. das Debuginterface nicht aktiviert? Bei der Codeerstellung mit MX ist dieses standardmäßi nicht aktiv. Das führt dazu das man nur einmal programmieren kann und danach nicht mehr.
RH schrieb: > Eventuell liegt das Problem eher auf der Seite von Windows? Das passiert auch unter Linux. Theoretisch können sich UART Empfänger nach Übertragungsstörungen besser fangen, wenn man 2 Stopp-Bits sendet. Vielleicht hilft das, habe ich am ST-Link noch nicht probiert.
RH schrieb: > Alle über den ST-Link > programmierten Chips lassen sich jetzt aber nicht mehr mit meinem J-Link > flashen. Wisst ihr, ob der ST-Link irgendwas in der Richtung sperrt und > wie man das rückgangig machen kann? Der ST-Link selbst nicht, aber dein Programm vielleicht. Standardmäßig (seitens der Hardware) sind bei allen STM32 Chip sowohl SWD als auch JTAG aktiviert. Der Code, den Cube MX generiert, deaktiviert aber beides standardmäßig. Wenn du in Cube MX einstellst, dass du SWD verwenden willst, deaktiviert er nur JTAG. Dazu gibt es relevante Optionen zum Verbindungsaufbau zwischen dem Adapter und dem µC. Die Optionen werden je nach Programm unterschiedlich genannt: Hardware Reset: Die Verbindung wird unmittelbar nach dem Reset Impuls aufgebaut. Hier ist es wichtig, dass dein Programm die SWD/JTAG Schnittstelle nicht sofort beim Start deaktiviert. Ein delay(1000) am Anfang kann hilfreich sein. Connect on Reset: Die Verbindung wird während des Reset aufgebaut. Da das Programm dann noch nicht läuft, sind SWD und JTAG zu diesem Zeitpunkt immer aktiv. Wenn du einen dicken Kondensator am Reset Pin hast, kann dieser störend wirken. Ich meine mich zu erinnern, dass irgendwo maximal 100nF empfohlen wurden. Andererseits brauche ich aber oft deutlich größere Kondensatoren, weil das Netzteil in den ersten hundert ms noch instabil arbeitet. Software Reset: Dazu darf die SWD/JTAG Schnittstelle nicht deaktiviert sein. Der Adapter sendet ein Soft-Reset Signal über diese Schnittstelle. Ohne Reset: Auch hier darf die Schnittstelle nicht deaktiviert sein. Wo genau der Unterschied zu "Software Reset" ist, habe ich nicht herausfinden können. Es gibt noch eine andere Möglichkeit, zu verhindern dass dein Programm startet und die Schnittstelle deaktiviert: Den Boot0 Pin auf High setzen, um den internen Bootloader zu aktivieren. Denn der lässt auch SWD/JTAG aktiv. Das alles erklärt dein Problem nicht, aber es hilft dir hoffentlich, der eigentlichen Ursache auf die Schliche zu kommen.
jo mei schrieb: > Ich habe mir jetzt nicht die Stabilität des internen Oszillators > im Datenblatt vorgenommen, aber ich sage mal so aus dem hohlen > Bauch heraus dass das für eine saubere Kommunikation nicht > vernünftig und zuverlässig funktionieren kann (ich würde mir das > für meine Schaltungen jedenfalls nie antun wollen). Die > Ungenauigkeit und der (Temperatur-) Drift wird immer wieder > Probleme bereiten. Zumindest für STM32L0, F1 und F3 kann ich dies bestätigen. Es ist ein Glücksspiel. Es klappt aber erheblich besser als bei den alten AVR Controllern. Wenn bei mir Hterm (trotz Quarz) plötzlich nur noch Müll ausgibt, starte ich Hterm neu und es geht meistens sofort wieder.
Stefan ⛄ F. schrieb: > Wenn bei mir Hterm (trotz Quarz) plötzlich nur noch Müll ausgibt, starte > ich Hterm neu und es geht meistens sofort wieder. Wenn bei mir Hterm (trotz Quarz und sonstigen stabilen Parametern) plötzlich nur noch Müll ausgeben würde wäre das für mich das ein Grund das Programm wegzuwerfen oder zumindest nie mehr zu benutzen. Es gibt genügend andere (und bessere) Programme.
jo mei schrieb: > wäre das für mich das ein Grund das Programm > wegzuwerfen oder zumindest nie mehr zu benutzen. Leider hat Hterm einige nützliche Merkmale, die kein anderes Terminalprogramm hat. Aber ja: Meistens benutze auch ich ein anderes (cutecom oder einfach nur cat).
RH schrieb: > Momentan funktioniert die Kommunikation wieder einwandfrei. Dann kann ja dein Thread geschlossen werden und wir brauchen dir nicht weiter helfen, und alle können frohen Mutes nach Hause gehen. Nicht wahr?
>HAL_UART_Transmit(&huart1, "HA", 2, 1);
mach mal dein timeout auf 2
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.