Hi, folgende Optionen hab ich auf einem Windows PC getestet, mit einem ATMEGA32 und AVR Dragon. AVRStudio 5 in verschiedenen Versionen <-- beim Breakpoint wird nicht angehalten AVRStudio 4 + AVR Toolchain in letzter Version: <-- Breakpoint geht, AVR-LIB hat noch die Debug-Info, daher ist Debugging recht ätzend wenn die Sourcen gesucht werden. Debug-Info gestrippt, läuft ganz i.O. Eclipse + AVR-Eclipse: Flashen ging nur jedes 2te Mal, Debugger-Anbindung gibts nicht.(?) WinAVR von 2010, da gabs ein anderes Problem, erinnere mich nicht. Was ich eigentlich wissen will - was ist eure "stabilste" Option um AVRs zu debuggen? Gruß, Daniel
My D. schrieb: > Was ich eigentlich wissen will - was ist eure "stabilste" Option um AVRs > > zu debuggen? Assembler, Kenntniss der Architektur und logisches Denken.... KH
1) Einen freien Pin toggeln und am Oszilloskop zusehen 2) Die serielle Schnittstelle zum Laufen bringen, und variablen ausgeben/abfragen 3) Einen DAC temporaer auf den SPI Bus (oder aehnlich) schnallen und Werte darauf ausgeben. Mit dem Oszilloskop zuschauen
My D. schrieb: > Eclipse + AVR-Eclipse: > Flashen ging nur jedes 2te Mal, Debugger-Anbindung gibts nicht.(?) Mit avarice und avr-gdb geht das bestimmt. Unter Codeblocks hab ich das schon mal am Laufen gehabt. Gruß Oliver
>2) Die serielle Schnittstelle zum Laufen bringen, und variablen >ausgeben/abfragen Wohl die beste Methode. Bei einem oder mehreren Interrupts macht Single Stepping sowieso keinen Sinn mehr;) Debugger werden oft überschätzt.
>>2) Die serielle Schnittstelle zum Laufen bringen, und variablen >>ausgeben/abfragen >Wohl die beste Methode. Bei einem oder mehreren Interrupts macht >Single Stepping sowieso keinen Sinn mehr;) Debugger werden oft >überschätzt. Je nach externem Prozess sollte man den nicht abhalten, da der Zustand moeglicherweise nicht stabil ist, oder Schaden entstehen kann. Moeglicherweise ist die Vorgeschichte auch wichtig und nicht instantan herbeifuehrbar.
holger schrieb: > Wohl die beste Methode. Naja. Aber eine gute Methode. + Leuchtdiode + richtiger Debugger + wissen, was man tut mfg.
KH, die Kommentare kannst du dir sparen. Mit einem guten Debugger auf Mehrkernsystemen habe ich ausreichend Erfahrung, ETM, 5s Ausführungs-Historie sowie Laufzeitmessung ist essentiell. Vom AVR Dragon erwarte ich das natürlich nicht - aber zumindest den Anspruch an stabiles Arbeiten, Single Stepping, konditionale Breakpoints habe ich. Wie es aussieht haben allerdings wenige den AVR Dragon als Debugging-Instrument im Einsatz.
My D. schrieb: > Wie es aussieht haben allerdings wenige den AVR Dragon als > Debugging-Instrument im Einsatz. So sieht's zumindest aus. Schade, schade, schade! Dabei hätte ich gehofft, hier mal etwas prufunderes zum Thema zu lesen. Zum Thema Debugger ist leider nur "Dünnes" zu finden auch mit Suchmaschinen des Vertrauens. Das einzige, halbwegs anschauliche sind Videoclips von ATMEL auf youtube. Also Leute, was kann man denn nun mit den Debuggern in der Praxis anfangen? Ihr spielt doch auch nicht alle nur mit dem Simulator oder? Hat einer denn schon mal ein "How-to" oder "tutorioal" zum debuggen mit Debuggern gefunden?
Ich habe zwar einen JTAG ICE mkII, aber noch NIE JTAG benutzt. Ein mal kurz debugWire um zu sehen, ob das funktioniert. Einen Mikrocontroller kann man nicht so wie Desktop-Applikationen debuggen. Einfach mal das Programm anhalten um die Werte in einer Regelschleife zu sehen? Dann machts je nach Stellglied BUMMS und irgendwas ist abgeraucht. Die beste Möglichkeit zum Debuggen ist bei Mikrocontroller eine (mehrere) LED/s oder UART. Falls die UART zu langsam ist, nimmt man eben einen FT232 und geht auf 1MBaud hoch.
ja klar...per UART debuggen ist sicherlich besser als per JTAG/SW etc %) @threadersteller: ich hatte einen XMEGA64 mit Dragon AVR benutzt. Das lief eigentlich sehr zufriedenstellend und stabil(mit AVRStudio 4 und 5) Was genau willst du debuggen? Optimierung mal ausgestellt? Wenn bei bestimmten Breakpoints nicht angehalten wird, kann es daran liegen dass das wegoptimiert wurde. JTAG Speed veringern...bin mir nicht sicher ob man das da umstellen konnte...ich mach nix mehr mit AVR. Wie lang ist dein JTAG Debugkabel? Lange Kabel können sich in lustigen Fehlerchen bemerkbar machen
Ich persönlich nutze den Dragon im Zusammenspiel mit einem 328P schon im dritten Projekt ohne Probleme. Die Datenübertragung ist zwar nicht wirklich schnell, aber es läuft ohne jegliche Abstürze o.ä. Geschickt gesetzte Breakpoints sind oft sehr hilfreich, um Fehler schnell zu finden. Ich kann mich aber nur meinen Vorrednern anschließen: man muss schon ziemlich genau wissen, was man tut...
A. B. schrieb: > Was genau willst du debuggen? Optimierung mal ausgestellt? Wenn bei > bestimmten Breakpoints nicht angehalten wird, kann es daran liegen dass > das wegoptimiert wurde. Unter AVR Studio 5 kannst du neben der Optimierungsstufe auch den DebugLevel einstellen. Da stört die Optimierung meist nicht, wenn ein Debuglevel von -g3 eingestellt wurde.
Schön, dass in dieses nützliche Thema hier mal Leben reinkommt :-) Also mal andersrum gefragt: Worin liegt denn nun der Nutzen eines JTAG(-u.ä.)-Debuggers? Was kann so ein Teil, was man mit UART (prima Methode, die für viel aber nicht für alles hilft) und/oder LED nicht schafft? Also was ich bisher erahne ist, dass man mit diesen Debuggern bei angeschlossener Perpherie arbeiten kann. Ist das richtig so? Da ist auch viel die Rede von schnellem entwickeln und Zeitersparnis.
> Da ist auch viel die Rede von schnellem entwickeln und Zeitersparnis.
CernD, das ist nicht wirklich der Fall.
Bei spezieller Fehlersuche und Analyse ist ein Debugger unerlässlich.
CernD schrieb: > Also mal andersrum gefragt: Worin liegt denn nun der Nutzen eines > JTAG(-u.ä.)-Debuggers? Was kann so ein Teil, was man mit UART (prima > Methode, die für viel aber nicht für alles hilft) und/oder LED nicht > schafft? Im Prinzip kann man mit Uart und LED fast alles machen, was mit dem JTAG-Debugger auch geht. Mit dem Debugger geht es manchmal einfach schneller und einfacher. Der große Vorteil des Debuggers ist, dass man nicht schon beim kompilieren wissen muss, was man sich für Variablen/Speicherstellen/... anschauen möchte. Man setzt einen Breakpoint an irgend eine Stelle im Programm und wenn der Breakpoint erreicht worden ist, kann man sich alles in Ruhe anschauen. Ein weiterer Vorteil ist, dass man damit auch die Werte von Variablen und Registern (incl. PC) ändern kann. Man kann sich damit z.B. anschauen, was beim Power-On Reset passiert, also den Startup-Code, bevor die main()-Funktion erreicht wird und bevor der UART initialisiert worden ist. Speziell wenn man einen Controller und die Peripherie-Funktionen noch nicht so gut kennt, kann so ein Debugger sehr nützlich sein, um Zugriffe auf die Peripherie und Interrupt-Handler zu debuggen.
My D. schrieb: > Bei spezieller Fehlersuche und Analyse ist ein Debugger unerlässlich. Hallo, das ist wirklich ein Thema bei dem es schwierig ist, Infos zu bekommen. Nun verrate uns doch, wofür ein Debugger unerlässlich ist. Ein paar Beispiele wären hilfreich. Spezielle Fehlersuche klingt auch toll, aber was soll das heissen? Gibt es Namen für diese Methode(n)?
Johannes E. schrieb: > Der große Vorteil des Debuggers ist, dass man nicht schon beim > kompilieren wissen muss, was man sich für Variablen/Speicherstellen/... > anschauen möchte. Man setzt einen Breakpoint an irgend eine Stelle im > Programm und wenn der Breakpoint erreicht worden ist, kann man sich > alles in Ruhe anschauen. Es ist besonders bei Mikrocontrollern oft unmöglich das Programm zu stoppen. Deswegen sollte man JTAG/DebugWire dort keine allzugroße Aufmerksamkeit schenken.
>Es ist besonders bei Mikrocontrollern oft unmöglich das Programm zu >stoppen. Deswegen sollte man JTAG/DebugWire dort keine allzugroße >Aufmerksamkeit schenken. Ist auch wirklich nervig wenn man beim Single Stepping immer wieder im Timerinterrupt landet;)
A. B. schrieb: > ja klar...per UART debuggen ist sicherlich besser als per JTAG/SW etc %) > > @threadersteller: ich hatte einen XMEGA64 mit Dragon AVR benutzt. Das > lief eigentlich sehr zufriedenstellend und stabil(mit AVRStudio 4 und 5) > > Was genau willst du debuggen? Optimierung mal ausgestellt? Wenn bei > bestimmten Breakpoints nicht angehalten wird, kann es daran liegen dass > das wegoptimiert wurde. > > JTAG Speed veringern...bin mir nicht sicher ob man das da umstellen > konnte...ich mach nix mehr mit AVR. > > Wie lang ist dein JTAG Debugkabel? Lange Kabel können sich in lustigen > Fehlerchen bemerkbar machen Kompiliert wurde mit O0. A.B., ich hab sogar das gleiche ELF-File in AVR Studio 5 und 4 geladen, unter AVR Studio 4 ist verlässlich der Breakpoint angesprungen worden. AVR Studio 5 hat mich leider kläglich im Stich gelassen. Allerdings unter Win7/64Bit, ev. gibts da auch beim Treiber o.ä. Einfluss... Daher schließe ich erstmal "lange" Debugkabel o.ä. aus.
> Hallo, > > das ist wirklich ein Thema bei dem es schwierig ist, Infos zu bekommen. > Nun verrate uns doch, wofür ein Debugger unerlässlich ist. Ein paar > Beispiele wären hilfreich. > > Spezielle Fehlersuche klingt auch toll, aber was soll das heissen? Gibt > es Namen für diese Methode(n)? Bei der Implementierung und Inbetriebnahme von Echtzeit-Betriebssytemen gibt es z.B. Situationen, in denen verschiedene priorisierte Interrupts bearbeitet werden, sychron zu angeschlossenen Bus-Systemen, und dabei in 24h Laufzeit eine Situation auftritt, die zum Fehlerfall führt (HALT der ECU). Durch einen Debugger kann man nachvollziehen, welcher Code in der Zeit vor dem HALT ausgeführt wurde, welche Interrupts aktiv waren, etc. Mit statischer Code-Analyse lassen sich solche Probleme nicht eingrenzen - je größer das Projekt desto unwahrscheinlicher. Anderer Fall ist die Inbetriebnahme einer Speicherkapsel/MPU. Um die einzelnen Zugriffe von Fremdsoftware über die Kapsel nachzuvollziehen ist ein Debugger gut. Oder um festzustellen welche der 100 Fremdsoftwaren mal wieder über den erlaubten RAM heraus schreibt.
>A.B., ich hab sogar das gleiche ELF-File in AVR Studio 5 und 4 geladen, >unter AVR Studio 4 ist verlässlich der Breakpoint angesprungen worden. >AVR Studio 5 hat mich leider kläglich im Stich gelassen. Allerdings >unter Win7/64Bit, ev. gibts da auch beim Treiber o.ä. Einfluss... Fein, dann muss man also erst mal den Debugger debuggen. Dann bleib doch bei bei Avrstudio 4 wenn 5 Probleme macht. Oder nimm eine LED oder einen UART.......
Simon K. schrieb: > Es ist besonders bei Mikrocontrollern oft unmöglich das Programm zu > stoppen. ?? So so. Das hängt wohl vollständig von der jeweiligen Anwendung ab, die man gerade testet und ist als solche Pauschalaussage völliger Unsinn. Ich verwende oft einen Debugger und ich habe es oft mit Echtzeit-Anwendungen zu tun. Sicher gibt es Grenzen und die sollte man kennen. holger schrieb: > Ist auch wirklich nervig wenn man beim Single Stepping immer > wieder im Timerinterrupt landet;) Z.B. "Run to line" verhindert das. So kann man sich von Zeile zu Zeile hangeln. Man muß das ja keine 300 Zeilen lang machen. Und so unbequem ist das ja nun auch nicht. Maus setzt den Cursor in die nächste Zeile (klick) und dann "Run to Line" auf eine Funktionstaste legen falls es noch nicht ist. Fertig. Und klar, welche Methode man auch immer verwendet: - UART-Ausgabe: für "Echtzeit" auch nur bedingt brauchbar, da auch das Senden Zeit kostet - LED: recht gut für "Echtzeit" da die Laufzeit nicht wesentlich verändert wird. Wobei 'wesentlich' auch relativ ist. - ICE-Debugger: vereinfacht das Verfolgen von Programm-Sequenzen oder Berechnungen enorm. Bei Echtzeitanwendungen muß man sich halt was Schlaues überlegen ;-) - Auch gut geht: Irgendein schneller Bus wenn man einen Analyzer dafür hat. Ich habe aktuell einen PCI-Bus im System. Da kann ich dann in "Echtzeit" Werte in das Target an unbelegte Register schreiben. Der PCI-Bus-Analyzer zeigt mir dann später was dort los war und das sogar mit Timing-Analyse. Das kann man mit allen schnellen Bussen machen, wenn man einen Analyzer dafür hat und man Adressen hat, in die man gefahrlos schreiben kann. Zugegeben, auf einem AVR wird diese Methode schwer ;-) Aber wenn man einen freien Port hat..... :-) Alles hat seine Vorteile in unterschiedlichen Situationen. Da muß man tatsächlich wissen was man tut. Zurück zum Thema. Debuggen mittels Eclipse, geht auch über avarice und avr-gdb wie oben schon mal jemand geschrieben hat. Breakpoints gehen auch. Aber beim Dragon weiß ich nicht, ob der Soft-Breakpoints unterstützt. Und H/W Breakpoints gibt es glaube ich nur 2. Aber wenn man die intelligent setzt, dann geht das auch. Wenn man erstmal im Debugger ist, dann geht das ganz stabil. Nur bis zum Debugger braucht es manchmal(!) 1-2 Anläufe. Ich habe die Erfahrung gemacht, dass das Debuggen (JTAG-ICE MkII) über den UART immer schneller geht, als über das USB-I/F. Das habe ich mehrmals probiert. Grundsätzlich kam ich da gut mit zurecht. Über AVR-Studio 4 gelangt man einfacher in den Debugger. Klappt immer beim 1. Mal. Mit AVRStudio 5 habe ich keine Erfahrung. Nie genutzt. Just my 2 cents 900ss
900ss D. schrieb: > Bei Echtzeitanwendungen muß man sich halt was > Schlaues überlegen ;-) Eigentlich muss man sich immer was Schlaues überlegen. ;-) So aus der Trickkiste: . immer optimierten Code debuggen, sonst debuggt man zweimal . auf `asm("nop");' kann man immer einen Breakpoint setzen, auch auf `PORTB = 42;' . wenn man sich für Zwischenergebnisse interessiert, der Compiler diese aber wegoptimiert, dann erfindet man schnell eine `volatile' Variable, in der man dieses festhält; das macht den Code zwar auch ein wenig langsamer, aber nicht so extrem, wie wenn man mit -O0 compiliert . wenn man von mehreren Durchläufen irgendwelche Daten sammelt, kann man sich ein "Logbuch" anlegen und dessen Inhalt dann mit dem Debugger später ansehen, ohne das Timing der Durchläufe selbst zu beeinflussen (Bsp: uint8_t logidx; uint16_t log[NLOG]; ... log[logidx++] = data; if (logidx == NLOG) logidx = 0;) . für Dinge wie das eben genannte sollte die zum Debuggen benutzte Plattform stets noch ausreichend freie Ressourcen haben; selbst, wenn die endgültige Applikation also in einen ATmega88 passt, nimmt man zum Debuggen einen ATmega168 . Debugging von ISRs nach Möglichkeit abschalten (gab's das nicht auch bei AVR Studio 4 dann irgendwann? bei AVaRICE ist es die Option -I) . wie 900ss schon schrieb, statt single-step lieber in größeren Sprüngen vorwärts gehen . hin und wieder hilft es einfach auch mal, sich den disassemblierten Code um den PC herum anzusehen um zu verstehen, in welchen Registern sich gerade die interessanten Zwischenergebnisse befinden
Jörg Wunsch schrieb: > Eigentlich muss man sich immer was Schlaues überlegen. ;-) Recht hast du :-) > So aus der Trickkiste: <snip>.... Schöne Ergänzung. Wenn die "Echtzeit" etwas gemütlicher sein darf, dann nehme ich für das von dir beschriebene Logbuch sprintf(). Es gibt die Anzahl der "ausgegeben" Zeichen zurück, mit der Zahl kann man schön den pointer für die nächste Ausgabe weiter setzen. Nach dem Testlauf einfach ein printf("%s", logBuffer) und schon hat man alles in Klartext und auf Wunsch auch mit Zeilenumbruch. Für ganz Faule ;-)
>Also Leute, was kann man denn nun mit den Debuggern in der Praxis >anfangen? Ihr spielt doch auch nicht alle nur mit dem Simulator oder? printf()-Ausgaben mit Timestamps, bzw noch ein Error-Log Trace (ebenfalls inkl. Timestamps) ist das einzig wahre...
>printf()
Toll wenn man Speicher zum Verschleudern hat.
Erst muss man natuerlich die Prozesse auch durchlaufen lassen koennen.
Dazu ist ein debugger gut geeignet. Nachher wird's schwieriger.
Nee. Wenn man Speicher zum Verschleudern hat, dann legt man ein Array an
und fuellt den per Code wie einen Tracebuffer.
Wenn man weniger Daten hat, genuegt das UART. Das Uart erlaubt einen
Prozess ueber leaengere Zeit zu beobachten. Dann kann man sich zB
irgendwelche Regelgroessen ausgeben lassen, Zustandsvariablen usw. Bei
schnelleren Ablaeufen kann man ein MultiDAC nehmen, und zB 8 Variablen
gleichzeitig beobachten.
Ich muss mal ein bisschen Trollen. Fuer mich ist der Debugger, der der irgend etwas debugged. Wie er das macht muss er sich von Projekt zu Projekt neu ueberlegen, da gibts kein universal Heilmittel. Ich verwende alles moegliche was sich mir bietet, je nach Projekt faengt das bei der LED an geht ueber UART, JTAG, O-Scope bis zum Logicanalyzer. Im allgemeinen setze ich mich mit ins Boot von Jörg Wunsch und 900ss 1. > Eigentlich muss man sich immer was Schlaues überlegen. ;-) und 2. ein log ist der beste Weg um zu analysieren was da vorgegangen ist. Ich war auch mal jung und habe "einfach drauflos programmiert" und dann Breakpoints gebraucht um mir Variablen oder Register anzusehen um die Fehler zu finden. Heute ueberleg ich mir vorher was da rauskommen soll, da erlebt man Ueberaschungen nur durch die eigene Bloedheit. Ju
Das Wichtigste ist, man muss Debuggen als Teil des EntwickungsProzesses sehen und auch so planen
Delta Oschi schrieb: > Das Wichtigste ist, man muss Debuggen als Teil des EntwickungsProzesses > sehen und auch so planen Ich glaube, das fasst es prima zusammen. JTAG, debugWIRE & Co. sind dabei nützliche Hilfsmittel, die einem die Arbeit vereinfachen können (und bei richtiger Benutzung dann Zeit sparen gegenüber "printf"- oder "LED"-Debugging), aber sie sind genauso wenig das allein selig Machende wie andere Methoden.
Simon K. schrieb: > Es ist besonders bei Mikrocontrollern oft unmöglich das Programm zu > stoppen. Deswegen sollte man JTAG/DebugWire dort keine allzugroße > Aufmerksamkeit schenken. Da gibt es schon einige Tricks: Wenn man eine Funktion debuggen möchte, die an einer kritischen Stelle aufgerufen wird, an der man nicht anhalten kann, dann mache ich das oft so, dass ich diese Funktion zum Testen an einer anderen Stelle nochmal aufrufe (z.B. ganz am Beginn der Main-Funktion). Da kann man dann auch bequem mit unterschiedlichen Parametern spielen. Wenn man eine Hardware ansteuert, z.B. bei einer Regelung, dann kann man zum Debuggen kurz vor dem Breakpoint die Freigabe ausschalten, z.B.: if (PINA & 1) // Trigger-Eingang für Breakpoint { FreigabeAus(); // Hardware-Freigabe ausschalten asm("nop"); // hier den Breakpoint setzen } Man muss, wie weiter oben schon erwähnt, ein paar schlaue Ideen haben, dann gibt es für fast alles eine Lösung. Printf-Anweisungen sind gut geeignet, um herauszufinden, an welcher Stelle ein Prozess hängenbleibt und um Werte zu protokollieren. Um herauszufinden, warum sich ein Prozess aufhängt bzw. warum ein Wert falsch berechnet wird, ist meistens der Debugger besser geeignet.
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.