Hey Leute, bin auf der Suche nach einem etwas profesionelleren Debugger inkl. Debug-Software für STM32. Wichtig wären mir vor allen Dingen eine "live-view" von Hardware-Registern sowie ein Echtzeit-Monitoring vom RAM (sowie mögliche direkt Manipulation von der SW aus). Mir ist klar, dass ein Lauterbach sowas kann, aber möchte zeitgleich möglichst "günstig" bleiben. Was nehmt Ihr?
Segger J-Link mit OZone wenn es nur um das Debuggen geht.
Dafür haben wir "kleine" Lauterbach Debugger. Die Kosten "nur" gute 3k5 Euro. Darunter wirst du bei Lauterbach wahrscheinlich nicht fündig.
Lauterbach mit Trace > Mir ist klar, dass ein Lauterbach sowas kann, aber möchte zeitgleich > möglichst "günstig" bleiben. Witzbold
:
Bearbeitet durch User
> Was nehmt Ihr?
Einen Segger mit selbstgeschriebener Software fuer das monitoring.
Olaf
es gibt auch ein OS Projekt 'Orbuculum', das nutzt den SWO und einige Tools um in die MCU zu schauen. Habe ich selber bisher nicht benutzt, steht bei mir auch auf der Todo Liste. https://github.com/orbcode/orbuculum
>eine "live-view" von Hardware-Registern sowie >ein Echtzeit-Monitoring vom RAM wie kann man einem Prozessor mit einem Takt > 1Mhz beim Lesen und Schreiben auf Speicher oder Register zugucken ? Ich kann da mit meinen Augen / Hirn nicht mithalten. Die "Pause" Taste in der CPU (aka "Breakpoint") kann doch jeder ST-Link. Aber ja, ein teurer Debugger findet Fehler schneller als ein billiger.
Debugger schrieb: > bin auf der Suche nach einem etwas profesionelleren Debugger inkl. > Debug-Software für STM32. Professsioneller als? > Wichtig wären mir vor allen Dingen eine "live-view" von > Hardware-Registern Die IAR IDE (EWARM) bietet so etwas; dort heißt es live-watch. Die Demoversion bis 32 kB ist kostenlos. Selbst mit der Codebeschränkung kann man neue Routinen separat recht gut testen und die Funktion der Peripherie verstehen. Ob sich eine Anschaffung lohnt, ist reichlich abzuwägen. Keil hat Ähnliches. drm schrieb: > Ich kann da mit meinen Augen / Hirn nicht mithalten. Das glaube ich Dir sofort. > Die "Pause" Taste in der CPU (aka "Breakpoint") kann doch jeder ST-Link. Welch ein Depp muß man sein, um z.B. bei einer (Schritt-)Motorsteuerung die laufende Bewegung mit einen Breakpoint zu stoppen oder gegen den Anschlag zu drücken?
https://www.segger.com/products/debug-probes/j-link/models/j-link-plus/ https://www.segger.com/products/debug-probes/j-link/models/j-link-edu-mini/ https://www.segger.com/purchase/pricing/jlink-related/ https://www.segger.com/products/development-tools/ozone-j-link-debugger/ https://www.segger.com/products/debug-probes/j-link/tools/j-scope/ https://www.segger.com/products/development-tools/embedded-studio/
> wie kann man einem Prozessor mit einem Takt > 1Mhz > beim Lesen und Schreiben auf Speicher oder Register zugucken ? Du kannst dir die Sachen ja auch als Datenfile rausschreiben, oder als Diagramm ankucken. > Die "Pause" Taste in der CPU (aka "Breakpoint") kann doch jeder ST-Link. Sobald du irgendwas regelst, z.B Temperatur oder einen Motor ist das etwas doof. Auch wenn du gleichzeitig eine Uebertragung mit Bluetooth oder WLAN laufen hast kannst du ja nicht einfach zwischendurch anhalten weil dann die Verbindung weg ist. Breakpoint ist schon manchmal nett, aber oft nicht genug. Perfekt ist das im uebrigen auch noch nicht. Sobald man die Debugmacrozelle in der CPU laufen hat zieht die deutlich mehr Strom. Das kann bei Lowpoweranwendung etwas nervig sein. Olaf
>Welch ein Depp muß man sein, um z.B. bei einer (Schritt-)Motorsteuerung oder ein STM32 mit RTOS über Speicher und Register zu debuggen, besonders wenn man ausgiebig Tasks benutzt Debug Ausgaben über SWO oder Usart-TX, Teststimuli über USART-RX sind die richtige Antwort wie man debuggt, nicht der nächste teure Debugger. ST ist bolle stolz drauf das die kostenlose CubeIDE (wie Keil/IAR) alles mit ST-Link oder J-Link auf die Kette kriegt. Einfach mal im YT Kanal von ST stöbern ... Im Zweifel hilft ein LogicAnalyzer oder Oszi mehr beim Debuggen als ein weiterer Debugger.
drm schrieb: > Debug Ausgaben über SWO oder Usart-TX, Teststimuli über USART-RX sind > die richtige Antwort wie man debuggt, Solange man auf dem Niveau delay_ms(1000) programmiert. Wenn der DMA-Controller mal hängenbleibt, möchte ich schon gezielter nachsehen können.
>Wenn der DMA-Controller mal hängenbleibt möchte ich schon gezielter nachsehen
können.
geht nicht, bei einer Fehlfunktion wird der WDG aktiv und macht einen
Reset
PS: das Komma habe ich behalten
drm schrieb: > ST ist bolle stolz drauf das die kostenlose CubeIDE (wie Keil/IAR) alles > mit ST-Link oder J-Link auf die Kette kriegt. Einfach mal im YT Kanal > von ST stöbern ... STM32CubeIDE ist, wie so viele andere Eclipse-basierten IDEs, der letzte Rotz in Sachen Debugging. Am schlimmsten finde ich dabei, dass der Debugger es nicht schafft, mehrere Symbole mit demselben Wert (z.B. 0x00000000) sauber auseinanderzuhalten. Und selbst solche vermeintlich einfachen Dinge wie das Darstellen der Elemente einer Struktur ab einer beliebigen Basisadresse sind unmöglich oder extrem umständlich. Deswegen verwende ich von der CubeIDE nur den GCC und die Binutils. Als Editor den UE Studio, als Build-System ein durch STM32CubeMX generiertes und anschließend händisch deutlich aufgebohrtes Makefile, und als Debugger einen Lauterbach TRACE32.
> STM32CubeIDE ist, wie so viele andere Eclipse-basierten IDEs, der letzte > Rotz in Sachen Debugging. Das liegt in der Natur der Sache. Wenn man sich einmal anschaut was der gdb im Textmode fuer unglaubliche Einstellmoeglichkeiten, Parameter und Kommandos ermoeglicht dann ist klar das man bei den grossen Problemen des Lebens im Terminalfenster arbeiten muss. Das kann man einfach nicht Klickibunti machen. Allerdings fuer die einfachen Dinge ist natuerlich "einmal klicken = breakpoint" schon von einer schlichten Eleganz. Allerdings liegt die Betonung dann auch auf "schlicht". .-) Olaf
Während der Core läuft kann man doch nicht parallel Register etc. auslesen? Wenn Segger ein solches Feature anbietet, wenden die da bestimmt Tricks an, d.h. die Laufzeit deines Programms wird in jedem Fall beeinflusst.
wut schrieb: > Während der Core läuft kann man doch nicht parallel Register etc. > auslesen? Der ST-Link V2 kann unter EmBitz zur Laufzeit zwar nicht Register, aber immerhin Variablen (und damit auch Peripherie-Register) life sichtbar machen, ohne den Kern anzuhalten. Grenzen hat das leider bei den Float-Registern. wut schrieb: > Wenn Segger ein solches Feature anbietet, wenden die da bestimmt Tricks > an, d.h. die Laufzeit deines Programms wird in jedem Fall beeinflusst. Natürlich wird die Laufzeit beeinflusst. Schon allein deshalb, weil alles über den Bus geschaufelt werden muss.
> Wenn Segger ein solches Feature anbietet, wenden die da bestimmt Tricks
Es ist nicht Segger die da irgendwas erfunden haben, die nutzen es nur
und stellen Anwendern eine einfachere Schnittstelle bereit. Die CPUs
haben integrierte Hardware welche die Zugriffe erlaubt.
Daher auch mein Einwand bezueglich LowPower. Sobald man einmal das
Debuginterface nutzt wird das vom JLink eingeschaltet und bleibt dann
an. Das erhoeht dann der Stromverbrauch so um 1mA.
Olaf
Olaf schrieb: > Das kann man einfach nicht Klickibunti machen. Doch, Lauterbach bietet den allergrößten Teil der Funktionalität auch per Klickibunti an, aber es lässt sich natürlich alles auch in PRACTICE-Skripte packen. Diese Sprache hat zwar nicht die Eleganz mancher modernen Skriptsprache, ist aber für den Zweck sehr gut geeignet.
Beitrag #6785459 wurde von einem Moderator gelöscht.
wut schrieb: > Wenn Segger ein solches Feature anbietet, wenden die da bestimmt Tricks > an, d.h. die Laufzeit deines Programms wird in jedem Fall beeinflusst. Je nach Ausstattung des Chips verfügt die Debugunit über einen Mem-Access-Port. Typischerweise hängt der einfach als weiterer Master an der Busmatrix und kann auf jeden Speicher wann er will zugreifen. Dann sieht man alles was im Speicher abgeht in (fast) Echtzeit. Man kann dann auch Variablen ändern und schauen was die Software daraufhin macht. Für Register existiert sowas glaube ich nicht, macht imho auch nicht viel Sinn. (Da brauchts dann eher ETM bzw. ITM Debugeinheit und eine passende Software dazu)
Cyblord -. schrieb: > Witzbold Nö - nur einer, der das Geld seines Chefs möglichst gut ausgeben will, ohne sich selbst (bzw. sein Gehirn) anzustrengen. Wenn man mit seinem Zeugs nicht mehr weiterkommt, muß man dem Cheffe eben klarmachen, daß man eine größere Debug-Kanone braucht - aber man darf das Ganze nicht gar zu sehr übertreiben. Also sei nachsichtig. W.S.
Andreas M. schrieb: > wut schrieb: >> Wenn Segger ein solches Feature anbietet, wenden die da bestimmt Tricks >> an, d.h. die Laufzeit deines Programms wird in jedem Fall beeinflusst. > > Für Register existiert sowas glaube ich nicht, macht imho auch nicht > viel Sinn. (Da brauchts dann eher ETM bzw. ITM Debugeinheit und eine > passende Software dazu) Also meines erachtens sollte sich das Debug-Interface auch einfach wie ein weiterer Bus-Master verhalten. Ich habe beruflich früher mal mit den TriCores gearbeitet und da ging das auch, dass man auf alle Peripherie-Register zugreifen konnte. War sehr praktisch. Man konnte da so Hardwaremodule wie SPI oder so einfach mal Register für Register testweise durchkonfigurieren per Maus und schauen was so passiert (ohne auch nur eine Zeile Code geschrieben zu haben).
egal schrieb: > Also meines erachtens sollte sich das Debug-Interface auch einfach wie > ein weiterer Bus-Master verhalten. Zum Cortex-M4 schreibt ST
1 | • The AHB-AP is an AHB master into the Bus Matrix. |
2 | Consequently, it can access all the data buses (Dcode Bus, |
3 | System Bus, internal and external PPB bus) but the ICode bus. |
4 | • Bitband transactions are supported. |
nachdem auch der Private Peripheral Bus (PPB) dabei ist, kommt man praktisch an alles ran, mit Ausnahme der Core Register. Bei einem Fault werden die aber gerettet, also bleibt nicht viel. Sind R0 bis R12 in einem optimierten Programm überhaupt interessant? Coprocessor Register sind leider noch ganz was anderes. > Ich habe beruflich früher mal mit den TriCores gearbeitet und da ging > das auch, dass man auf alle Peripherie-Register zugreifen konnte. Eben alles, was memory-mapped ist.
Bauform B. schrieb: > Eben alles, was memory-mapped ist. und ein bisschen mehr, die CoreSight Doku ist was für lange Winterabende. https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace/coresight-components CPU Register konnte afaik schon das ältere ST-Utility anzeigen.
Bauform B. schrieb: > Bei einem Fault > werden die aber gerettet Wenn man sich einen Faulthandler schreibt, der das macht, dann sicherlich. Ansonsten werden bei einem Fault die gleichen Register vom NVIC stacked, wie bei nem IRQ.
Bauform B. schrieb: > Sind R0 bis R12 in > einem optimierten Programm überhaupt interessant? Klar, wenn man den Sourcecode und ein Assemblerlisting hat. IMO ist der Assemblercode optimierter Programme sogar besser lesbar, weil weniger sinnloses Hin-und-Her-Kopieren drin ist. Wenn man also genau weiß wo es geknallt hat, kann man mit den Registerwerten durchaus was anfangen. Mw E. schrieb: > Wenn man sich einen Faulthandler schreibt, der das macht, dann > sicherlich. Wenn man einen Breakpoint in den Faulthandler setzt oder den Debugger so konfiguriert, beim Auftreten eines Faults zu unterbrechen, kann man die Prozessor-Register auch "normal" auslesen. Die Anwendung wird wohl kaum nach Auftreten eines Fault weiter laufen müssen... W.S. schrieb: > aber man darf das Ganze nicht > gar zu sehr übertreiben. Wie kann man effiziente Fehlersuche "übertreiben", und wer verbietet es? Die J-Links kann ich jedenfalls auch empfehlen, die ST-Links... weniger.
:
Bearbeitet durch User
egal schrieb: >> Für Register existiert sowas glaube ich nicht, macht imho auch nicht >> viel Sinn. (Da brauchts dann eher ETM bzw. ITM Debugeinheit und eine >> passende Software dazu) > > Also meines erachtens sollte sich das Debug-Interface auch einfach wie > ein weiterer Bus-Master verhalten. > > Ich habe beruflich früher mal mit den TriCores gearbeitet und da ging > das auch, dass man auf alle Peripherie-Register zugreifen konnte. Ja, hab mich schlecht ausgedrückt. Ich meinte die CPU Register. (Ich verwende den Begriff Register nur selten in Verbindung mit Peripherieeinheiten) Johannes S. schrieb: > CPU Register konnte afaik schon das ältere ST-Utility anzeigen. Das kann so ziemlich jeder Debugger bei so ziemlich jeder CPU die ich kenne solange die CPU steht. Mir ging es darum, dass es meiner Meinung nach wenig Sinn macht die CPU Register in Echtzeit während die CPU läuft zu "sehen". Man kann das sowie nicht zuordnen. Niklas G. schrieb: >> Sind R0 bis R12 in >> einem optimierten Programm überhaupt interessant? > > Klar, wenn man den Sourcecode und ein Assemblerlisting hat. IMO ist der > Assemblercode optimierter Programme sogar besser lesbar, weil weniger > sinnloses Hin-und-Her-Kopieren drin ist. Wenn man also genau weiß wo es > geknallt hat, kann man mit den Registerwerten durchaus was anfangen. Genauso ist es. Wir hatten mal einen Fall dass ein Embedded OS bei Taskunterbrechung (Premption durch höherpriore Task nach Interrupt) die Condition Flags im CPSR nicht wieder hergestellt hat. Das war sehr spaßig, wenn ein Teil von einem "if" ausgeführt wird und der andere Teil nicht. Sowas findet man nur wenn man in die Register schaut und den Assembler dazu versteht. Zum Glück ist ARM Assembler gut lesbar.
Niklas G. schrieb: > Wenn man einen Breakpoint in den Faulthandler setzt oder den Debugger so > konfiguriert, beim Auftreten eines Faults zu unterbrechen, kann man die > Prozessor-Register auch "normal" auslesen. Die Anwendung wird wohl kaum > nach Auftreten eines Fault weiter laufen müssen... Er schrieb ja explizit von sichern, daher meine Aussage. Die Anzeige des Faults ist je nach IDE unterschiedlich in der Qualität. Der Faultanzeiger der IAR für Cortex-M zB ist recht schlecht und zeigt auch oft mal nichts an. Daher hatte ich mir da mal Handler selber geschrieben. Die geben das wahlweise per UART aus oder packen es in ein struct. Der BKPT kommt dann wenn das struct gefüllt ist. Dieser Handler klamüsert auch schon die Faultbits auseinander. Damit sieht man gleich, dass es zb ein laden eines struct vom Nullpointer war.
> nach wenig Sinn macht die CPU Register in Echtzeit während die CPU läuft > zu "sehen". Man kann das sowie nicht zuordnen. Das denke ich auch. Zumal es dann ja auch noch den Cache gibt und man sich fragen muesste was da so drin steht. Es ist sicherlich sehr interessant aus einer laufenden CPU Variablen auszulesen um sich bei komplexen Regelungen/Programmen einen Ueberblick ueber den aktuellen Zustand zu verschaffen, aber ich denke Register muss ich auch erst sehen wenn ich im Singlestep da durch gehe und gleichzeitig den Assemblercode sehe. Lustig ist das bei den SH2 von Renesas. Die sind superscalar, da fuehrt die CPU auch schonmal zwei Assemblerbefehle gleichzeitig aus. Dann sieht man zwei Balken im Debugger welche den gerade aktuellen Befehl anzeigen. Lustig finde ich es immer wieder wenn hier so getan wird als wenn das nur Profis bei krassen Problemen brauchen. Aber gerade Anfaenger sollten unbedingt mal ihrem Programm mit dem Debugger auf die Fuesse schauen. Man lernt da so einiges was man vorher nicht vermutet haette. Olaf
Andreas M. schrieb: > Genauso ist es. Wir hatten mal einen Fall dass ein Embedded OS bei > Taskunterbrechung (Premption durch höherpriore Task nach Interrupt) die > Condition Flags im CPSR nicht wieder hergestellt hat. Das ist aber schon ein übles Problem des RTOS, das kann man schon nicht mehr als "Bug" bezeichnen - zumal die Cortex-M das xPSR ja automatisch wiederherstellen, wenn man denn den richtigen Stack hat. Olaf schrieb: > Lustig finde ich es immer wieder wenn hier so getan wird als wenn das > nur Profis bei krassen Problemen brauchen. Aber gerade Anfaenger sollten > unbedingt mal ihrem Programm mit dem Debugger auf die Fuesse schauen. Absolut, und auch die Bedienung des Debuggers lernen, das gehört m.M.n zu den Grundfertigkeiten des Programmierens. Wer im Berufsleben keine Debugger benutzt weil er "das nicht kann" (so schwierig ist es nun auch nicht) bzw. "noch nie gemacht hat", macht etwas falsch. Programmieren sollte man ohnehin erst am PC lernen, und dort ist der Debugger in den meisten IDEs einfach direkt und problemlos nutzbar; mit dieser Erfahrung will man den Debugger im Embedded-Bereich dann auch nicht mehr missen.
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.