Moin Moin, ich möchte mich mal mit dem SWO von STM32 auseinandersetzen. Wenn ich es richtig verstanden habe sollte es möglich sein mit SWO eine komfortabel Debug Schnittstelle zu nutzen. SWO ist sehr Ressourcen sparend stimmt das? Ich habe aber noch nicht zu hundert 100%die Möglichkeiten die SWO bietet verstanden. Printf ausgaben sollten möglich sein und auch Trace ausgaben von Variablen ist das so richtig? Ist es vernünftig SWO mit Atollic zu nutzen? Wo bekomme ich eine gute Anleitung wie man es richtig macht? Danke für eure Hilfe Schönen Sonntag
>SWO von STM32 ... Wenn ich es richtig verstanden habe sollte es möglich sein > mit SWO eine komfortabel Debug Schnittstelle zu nutzen Ja, ich benutze auch SWD als als physischen Zugangskanal des Debuggers zu meinen STM32. Als Debug Probe verwende ich J-Link Edu bzw. ein STM32-Nucleo Board kann man auch als low cost SWD Debug Probe umkonfigurieren. >SWO ist sehr Ressourcen sparend stimmt das? Alles in Hardware. >Printf ausgaben sollten möglich sein Möchte man eigenen Trace Output am PC sehen, einfach angehängte Datei mitkompiliern. Das normale printf() ruft irgendwann intern _write() zur Ausgabe aus. __io_putchar() transportiert das ganze dann über SWD zum PC. Im TrueSTUDIO kannst du dann das Ergebniss in der SWV Console anschauen. (Nach dem Debug Start den roten Punk (Start Trace) in dem SWV Console View aktivieren). Willst du nicht den ganzen printf Overhead haben, dann beim Aufsetzten des Projekts die Datei tiny_printf.c mitgenerrieren lassen. Aber meistens reichen die normalen Debug Möglichkeiten aus, alles so wie man es vom Debugen eines PC Programms gewohnt ist.
Angehängte Dateien:
-
debug.PNG
110 KB
Danke für deine Hilfe! Ich habe jetzt mit dem Tool "STM32 ST-LINK Utility" geschaft die printf Ausgaben aus zu geben. Mit dem Atollic true Studio will es noch nicht klappen. Wenn ich auf den roten Punkt klicke passiert nichts und wenn ich mit dem grünen Play Button starte wird der rotr Punkt im SWO Consolen Fenster ausgegraut und mehr passiert nicht. Hast noch einen Tipp
In den SWV Settings (neben dem Roten Punkt) Punkt "ITM Stimulus Ports" den Port 0 freigeschaltet?
KM schrieb: > In den SWV Settings (neben dem Roten Punkt) Punkt "ITM Stimulus Ports" > den Port 0 freigeschaltet? Hatte ich nicht aber auch das hilft nicht.
Irgenwie ist in debug.PNG im SWV Console View das Tab "Port 0" nicht zu sehen. -> Günes Kreuz "Add Port" im SWV Console View und dann Port 0 eingeben.
Jetzt hat es geklappt. Sehr Komfortabel so zu debuggen. Macht so wirklich viel Spaß! Alles aus dem Atollicstudio raus. Wird das Swo auch ausgeführt wenn kein Adapter an der Hardware hängt?
> Wird das Swo auch ausgeführt wenn kein Adapter an der Hardware hängt?
Nein. Der SWO Ausgang wird vom Debugger aktiviert.
Stefan ⛄ F. schrieb: > Nein. Der SWO Ausgang wird vom Debugger aktiviert. Das heißt das das printf im Normal Betrieb keine Belastung für den Stm32 ist? Danke für die Hilfe
Bildschirmreiniger schrieb: > Das heißt das das printf im Normal Betrieb keine Belastung für den Stm32 > ist? Das kommt darauf an, wie die _write() Methode implementiert wurde. Sie kann vor der Ausgabe abfragen, ob der SWO Ausgang aktiviert wurde. Und dann kann sie entscheiden, ob sie warten oder überspringen will. Wenn man printf mit Platzhaltern benutzt, muss er diese aber auf jeden Fall abarbeiten, auch wenn die Ausgabe danach gar nicht stattfindet. Mit
1 | ITM_SendChar(c); |
kannst du einzelne Zeichen effizienter ausgeben. Wenn die Schnittstelle deaktiviert ist, überspringt sie das Ausgeben. Innerhalb dieser CMSIS Funktion kannst du sehen, wie man den Status des Ports abfragt:
1 | if (((ITM->TCR & ITM_TCR_ITMENA_Msk) != 0UL) && /* ITM enabled */ |
2 | ((ITM->TER & 1UL ) != 0UL)) /* ITM Port #0 enabled */ |
3 | {
|
4 | ...
|
5 | }
|
Wenn du teure Operationen zum generieren/formatieren des Strings hast, kannst du das vorher abfragen, bevor du Zeit vergeudest - falls das für deine Anwendung hilfreich ist.
Stefan ⛄ F. schrieb: > if (((ITM->TCR & ITM_TCR_ITMENA_Msk) != 0UL) && /* ITM enabled */ > ((ITM->TER & 1UL ) != 0UL)) /* ITM Port #0 enabled > */ > { > ... > } Sieht gut aus. Ben S. schrieb: > Warum eigentlich noch das Atollic True Studio? Gibt es was besseres? Habe mit Atollic begonnen und bin dabei geblieben.
KM schrieb: > Als Debug Probe verwende ich J-Link Edu Was spricht dann gegen https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/ ? Das belastet den Mikrocontroller zur Laufzeit noch einmal um Längen weniger als SWO. Und man braucht auch keinen Hardwarepin extra verkabeln.
Lutz schrieb: > Das belastet den Mikrocontroller zur Laufzeit noch einmal um Längen > weniger als SWO. Und man braucht auch keinen Hardwarepin extra > verkabeln. Wie kommst du darauf, dass das den Controller weniger belastet? Die ITM ist sozusagen ein zweiter Kern neben dem eigentlichen Kern und nimmt diesem damit die Arbeit ab. Wie soll das effizienter gehen, in dem man es mit irgendeiner Library dann doch durch den eigentlichen Prozessor laufen lässt? Der große Vorteil von RTT ist wohl eher, dass das auch mit anderen Architekturen als Cortex-M funktioniert.
Ben S. schrieb: > Warum eigentlich noch das Atollic True Studio? #OT Weil in der STM32IDE z.B. (zumindest bei mir) die SFR (SpecialFunctionRegister) View nicht gegangen ist (Windows, neueste STM32IDE). Ich hab stundenlang (mit Hilfe vonn Google versucht das zum laufen zu bringen und bin dann wieder zu Atollic zurück. rgds #/OT
Mal so eine Frage am Rande, warum braucht man heute eigentlich noch einen Debugger um quasi in den uC zu schauen? Ich als Laie denke, das meiste sollte doch schon als Simulation lösbar sein. Gut, vllt bei sehr engen Timings deren Spezifikation problematisch ist, ok. Aber für analoge Geschichten gibt es Spice etc. warum nicht für digitales? Habt einen gesunden Tag!
Blöder Mann ;-) schrieb: #OT > als Simulation lösbar Welchen Simulator für einen STM32F4 kennst Du der eine Zielfrequenz von 180MHz und die dazugehörigen Peripherien mir dieser Taktrate simulieren kann? #/OT rgds
6a66 schrieb: > Weil in der STM32IDE z.B. (zumindest bei mir) die SFR > (SpecialFunctionRegister) View nicht gegangen ist Du meinst die System Workbench for STM32, nehme ich an. Das funktioniert bei mir allerdings. Du musst nur diese View allerdings öffnen, bevor du den Debugger startest, sonst zeigt sie nur die Default Werte an, aber nicht die aktuellen. Doch auch diese IDE ist in die Jahre gekommen. Aktuell ist die STM32 Cube IDE. Auch dort funktioniert diese View bei mir.
Stefan ⛄ F. schrieb: > Aktuell ist die STM32 > Cube IDE. #OT Die meinte ich eigentlich. Bin gerne bereit bei einem Projektschritt das nochmal zu versuchen. #/OT Und das mit SWO werde ich auch bei Gelegenheit angehen. Komme mit dem Debugger bisher ganz gut zurecht. rgds
Blöder Mann ;-) schrieb: > Ich als Laie denke, das meiste sollte doch schon als Simulation lösbar > sein. Zum einen haben die µC zunehmend viele komplexe Funktionen, die zu simulieren immer komplexer wird. Diese Mühe macht sich kaum noch ein Entwickler. Zum Anderen kann so ein Simulator nicht jede beliebig Hardware simulieren, die an den µC angeschlossen ist. Doch von der hängt das Verhalten des Programmes ab, dass man simulieren will. Wie willst du z.B. eine BLDC Motor-Steuerung simulieren, ohne den Motor und die ganze Mechanik drumherum ebenfalls zu simulieren? Das geht nicht!
Stefan ⛄ F. schrieb: > Du musst nur diese View allerdings öffnen, bevor du > den Debugger startest, sonst zeigt sie nur die Default Werte an, aber > nicht die aktuellen. #OT Nee, die hat nur einen Error angezeigt dass das nicht geladen werden kann (wenn ich mich recht erinnere irgend einen Eclipe oder Java Error, das war auch bei anderen Views der Fall). Nachdem ich gerade beim Projektwechsel war hatte ich ein paar Stunden darein investiert und bin dann wieder zurück anstatt tagelang an dem Punkt rumzueiern. Aber was soll's, TrueStudio läuft prima. #/OT rgds
Ich kombiniere SWO gerne mit mehreren Funktionen: a) Einer Poer-On LED. Das Programm schaltet die LED nach Initialisierung der Taktversorgung ein. So erkenne ich, dass der µC "lebt". b) Im Fall von erkannten Störungen, gibt die LED durch Blinkmuster einen Fehlercode aus (habe ich von meinem Motorrad abgeguckt). c) Mit dem Debugger kann ich SWO aktivieren und dann detaillierte Meldungen auslesen. Bei der Dreifachen Nutzung dieses Pins kann man nicht über "belegt einen Pin zusätzlich" meckern. Mit fällt noch eine vierte Nutzungsmöglichkeit ein: d) Wenn man eine weiße oder blaue LED verwendet, kann man parallel dazu einen Jumper platzieren, der von der Firmware abgefragt wird und irgend eine Sonderfunktion auslöst - zum Beispiel Reset der Konfigurationsdaten.
Stefan ⛄ F. schrieb: >> Ich als Laie denke, das meiste sollte doch schon als Simulation lösbar >> sein. Das Thema 100MHz, wer sagt denn, daß eine Simulation in Echtzeit laufen muss? > > Zum einen haben die µC zunehmend viele komplexe Funktionen, die zu > simulieren immer komplexer wird. Diese Mühe macht sich kaum noch ein > Entwickler. Naja, bei Spice gibt es eine Umgebung und dort werden die Parameter (Bauteildefinitionen) hinterlegt. Dazu gibt es Eingangssignale, die zu definieren sind. Folglich sollte man die Ausgangssignal simulieren können. Natürlich ist das Mühe für den Chipentwickler, aber das war es bei Spice auch.... > > Zum Anderen kann so ein Simulator nicht jede beliebig Hardware > simulieren, die an den µC angeschlossen ist. Doch von der hängt das > Verhalten des Programmes ab, dass man simulieren will. Wie willst du > z.B. eine BLDC Motor-Steuerung simulieren, ohne den Motor und die ganze > Mechanik drumherum ebenfalls zu simulieren? Das geht nicht! Ich denke, das sollte zumindest bis zur Schnittstelle zur Leistungsabteilung doch möglich sein. Da kommt dann digitales heraus...
Blöder Mann ;-) schrieb: > das sollte ... doch möglich sein Möglich ist alles. Wirtschaftlich aber nicht. Dennoch gibt es ab und zu Leite, die aus Spaß an der Sache auch unwirtschaftliche Dinge realisieren. Du kannst in diesem Fall ja mal damit anfangen. Hopp Hopp!
Stefan ⛄ F. schrieb: > Bei der Dreifachen Nutzung dieses Pins kann man nicht über "belegt einen > Pin zusätzlich" meckern. Danke für die guten Tipps. Hab' den SWO noch nicht im Programm. Aber das sind sehr gute Ideen. Und den Pin habe ich ohnehin noch freigelassen. rgds
Blöder Mann ;-) schrieb: > Aber sorry! Ich will den Thread hier nicht sprengen! #OT Wir hatten früher (vor >20J) bei der Entwicklung einer HW-Platform mit einem ASIC im Nebenraum eine Simulatomaschine für das ASIC (CPU) stehen. Das war ein Schrank mit der Zielhardware und viel Zusatz-HW für das ASIC. Schweinsteuer >>100kDM und hat eine extra Klimaanlage benötigt. War von der Komplexität eher ein STM32F103 ohne Peripherie der simuliert werden sollte. Also NO WAY für Realtime heute. #/OT Der Weg mit den Debuggern ist doch nicht schlecht, warum da was Neues erfinden? rgds
Angehängte Dateien:
-
reset_CrumbX1-NET.png
440 KB
6a66 schrieb: > Und den Pin habe ich ohnehin noch freigelassen. Mache da einfach immer eine bedrahtete weiße LED (mit Vorwiderstand) dran. Dann hast du alle anderen Optionen für die Zukunft offen. Zum Reset könnte man in die Bedienungsanleitung schreiben: Verbinden sie die beiden Drähte der Power-LED und schalten dann das Gerät ein.* Den SWO Viewer kann man mit einer Haken-Klemme an das Bein hängen. *) Etwas ähnliches habe ich schon einmal bei einem Modul gemacht, dass als Kleinserie (einige hundert Stück) produziert wurde. Da musste man zwei Pins von nebeneinander liegenden Widerständen brücken, um das Passwort zu löschen. Das hat bisher jeder Anwender verstanden. Ich hatte dazu bewusst eine Stelle ausgewählt, wo nichts schlimmes passiert, wenn man abrutscht. Darunter siehst du den Connector für den Debugger.
Blöder Mann ;-) schrieb: > Mal so eine Frage am Rande, warum braucht man heute eigentlich noch > einen Debugger um quasi in den uC zu schauen? Wer einen Debugger braucht, kann eh nicht programmieren. Das richtige Tool ist die UART mit endloser Textausgabe, dass wissen wir doch inzwischen alle ????
Ben S. schrieb: > Wer einen Debugger braucht, kann eh nicht programmieren. Das richtige > Tool ist die UART mit endloser Textausgabe, dass wissen wir doch > inzwischen alle ???? By the way: Man kann die SWO Leitung so konfigurieren, dass ihre Ausgabe im UART Format stattfindet. Denn Sinn der Sache habe ich aber noch nicht verstanden, denn man braucht ohnehin einen Debugger, um den Ausgang zu aktivieren. Was mir da auch noch unklar ist: Der Trace-SWO Ausgang hat ein paar Bytes Puffer (z.B. 10) aber zwischen den Buchstaben überträgt er Null-Bytes. Sind die auch im Puffer, so dass sie dort wertvollen Platz verschwenden?
Stefan ⛄ F. schrieb: > Mache da einfach immer eine bedrahtete weiße LED (mit Vorwiderstand) > dran. Dann hast du alle anderen Optionen für die Zukunft offen. > > Zum Reset könnte man in die Bedienungsanleitung schreiben: Verbinden sie > die beiden Drähte der Power-LED und schalten dann das Gerät ein.* Yep, so ähnlich hatte ich das vor - nur nicht bedrahtet und nur für die Entwicklungsphase :) Das mit dem Rest Jumper stecken für den Benutzer ist dann nicht so einfach. Das Gerät wird wasserdicht verschlossen und versiegelt. Da kommst Du dann nicht mehr ran. Das geht bei mir inwischen über einen Tastendruck bei PowerUp, da startet das System ohne die EERPOM Daten zu laden. Ben S. schrieb: > dass wissen wir doch > inzwischen alle ???? JOU :) Deswegen auch die Diskussionen wie: "Mein Programm geht nicht. Habe 10 Seiten Code gepostet. Wer hilft mir ???" rgds
Christopher J. schrieb: > Lutz schrieb: >> Das belastet den Mikrocontroller zur Laufzeit noch einmal um Längen >> weniger als SWO. Und man braucht auch keinen Hardwarepin extra >> verkabeln. > > Wie kommst du darauf, dass das den Controller weniger belastet? > Die ITM ist sozusagen ein zweiter Kern neben dem eigentlichen Kern und > nimmt diesem damit die Arbeit ab. Wie soll das effizienter gehen, in dem > man es mit irgendeiner Library dann doch durch den eigentlichen > Prozessor laufen lässt? > > Der große Vorteil von RTT ist wohl eher, dass das auch mit anderen > Architekturen als Cortex-M funktioniert. Hast Recht. SWO hat gar keinen Einfluß auf den Controller. RTT war/ist wesentlich schneller. Und deutlich einfacher zu nutzen bzw. zu konfigurieren. Und kann Daten in beide Richtungen transportieren! Und hat auch ohne angeschlossenen Debugger den gleichen Einfluß bzw. der selbe Code läuft auch ohne angeschlossenen Debugger.
Lutz schrieb: > SWO hat gar keinen Einfluß auf den Controller. > RTT ist wesentlich schneller. Also noch schneller als gar keinen Einfluss. Dann nehme ich drei davon, ist besser als Übertakten.
Welchen Zusammenhang siehst du jetzt zwischen schnell sein und Einfluß auf etwas haben???
KM schrieb: > Ja, ich benutze auch SWD als als physischen Zugangskanal des Debuggers > zu meinen STM32. Als Debug Probe verwende ich J-Link Edu bzw. ein > STM32-Nucleo Board kann man auch als low cost SWD Debug Probe > umkonfigurieren. Hallo wollte die im Beitrag Beitrag "Re: SWO Atollic True Studio STM32Gute" angehängte Datei PrintF_SWO_Bridge.h in meinem Projekt einbinden. Ist dafür eine .h geeignet?
piazza_walter schrieb: > Hallo wollte die im Beitrag > Beitrag "Re: SWO Atollic True Studio STM32Gute" angehängte Datei > PrintF_SWO_Bridge.h in meinem Projekt einbinden. > > Ist dafür eine .h geeignet? ICH verwende dazu syscall.c
Hansjörg schrieb: > ICH verwende dazu syscall.c Gibt es dazu eine Regel, was in syscall hinein gehört?
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.