Hallo, ich hab grad erst angefangen mit der Thematik zu befassen, aber immerhin laufen schon die ersten einfachen Programme auf einem ATmega8515 im STK500, soweit alles sehr nett und das GCC Tutorial war auch ein guter Einstieg. Genau so ein leichter Einstieg zum Thema Debugging fehlt mir nun. Gibt's irgend wo ein tutorial, das den Einsatz von Insight und GDB zum "in circuit debugging" erläutert? Grüße Flo PS: Gibt's eine Möglichkeit avrdude die Zusammenarbeit mit der aktuellen Firmware (2.0 oder so) für das STK500 zu bewegen?
> Gibt's irgend wo ein tutorial, das den Einsatz von Insight und GDB > zum "in circuit debugging" erläutert? Das kann ich dir erstmal nicht sagen, ich benutze den GDB seit 15 Jahren, da hab' ich keinen Bedarf nach Insight oder so. ;-) Anyway, du bist dir im Klaren, dass man für in-circuit debugging ein JTAG ICE braucht und das das erst ab einem ATmega16 aufwärts funktioniert? > PS: Gibt's eine Möglichkeit avrdude die Zusammenarbeit mit der > aktuellen Firmware (2.0 oder so) für das STK500 zu bewegen? Ja, avrdude 5.0 ist kurz vorm Release.
Hallo Jörg, danke für Deine Antwort. >> Gibt's irgend wo ein tutorial, das den Einsatz von Insight und GDB >> zum "in circuit debugging" erläutert? > > Das kann ich dir erstmal nicht sagen, ich benutze den GDB seit 15 > Jahren, da hab' ich keinen Bedarf nach Insight oder so. ;-) Das ist sicher Geschmakssache, ich hätte nix gegen das GUI, aber im Prinzi ist's egal und hatt eher weniger mit meinem Problem zu tun. > Anyway, du bist dir im Klaren, dass man für in-circuit debugging ein > JTAG ICE braucht und das das erst ab einem ATmega16 aufwärts > funktioniert? Ja, so im Prinzip. Nur gelinkt es mit nicht rauszufinden, was es damit genau auf sich hat und wo wie ichs auf dem Controller bekomme. Also ich glaub im Prinzip ist mir das Konzept schon klar. Es geht ja um remote debugging und auf dem Traget muss ja irgendeine Software laufen, die mit dem remote debugger kommuniziert, das ist wohl JTAG. >> PS: Gibt's eine Möglichkeit avrdude die Zusammenarbeit mit der >> aktuellen Firmware (2.0 oder so) für das STK500 zu bewegen? > > Ja, avrdude 5.0 ist ku>rz vorm Release. Ah, danke. Grüße Flo
> Das ist sicher Geschmakssache, ich hätte nix gegen das GUI, aber im > Prinzi ist's egal und hatt eher weniger mit meinem Problem zu tun. Naja, wie man mit dem GDB und avarice überhaupt klarkommt, ist in der avarice-Doku beschrieben. Wenn du das nicht findest, kann ich dir das auch hier kurz skizzieren, aber bis dorthin hast du noch ein Stück des Wegs vor dir... >> Anyway, du bist dir im Klaren, dass man für in-circuit debugging >> ein JTAG ICE braucht und das das erst ab einem ATmega16 aufwärts >> funktioniert? > Ja, so im Prinzip. Nur gelinkt es mit nicht rauszufinden, was es damit > genau auf sich hat und wo wie ichs auf dem Controller bekomme. > Also ich glaub im Prinzip ist mir das Konzept schon klar. Es geht ja > um remote debugging und auf dem Traget muss ja irgendeine Software > laufen, die mit dem remote debugger kommuniziert, das ist wohl JTAG. Nein, nicht Software, sondern Hardware. Insofern musst nicht du es ,,auf den Controller bekommen'', sondern du brauchst: . einen Controller, der eine JTAG-Engine besitzt; das sind praktisch alle ATmega >= 16 KiB ROM (Ausnahme: ATmega103, ATmega168) . ein JTAG ICE Letzteres ist eine kleine Box, die auf der einen Seite JTAG zum Controller spricht und auf der anderen Seite (zum Host) ein serielles Protokoll über RS-232 oder neuerdings auch über USB. Auf der Host-Seite sitzt als Mittler zwischen dem GDB und dem JTAG ICE dann noch ein avarice-Prozess. Das JTAG ICE gibt's in zwei Ausführungen. Das alte (mark I) hatte einen ATmega16, einen MAX232, ein paar Pegelwandler und einen 7805 zur Stromversorgung via Steckernetzteil. Davon gibt's Clones, die deutlich preiswerter sind als das Atmel-Original, die lassen in der Regel dann die Stromversorgung und die Pegelwandler weg und beziehen die Energie direkt vom Target. Typischerweise arbeiten die Clones so, dass sie einen Bootloader besitzen und dann durch den Endanwender via AVR Studio mit der Atmel-Firmware zu versehen sind. Das neuere mark II (mkII) ist ein ganzes Stück aufwändiger gebaut, da es nicht nur eine größere Firmware abkönnen soll, sondern auch das neue 1-wire-Protokoll namens debugWire für die kleinen AVRs unterstützt. Da werkeln dann zwei ATmega128 drin, die Hostanbindung und Stromversorgung kann alternativ zu RS-232 auch über USB erfolgen. Meine Vermutung ist, dass man für neuere AVRs aber keinen Support mehr fürs mkI bekommen wird, da die Firmware Anschlag voll ist. Die originalen Atmel-ICEs sind recht preisintensiv.
Hallo Jörg >>> Anyway, du bist dir im Klaren, dass man für in-circuit debugging >>> ein JTAG ICE braucht und das das erst ab einem ATmega16 aufwärts >>> funktioniert? > >> Ja, so im Prinzip. Nur gelinkt es mit nicht rauszufinden, was >> es damit genau auf sich hat und wo wie ichs auf dem Controller >> bekomme. Tja, ich muss mich korrigieren, ich hab das Prinzip offensichtlich nicht kapiert... > Nein, nicht Software, sondern Hardware. Das erklärt einiges. > Insofern musst nicht du es ,,auf den Controller bekommen'', sondern > du brauchst: > > . einen Controller, der eine JTAG-Engine besitzt; das sind > praktisch alle ATmega >= 16 KiB ROM (Ausnahme: ATmega103, > ATmega168) Das hätte ich ja noch rumliegen... >. ein JTAG ICE ... letzteres natürlich nicht. Mist. >Letzteres ist eine kleine Box, die auf der einen Seite JTAG zum >Controller spricht und auf der anderen Seite (zum Host) ein serielles >Protokoll über RS-232 oder neuerdings auch über USB. Auf der >Host-Seite sitzt als Mittler zwischen dem GDB und dem JTAG ICE dann >noch ein avarice-Prozess. Danke für die Erklärung. Ich dachte das ginge in Software so wie remote debugging mit zwei PCs > Das JTAG ICE gibt's in zwei Ausführungen. Das alte (mark I) hatte > einen ATmega16, einen MAX232, ein paar Pegelwandler und einen 7805 > zur Stromversorgung via Steckernetzteil. Mal sehen, was so was kostet. > Davon gibt's Clones, die deutlich preiswerter sind als das > Atmel-Original, die lassen in der Regel dann die Stromversorgung > und die Pegelwandler weg und beziehen die Energie direkt vom > Target. Typischerweise arbeiten die Clones so, dass sie einen > Bootloader besitzen und dann durch den Endanwender via AVR Studio > mit der Atmel-Firmware zu versehen sind. Hmm, vielleicht hab ichs wieder nicht verstanden, aber da liest sich jetzt so, als könnte ich einen ATmega16 in mein STK500 stecken, den Bootloader drauf laden, dann meine Applikation und dann debugen. Dann bräuchte ich doch keine weitere Hardware kaufen. > Das neuere mark II (mkII) ist ein ganzes Stück aufwändiger gebaut, > da es nicht nur eine größere Firmware abkönnen soll, sondern auch > das neue 1-wire-Protokoll namens debugWire für die kleinen AVRs > unterstützt. Da werkeln dann zwei ATmega128 drin, die > Hostanbindung und Stromversorgung kann alternativ zu RS-232 auch > über USB erfolgen. Die alte Version würde mir sicher reichen. Grüße Flo
Anfrage an den Sender Jerewan: > Hmm, vielleicht hab ichs wieder nicht verstanden, aber da liest > sich jetzt so, als könnte ich einen ATmega16 in mein STK500 stecken, > den Bootloader drauf laden, dann meine Applikation und dann > debugen. Dann bräuchte ich doch keine weitere Hardware kaufen. ,,Im Prinzip, ja, aber...'' Wenn du dieses STK500+ATmega16 als JTAG ICE benutzen willst, kannst du es natürlich nicht gleichzeitig als Target zum Debuggen nehmen. Das JTAG ICE sitzt ja zwischen Target und Host als separates Gerät. Sinnvoller ist es wahrscheinlich, einen ATmega16+MAX232 auf einer Lochrasterplatine oder so als JTAG ICE zu konfigurieren. Ich weiß nicht, ob's die Schaltpläne vom sogenannten BootICE noch gibt. Alternativ gibt's die Clones kommerziell von Olimex oder von ECROS als ICE-Cube.
Hallo Jörg >> Hmm, vielleicht hab ich s wieder nicht verstanden, aber da liest >> sich jetzt so, als könnte ich einen ATmega16 in mein STK500 >> stecken, den Bootloader drauf laden, dann meine Applikation und >> dann debugen. Dann bräuchte ich doch keine weitere Hardware kaufen. > > ,,Im Prinzip, ja, aber...'' > > Wenn du dieses STK500+ATmega16 als JTAG ICE benutzen willst, kannst > du es natürlich nicht gleichzeitig als Target zum Debuggen nehmen. > Das JTAG ICE sitzt ja zwischen Target und Host als separates Gerät. Ok, verstehe. Ich brauch zwei Controller. > Sinnvoller ist es wahrscheinlich, einen ATmega16+MAX232 auf einer > Lochrasterplatine oder so als JTAG ICE zu konfigurieren. Ich weiß > nicht, ob's die Schaltpläne vom sogenannten BootICE noch gibt. Ja, scheints noch zu geben, hab zumindest einen Schaltplan gefunden, aber da ists glaub ich gescheiter eine fertige Lösung zu kaufen, das spart Zeit. > Alternativ gibt's die Clones kommerziell von Olimex oder von ECROS > als ICE-Cube. Schau ich mir mal an, danke. Scheint so um die 40 EUR zu kosten, geht eigentlich. Sieht mir aber dann doch alles zu kompliziert aus, da bleib ich vielleicht beim UART-Debugging das ist ja ganz einfach, auch wenns nicht wirklich viel mit Debugging zu tun hat. Grüße Flo
> Sieht mir aber dann doch alles zu kompliziert aus, da bleib ich > vielleicht beim "UART-Debugging" das ist ja ganz einfach, auch > wenn's nicht wirklich viel mit Debugging zu tun hat. Klar, solange dir das genügt, nur zu. Aber irgendwann kann es einem auch mal richtig Zeit sparen, wenn man ,,in die Applikation reingucken'' kann. Solange man mit paar UART-Messages auskommt, nehme ich das auch lieber, zumal Einzelschritte mit dem ICE doch ein Stück langwieriger sind.
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.