Mit einem neuen Original AVR-JTAGICEmkII wurde versucht ein Program auf einem ATMega128-Bord zu testen. Nach einigen "Kommunikations-Problemen" - erst nach einem Upgraden hatte das ATMEL-Studio 4.18 den JTAG-Adapter erkannt - konnte zunächst das Programming-Tool angesprochen werden. Damit wurde z.B. die aktuelle Fuse-Programmierung überprüft: JTAGEN und SPIEN waren enabled, d.h. "angehakt", OCDEN nicht. Das wurde nachgeholt, dann das Programmiert-Tool beendet. Nachfolgend wurde unter "Debug/Select Platform and device..." JTAGICEmkII, ATmega128 und USB ausgewählt. Das Ergebnis ist in der Statusleiste zu sehen. So weit so gut - wenn jetzt aber "Start Debugging" gedrückt wird, so passiert erst mal gar nichts - außer, daß offensichtlich der JTAG-Adapter in laufender Aktion ist (erkennbar am schnellen Flackern der linken grünen LED und "Running" in der Statusleiste). Wird jetzt "BREAK" gedrückt, so wird ein Diassembler-Fenster aufgemacht, der gelbe Zeilenzeiger springt auf die letzte Programmspeicher-Zelle +0000FFFF und "Stopped" wird in der Statuszeile angezeigt. Von dort läßt sich dann nichts mehr bewegen - kein Reset oder sonstige Debug-Funktionen sind wirksam, außer mit "Stopp Debugging" das ganze abzubrechen. Wird hingegen der AVR-Simulator ausgewählt, so funktioniert das Debugging einwandfrei: nach "Start Debugging" und Darstellung eines Fortschrittsbalkens unten über der Statuszeile steht dann der gelbe Zeilenzeiger ordnungsgemäß am Beginn des Programms und man kann mit den zur Verfügung stehenden Debug-Befehlen, wie z.B. "Step" den ASM-Code im einzelnen durchgehen. Kann mir jemand erklären, warum das mit dem JTAGICEmkII nicht geht, oder wo liegt der Fehler? Aus den zur Verfügung stehenden ATMEL-Dokumenten konnte ich das jedenfalls nicht herauslesen. Mit Grüßen aus Berlin PSblnkd
Hallo, hatte gestern fast das gleiche Problem mit dem AVR Dragon und einem selbsentwickelten Board mit einem ATmega324P. Heute Morgen konnte ich dann das Problem lösen: Während dem Debuggen ist der nSRST-Pin des AVR Dragon grundsätzlich auf LOW, dadurch war der ATmega324P auf unserem Board grundsätzlich im RESET-Zustand. Den nSRST des JTAG Adapter-Kabel haben ich nun getrennt und alles funktioniert wie es soll. Ich hoffe, ich konnte helfen ... Grüßle, Bix2402.
Hi >Kann mir jemand erklären, warum das mit dem JTAGICEmkII nicht geht, oder >wo liegt der Fehler? In deinem Programm? Was passiert, wenn du dein Programm mit F10 oder F11 schrittweise abarbeitest. MfG Spess
PSblnkd schrieb: > So weit so gut - wenn jetzt aber "Start > Debugging" gedrückt wird, so passiert erst mal gar nichts Nach dem Start,grüner Pfeil oder <CTRL>+F7, wird zuerst das Program geladen, immer, auch wenn nichts geändert wurde. Dabei sieht man einen Fortschrittsbalken unten links in der Statuszeile. Bei langen Programmen deutlich, bei kurzen blinkt der nur kurz auf. Dann bleibt das Programm am Anfang stehen(!): Break-Pfeil auf dem ersten Befehl in der main. Das Programm muss jetzt mit F5 oder Klick auf den gelben Pfeil oben manuell gestartet werden. Wenn dann ein Break, <CTRL>+F5, gemacht wird, bleibt das Programm im Quelltext da stehen, wo es sich gerade zufällig befindet. Aber nur dann, wenn sich im Quelltext auch an der Stelle ein Befehl befindet, der nicht wegoptimert wurde. Das bedeutet, manchmal passiert gar nichts. Richtig funktioniert es nur, wenn die Optimierung im Compiler abgeschaltet wurde. Wenn das Programm steht, kann man unter Tools in der Menüleiste den Disassembler öffnen. Ich debugge grundsätzlich, indem ich vorher einen Breakpoint (F9) setze und den Programmablauf dann gezielt anhalte. Wenn die Optimierung eingeschaltet ist, lässt sich ein Breakpoint nicht überall setzen. Manchmal muss man dann ein wenig nachhelfen. Auf lokale Variable lässt sich z.B. gar kein Breakpoint setzen. Die muss man dann zum Debuggen global mit volatile machen. Irgendwann gewöhnt man sich dran. Ist halt kein Visual Studio auf dem PC. Ein Break per Taste zu einem beliebigen Zeitpunkt, bringt doch nur was, wenn er sich beabsichtigt oder nicht, ewig in einer Schleife aufhält. Jedenfalls fällt mir nichts Sinnvolleres dazu ein. > OCDEN nicht. Das wurde nachgeholt, dann das Programmiert-Tool beendet Die Einstellung ist egal. Die wird automatisch beim Starten des Debuggers gesetzt und beim Beenden wieder weggenommen. Atmega644p, Jtagice MKII, AVR-Studio 4.19, alle Einstellungen default. mfg.
@Bix2402 Das nSRST-Pin ist auf dem "ATmegeEvoBoard" (ATmega128) nicht angeschlossen, daher kommt das als Fehler kaum in Frage. Es sei denn - so wie in einigen veröffentlichten Scahltungen zum JTAG-Adapter dargestellt - es ist eine Verbindung nSRST-Pin mit /RESET des µC zwingend erforderlich. @spess53 Am Programm (Assembler) kann es nicht liegen, weil - wie ich schrieb - dieses im normalen Simulator einwandfrei läuft. Da der JTAG-Debugger an der Programmadresse $FFFF hängenbleibt (siehe o.g. Beschreibung) ist auch F10 bzw. F11 wirkungslos. @Thomas Eckmann Wie ich schrieb, ergibt sich bei mir mit dem JTAGICEmkII kein Fortschrittsbalken, aber mit dem normalen Simulator schon. Deine Beschreibung ähnelt der, wie ich sie mit dem normalen AVR-Simulator kenne. Von dort kann man unter "View" den Diassembler erreichen, welcher aber vom gespeicherten hex-File ausgeht. Wenn über JTAG der Debugger angesprochen wird, liest dieser den tatsächlich im µC-Flash gespeicherten Maschinen-Code aus. Und da liegt eben der Hund begraben - offensichtlich findet der JTAGICE-Debugger nicht das Programmspeicher-Ende, hängt in einer Endlos-Schleife und springt nicht in den Step-Modus bei Progammspeicher 0. Deine Break-Beschreibung bezieht sich auf den Run-Modus, aber da komme ich offensichtlich gar nicht hin, weil der Debugger schon bei der Vorbereitung steckenbleibt. Hängt das evtl. mit meiner AVR-Studio-Version 4.18 zusammen? Irgendwo hatte ich gelesen, daß es auch noch eine 4.19-Version gibt. Grüsse aus Berlin PSblnkd
Hi >@spess53 >Am Programm (Assembler) kann es nicht liegen, weil - wie ich schrieb - >dieses im normalen Simulator einwandfrei läuft. Nicht unbedingt ein Kriterium. Der Simulator ist kein realer Controller. >Da der JTAG-Debugger an der Programmadresse $FFFF hängenbleibt (siehe >o.g. Beschreibung) ist auch F10 bzw. F11 wirkungslos. Ich meinte von Anfang an mit Einzelschritt durchsteppen. >Hängt das evtl. mit meiner AVR-Studio-Version 4.18 zusammen? >Irgendwo hatte ich gelesen, daß es auch noch eine 4.19-Version gibt. Das ist auch nur 4.18 incl. der Service Packs MfG Spess
PSblnkd schrieb: > Hängt das evtl. mit meiner AVR-Studio-Version 4.18 zusammen? Nein. Ich benutze das seit Jahren. Der hat immer funktioniert. PSblnkd schrieb: > es ist eine Verbindung nSRST-Pin mit /RESET des µC zwingend erforderlich. Laut Doku optional. Ich habe sie immer dran und das hat auch noch nie Probleme bereitet. PSblnkd schrieb: > Wenn über JTAG der Debugger angesprochen wird, liest dieser den > tatsächlich im µC-Flash gespeicherten Maschinen-Code aus. Und da liegt > eben der Hund begraben - offensichtlich findet der JTAGICE-Debugger > nicht das Programmspeicher-Ende, hängt in einer Endlos-Schleife und > springt nicht in den Step-Modus bei Progammspeicher 0. Keine Ahnung, wie du darauf kommst und ob das wirklich so ist. Ich weiss auch nicht, was du da veranstaltest oder versuchst. Aber wenn man in der Menüleiste auf Debug klickt, hat man, abgesehen von den Breakpoints, eine Option. Und das ist "Start Debugging". Und dann passiert das, was ich oben beschrieben habe. Und wenn das nicht passiert ist irgendwas im Eimer. Fehlende Leitung, Kurzschluss, abgekackter Treiber oder sonstwas. Installier' das ganze AVR-Studio nochmal neu. Nicht reparieren sondern erst deinstallieren. Vor allen Dingen den Jungo-Treiber. Damit man zumindest das ausschliessen kann. mfg.
@spess53 Wenn der Debugger schon in der Vorbereitung mit "Start Debugging" offensichtlich in einer Endlosschleife hängt, kommt man an die Einzelschritt-Funktion gar nicht ran. Es ist lediglich "Break" und "Reset" aktiviert, wobei letzteres ohne Wirkung ist. Nur bei "Break" erscheint nach kurzer Zeit das Diassembler-Fenster und Zeilenzeiger ganz unten bei $FFFF. "Stop Debugging" geht natürlich auch... @Thomas Eckmann Hängt möglicherweise die Wirkungslosigkeit von "Reset" mit dem Nichtvorhandenseit der Verbindung nSRST-Pin mit /RESET des µC zusammen? Wie gesagt - ich versuche hier nichts Außergewöhnliches, nur die Debugger-Funktion über JTAG, um die realen Portverhältnisse untersuchen zu können, welche z.B. an der Kommunikation mit einem anderen µC beteiligt sind. Die physische Anschaltung des JTAGICEmkII an das ATmegaEvoBoard muß definitiv i.O. sein, sonst würde auch die Programmer-Funktion des JTAGICEmkII nicht funktionieren. Obwohl in den mir vorliegenden Dokus keine Einschränkungen bzgl. der Code-Quelle zu finden sind, gehe ich davon aus, daß es egal ist, ob diese als C-Code oder Assembler vorliegen. Deinen Tip mit der Neuinstallation vom AVR Studio werde ich versuchen. Auf http://www.atmel.com/tools/STUDIOARCHIVE.aspx stehen auch noch (!) die alten Versionen zur Verfügung. Grüsse aus Berlin PSblnkd
Auf Youtube gibt es Demo-Videos für Anfänger mit ATMEL Debug-Tools. Die sind zwar in Englisch, aber selbst für "Sprachlose" ist deutlich zu erkennen, dass zuerst ein breakpoint gesetzt werden muss, bevor man mit dem debuggen anfängt.
Hi >Auf Youtube gibt es Demo-Videos für Anfänger mit ATMEL Debug-Tools. >Die sind zwar in Englisch, aber selbst für "Sprachlose" ist deutlich zu >erkennen, dass zuerst ein breakpoint gesetzt werden muss, bevor man mit >dem debuggen anfängt. Bei mir funktioniert das mit dem AVR Dragon/AVR ICE MKII problemlos ohne Breakpoint. Also kannst du diese Videos unter Ulk verbuchen. MfG Spess
Ich habe es gefunden! Es lag an dem "ATmegaEvoBoard". Die Stromversorung erfolgt onBord mit Gleichrichter, 10µF-Ladekondensator, 7805 und einem weiteren Siebkondensator 10µF danach. Der Ladekondensator war mit 10µF viel zu klein bemessen, so daß die hohe Ripple-Spannung der 7805 nicht mehr ausregeln konnte. Es wurde ein handelsüblicher Stecker-Trafo 9V/0,5A~ verwendet. Verwunderlich war vor allem die geringe Betriebs-Spannung von wesentlich kleiner als 5V - und das bei einem 7805. Da sollte man doch meinen, dass ein DVM immer etwas in der Nähe von 5,0V anzeigen müßte. Das hat sogar Auswirkung auf eine ganz normale Port-Funktion. Da funktioniert dann nicht einmal mehr ein simple LED-Ausgabe, wenn schon alles andere weggelassen ist! Nachdem der Ladekondensator auf 470µF vergrößert wurde, funktionierte auch der JTAG-Adapter, so wie es sein sollte. Nach "Start Debugging" wird nicht mehr das Diassembler-Fenster aufgerufen, sondern wie beim normalen AVR-Simulator steht nach kurzer Zeit - allerdings ohne Fortschrittsbalken - der gelbe Zeilenzeiger in die Assembler-Quelle auf dem ersten Befehl. In der Regel ist das der erste jmp (oder rjmp) in der Interrupt-Tabelle, welcher bei Reset aufgerufen wird. Die rechte LED im JTAGICEmkII, welche bei der Kommunikation JTAG-Board heftig geblinkt hat, bleibt nun dunkel. Jetzt funktioniert auch "Step" (F11) und "Run" (F5) bis zum nächsten Breakpoint, falls ein solcher gesetzt wurde. Wird die Board-Stromversorgung unterbrochen, verschwindet auch der gelbe Zeilenzeiger. Wird sie wieder hergestellt, ist er auch wieder da - allerdings am Programm-Beginn, weil der ATmega128 ein Reset macht und die Funktionalität dann wieder vorhanden ist. Nun kann ich die eigentliche Aufgabe - die Kommunikation mit einem anderen µC - angehen. Vielen Dank an alle "Problem-Bearbeiter". Grüsse aus Berlin PSblnkd
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.