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ß
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?
UART.PNG
(56 KB)
