Hallo, nach viel Arbeit habe ich es endlich geschafft, AVRs mit Code::Blocks unter Linux debuggen zu können. Ich starte im Terminal avarice mit folgendem Befehl: avarice --mkII --dragon --jtag usb --part atmega48 --debug :4242 Avarice wartet dann auf eine Verbindung vom AVR-GDB. Diese kommt auch zustande, wenn ich in CodeBlocks das Debuggen starte. Das ist die gute Nachricht. Die schlechte ist: Das Ganze funktioniert nur vernünftig per JTAG. Das Selbe wollte ich über DebugWire mit einem ATMega48 machen. Dieser hat nämlich kein JTAG. Im obenstehenden avarice-Befehl wird noch ein "--debugwire" hinzugefügt. Es klappt aber nicht zuverlässig. Manchmal, nach USB ein- und ausstecken, und/oder Versorgung ein- und ausschalten und/oder PC-Neustart und/oder Controller Erase + Neuprogrammierung funktioniert das Debuggen. Wenn ich dann mit AVR8 Burn-O-Mat versuche, ein geändertes Programm als .hex zu flashen, funktioniert dies, aber auch nur manchmal. Danach ist kein Debuggen mehr möglich. Das DWEN-Fusebit ist aber laut dem Burn-O-Mat nach wie vor gesetzt. Die Zusammenhänge, wann es läuft und wann nicht, erschließen sich mir nicht. Ich habe schon so viel herumprobiert, dass ich den Wald vor lauter Bäumen nicht mehr sehe. Kann mir jemand sagen, wie ich vorgehen soll, dass es funktioniert? Ich wäre über jede Hilfe dankbar, denn das Ganze ist sehr frustrierend. :-( Wenn ich vor dem Umstieg von Windows auf Linux gewusst hätte, was das für eine Tortur ist, hätte ich für das Projekt einen AVR mit JTAG genommen. Jetzt muss ich das irgendwie hinkriegen. Gruß Third-Eye
:
Bearbeitet durch User
Habe inzwischen herausgefunden, dass AVR8 Burn-O-Mat zumindest versucht, den Controller per DebugWire zu beschreiben. Er meldet aber dann, dass das Flashen fehlerhaft war. Jedenfalls ist nach diesem Programmiervorgang kein Debuggen mehr möglich, Avarice bringt ein paar mal die Meldung got asynchronous event: 0xf7 und beendet sich dann. Der Inhalt des Flashs scheint aber auch gelöscht oder zumindest zerstört worden zu sein. Denn danach funktioniert mein LED-Blink-Programm nicht mehr. Die LED bleibt aus. Auch nach dem erneuten Aus- und Einschalten. Anschließend kann ich dann mit AVR8 Burn-O-Mat per ISP den Controller wieder flashen. Er meldet aber dann, dass ISP nicht funktioniert, er verucht es über DebugWire und dann kann er den Controller erfolgrich flashen. Habe ich nicht vorhin genau das versucht? Schön langsam regt mich das echt auf... Solange ich nichts mit AVR8 Burn-O-Mat mache, funktioniert alles. Ich glaube, ich versuche avrdude manuell zu benutzen. Vielleicht liegt es an irgendeinem der Programmargumente. Wer noch eine Idee hat, bitte melden.
Hi, Hier mal ein schuss ins blaue... Zumindest waren es mal meine probleme mit den ich kämpfen musste. Mein setup: - Avr dragon - avr dude - ubuntu... Diverse Versionen ab 12.x - geflashed wird per SPI. - Debugwire habe ich auch schon verwendet... Aber eher selten. Probleme: - schlechtes oder zu langes ISP kabel. - dragon am usb3.0 port wollte nicht. Habe es mit ubuntu 14.04 noch nicht getestet. - dragon am usb-hub (aktiv) wollte auch nicht. Könnte am billighub liegen. - schlechte Stromversorgung am avr. Spannungsregler bzw Elko ausgetauscht. - falsch beschaltet ;-) - abhängig vom mondstand will der dragon nur mit verminderter Geschwindigkeit fashen. Habe noch nicht herausgefunden warum. Vielleicht hilft Dir das etwas weiter. -Foka.
Der Tipp mit der Hardware hat mir geholfen. Danke. Ich war so darauf fixiert, dass es ein Software-Problem sein muss, dass ich keinen Blick auf die Hardware geworfen hatte. Ich habe heute mal das Oszi an den Resetpin gehängt. Und siehe da: Wenn mein Labornetzteil ausgeschaltet ist, ist am µC und damit auch am Resetpin immer noch ca. +1,5V. Die Schaltung wird dann wohl vom Dragon weiter versorgt. Jedes mal, als ich das Labornetzteil ausgeschaltet hatte, ist der Controller weitergelaufen. Das hätte also im Atmel Studio auch nicht funktioniert. Bisher (bin noch nicht so lange Linuxbenutzer) waren meine Schaltungen, bei denen ich DebugWire verwendete, wohl niederohmig genug, um den Controller beim "Power Cycle" wirklich zu resetten. Eigentlich hätte ich ja gewusst, dass DebugWire, elektrisch gesehen, ein ziemliches Sensiebelchen ist... Egal. Ich freue mich, dass es jetzt funktioniert! :-)
Hm, jetzt funktioniert zwar das Debuggen perfekt, aber dabei zerschießt er das Programm. :-( D.h. ich kann ganz normal Debuggen, Pausieren, Weitermachen, Breakpoints setzen usw. Aber wenn ich das Debuggen beende, ist das µC Programm zerschossen (evtl. auch ganz gelöscht, das habe ich noch nicht überprüft). Ich muss jedes Mal neu flashen. Das kann doch nicht im Sinne des Erfinders sein? Woran kann das liegen? avarice ist Version 1.13 avr-gdb ist Version 7.6.50.20131218-cvs
Hi, so weit ich mich erinnern kann muss nach dem debuggen jede page, die ein Brechpunkt hatte, neu geflasht werden. Die gesamte Prozedur ist etwas fummelig. Damals habe ich vor dem Verlassen des debuggers immer alle breakpoints ausgeschaltet. Damit sollte der dragon alle entsprechenden pages wieder neu laden: (gdb) disa b [breakpointNr] oder (gdb) del br [breakpointNr] (Ohne argumente werden alle Brechpunkte ausgeschaltet/geloescht.) Ich weiss aber nicht mehr was ich genau danach gemacht habe... auf jeden Fall isp-mode wieder einschalten (dwen aus) und... na ja wie gesagt, ist schon laenger her. Fuer die ganze Prozedur gibts im Netz, auch hier im Forum, jede menge Anleitungen. Ansonsten haben wir hier einen Moderator (Joerg) der fuer uns den avrdude, zum Gorossteil, verbrochen hat ;-) Er kann Dir bestimmt auch weiter helfen. -Foka
Soetwas in der Art habe ich mir schon gedacht, dass die Breakpoints irgendwie wieder entfernt und der ursprüngliche Code wiederhergestellt werden muss. Ich habe mich inzwischen etwas eingelesen, wie das Debugwire eigentlich funktioniert. Hatte es zwar schon oft genutzt, aber nie hinterfragt. Dass jeder Breakpoint den Flash überschreibt, hat mich etwas erstaunt. Da sollten die Herren von Atmel mal in Richtung STM8 schielen (SWIM) und sich da was abgucken. ;-) Ich wusste gar nicht, dass avrdude "von hier" stammt. Coole Sache. :-) Ich habe im Netz leider nichts Brauchbares gefunden, welche Befehle im AVR-GDB zum Wiederherstellen des ursprünglichen Proramms notwendig sind. Kommandos wie "detach", "disconnect", "kill" usw. waren jedenfalls nicht erfolgreich (gleiches Phänomen, Programm ist anschließend nicht mehr lauffähig). Hat jemand mehr Infos, welche Prozedur zum Beenden nötig ist? Eine andere Frage wäre, wie ich das im Code::Blocks eingestellt kriege? Es gibt zwar Felder, in die man Kommandos eintragen kann: "Additional GDB commands" --> "Before connection" und "After connection". Leider gibt es nicht soetwas wie "After connection is terminated" o.ä.
Third Eye schrieb: > Ich habe im Netz leider nichts Brauchbares gefunden, welche Befehle im > AVR-GDB zum Wiederherstellen des ursprünglichen Proramms notwendig sind. > Kommandos wie "detach", "disconnect", "kill" usw. waren jedenfalls nicht > erfolgreich (gleiches Phänomen, Programm ist anschließend nicht mehr > lauffähig). > > Hat jemand mehr Infos, welche Prozedur zum Beenden nötig ist? Die Prozedur must Du mit dem avrdude beenden. Kommandos im gdb bringen hier nix. Schau mal hier: http://www.homebuilthardware.com/index.php/avr/linux-avrdragon-tutorial-1/ Nach dieser Seite habe ich mich damals gerichtet und es hat ganz gut funktioniert. Noch paar nuetzliche Tips findest Du in diesem Thread: Beitrag "Stabilstes Debugging für AVRs" -Foka
Third Eye schrieb: > Soetwas in der Art habe ich mir schon gedacht, dass die Breakpoints > irgendwie wieder entfernt und der ursprüngliche Code wiederhergestellt > werden muss. Allerdings macht das das JTAG-ICE normalerweise als Bestandteil seiner Aufräumprozedur selbst. Nur, wenn du die Verbindung zum ICE nicht sauber beendest, hat es dafür natürlich keine Chance. > Da sollten die Herren von Atmel mal in Richtung STM8 schielen (SWIM) und > sich da was abgucken. ;-) Die Herren von Atmel hatten lange vor debugWIRE auch JTAG zum Debuggen parat. Allerdings ist das eine aufwändigere Lösung, weshalb man für die kleinen billigen Tinys nach etwas anderem gesucht hat. Letztlich ist debugWIRE weiter nichts als eine Art Monitorprogramm (sowas war in der Anfangszeit von Mikroprozessoren gang und gäbe). Irgendwo tief versteckt findet man auch noch den ursprünglichen Namen „MonCon“ dafür. > Ich wusste gar nicht, dass avrdude "von hier" stammt. Coole Sache. :-) Stammt es nicht, auch wenn ich de facto der derzeitige Maintainer bin. Die initialen Autoren kommen von überm Teich (und die hatten noch viel Arbeit damit, das blöde Protokoll zu reverse-engineeren, bevor Atmel es dann endlich dokumentiert hat). > Ich habe im Netz leider nichts Brauchbares gefunden, welche Befehle im > AVR-GDB zum Wiederherstellen des ursprünglichen Proramms notwendig sind. “detach” (Lösen der Verbindung zum JTAG-ICE) Wenn das nicht geht, ist irgendwo was foul. Eventuell probierst du's ja erstmal mit einem Standalone-GDB.
Foka Mokra schrieb: > Die Prozedur must Du mit dem avrdude beenden. Das betrifft allerdings das Rücksetzen der Fuse.
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.