mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wie debugt ihr mit einem ATmega88 und AVRStudio/WinAVR


Autor: M.B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie schon geschrieben.

Wie debugt Ihr euren ATmega mit AVRStudio? Wie seht ihr, was im 
Prozessor "abgeht"? Ich möchte nicht simulieren, sondern auslesen welche 
Variablen welche Werte haben.

Gibts einen Artikel oder eine Anleitung hierrüber?

Bisher habe ich mir solche Sachen über ein LCD ausgegeben, aber leider 
ist nun mein LCD kaputt und ohne Umwege habe ich auch keine Pins mehr 
frei am µC.

Ich habe ein STK500 und ein AVRISPmkII zur Verfügung.

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus,

debugge mit dem AVR - Dragon, bin damit mehr als zufrieden und ich denke 
für den Hobby - Bereich mehr als ausreichend.
Ist auch relative Günstig, für das was es kann.


Gruss

Autor: M.B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Info. Gibt es eine Anleitung für den Dragon oder wo muss 
ich nachschauen? AVRstudio? oder ist beim dragon eine dabei?

Autor: M.B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ist auch immer die Rede vom debugWire - wie muss ich mir das 
vorstellen? Wird da ein Pin "geopfert" für die Debug-Information?

Autor: Fabian B. (fabs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, der Reset-Pin wird dafür verwendet. Mit dem Dragon oder dem 
ICE-MKII geht das wunderbar.

Gruß
Fabian

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wie seht ihr, was im Prozessor "abgeht"?

Simulieren, mit VMLAB. Zum Verständnis, was der Prozessor tatsächlich 
macht, ist das genial.

Leider nicht ganz fehlerfrei, dafür kostenlos.

Oliver

Autor: M.B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ich hab mir nun den Dragon besorgt. Vielleicht kann mal jemand, der 
den Dragon kennt und benutzt, sagen wie der Ablauf ist. Weil ich mir 
nicht sicher bin wie ich mit der Fuse umgehen soll:

Ich habe das Dragon.Board mit USB verbunden und wird im Studio erkannt. 
Es ist als Debug-Plattform angegeben.
Nun habe ich meinen Controller (mega88) auf einer platine eingebaut, 
dort ist habe ich eine ISP Schnittstelle.

Nun zur Vorgehensweise:
Ich habe die Connections auf dem dragon-Board geprüft und nun die 
ISP-Schnittstelle (Dragon-Board) mit der ISP-Schnittstelle (Anwendung) 
verbunden.

Jetzt müsste oder sollte ich die Fuse dwen setzen.

Bevor ich das mache, wie kann ich die wieder zurücksetzen, da ja dann 
der Reset-Eingang "außer Funktion" ist.

Wie kann ich dann meinen Prozessor wieder programmieren? Geht das auc 
über das Dragon-Board?

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Gibt es eine Anleitung für den Dragon oder wo muss ich nachschauen?

Gibt es auf Deinem Rechner. In AVR-Studio gibt es einen Menüpunkt namens 
"Help". Dort werden auch alle Tools beschrieben, die das AVR-Studio 
unterstützt, also auch der Dragon. Der Dragon selbst wird ohne 
Dokumentation ausgeliefert.

> Bisher habe ich mir solche Sachen über ein LCD ausgegeben, aber leider
> ist nun mein LCD kaputt ...

Bei Pollin gibt es gut verwendbare LCDs zu Preisen ab 2 Euro. Das sind 
zwar Industrie-Restposten, aber neu (im Sinne von unbenutzt) und 
erstklassige Qualität.

Viele Leute debuggen auch über UART, dazu ist aber ein 
baudratentauglicher Quarz ratsam. Mir reicht zum Debuggen oftmals eine 
LED, die ich an bestimmten Stellen ein/aus-schalte oder ein PWM-Pin, an 
dem ich mittels Multimeter den Tastgrad ablesen kann. Natürlich nutze 
ich auch gern ein LCD zum Debuggen, aber manche Schaltungen arbeiten 
nunmal ohne LCD auf kleinen Tinies... ;-)

...

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ..., sagen wie der Ablauf ist.

- Dragon als ISP-Programmer connecten
- DWEN-Fuse aktivieren
- Dragon als ISP disconnecten
- Debugger hochfahren, dabei statt Simulator den Dragon auswählen
- AVR-Typ auswählen
- Debuggen wie im Simulator üblich (Haltepunkte, Einzelschritte,
  Watch...)
- Im Debugger DWEN-Fuse wieder deaktivieren, um ISP wieder zu 
ermöglichen

Musst mal ein bissel durch die Menüs blättern, AVR-Studio kann bedeutend 
mehr, als ein Gamekid mit der Maus anklicken kann.

...

Autor: M.B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank Hannes!!!!!

Dann kann ich die Fuse also aktivieren!

Zum Verständnis:

Im "Debug-Modus" kann ich über ISP nicht umprogrammieren (auch nicht mit 
z.B. STK). Dafür muss ich immer erst die Fuse wieder zurücksetzen.

Autor: M.B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das habe ich geahnt:
Ich bekomme keine debugWire Connection!
Ich habe zunächst ein 6-pol ISP Kabel vom Dragon zur Anwendug gesteckt - 
keine Verbindung!
Ich habe danach die Stecker einzeln gesteckt und bin mit VCC vom Dragon 
zur ISP Dragon und zur ISP Anwendung. die restlichen Leitungen 
(insbesondere GND und Reset) direkt zwische ISP und ISP.
Auf meinem Dragon-Board leuchtet eine schmale grüne LED und die 4-Pin 
LED leuchtet rot.
Die Stromversorgung habe ich einmal über USB geholt und auch einmal mit 
zusätzlich eingeschalteter Stromversorgung von der Anwendung.

Was gibts noch zu beachten? In der Beschreibung / Hilfe habe ich bisher 
noch nichts gefunden.

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Reset - Jumper auf dem STK500 muss entfernt werden. Dann sollte es 
gehen, wenn du alles in AVRStudio eingestellt hast.

Autor: M.B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jim: IOch arbeite in der Anwendung nicht mit STK500

Aber ich habe das Problem nun gelöst:

Ich hatte den Reset-PIN in der Anwendung mit einem 100nF und 10k und 
einer Diode beschaltet. NAchdem ich nach und nach alles ausgelötet habe 
funktionierts - Gott sei dank!

Also debug-Wire Modus funktioniert bei mir bei Nichtbeschaltung des 
Reset-Pins.

Danke hier ans Forum für die vielen Infos...

Autor: Fabian B. (fabs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt nicht ganz, am Reset darf kein C sein und ein R mit max 10k oder 
so... steht aber in der Anwendungsanleitung zu DBWire im 
Controllerdatenblatt.

Diese Resetbeschaltung ist in Testanwendungen meist sowieso nicht 
notwendig.

Gruß
Fabian

Autor: M.B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt nicht ganz...:

Hier in der Beschreibung:
Problem: Not able to communicate with device through debugWIRE
Reason: RESET pullup resistor to small
Solution: Remove or increase the pull-up value to 10K ohm or more.

Scheinbar hatte bei mir aber zusätzlich noch die Diode gestört. Obwohl c 
und r weg waren ging es immer noch nicht.

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

es ist ein fitzelchen ab vom Thema aber ich versuch's trotzdem:

ich arbeite ebenfalls mit ATMega88 bzw. ATMega168 und AvrDragon. Wie in 
http://www.avrfreaks.net/index.php?name=PNphpBB2&f... 
besprochen, haben einige Leute (dummerweise auch ich) Probleme bei 
Prozessorfrequenzen >1MHz (Fuse CLK/8 disabled). Ich habe es gestern 
noch ausprobiert: Alle Typen die mir zur Verfügung stehen 
(ATMega48/ATMega88/ATMega168) krachen meist schon beim flashen - 
spätestens aber nach den ersten Single-Step-Schritten mit der 
Fehlermeldung derart, dass die Hardware nicht mehr reagiert und die 
Debugsitzung abgebrochen wird.

Wie sieht das bei Euch aus? Ich frage deshalb: Bin immer noch auf der 
Suche, was ich falsch mache (RESET/dW ist bei mir nur mit dem Dragon 
verbunden). Diejenigen, die keine Probleme haben: Welche Firmware habt 
Ihr auf dem Dragon und wo ist der Dragon angeschlossen (direkt am PC 
oder Hub evt. fremd versorgt?).

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich hatte den Reset-PIN in der Anwendung mit einem 100nF und 10k und
> einer Diode beschaltet.

Dies ist ein alter Zopf aus der Zeit der Classic-AVRs als billiger 
Ersatz für einen externen BrownOut-Baustein. Seit die AVRs einen 
internen BrownOut-Detektor haben, brauct man sowas nicht mehr, im 
Gegenteil, es ist sogar störend. Ich beschalte Reset nur mit einem 
PullUp-Widerstand. Vor DW war es 3k9..4k7, jetzt ist es meist gut 10k 
(11k5, weil ich davon eine ganze Rolle habe).

> Probleme bei Prozessorfrequenzen >1MHz

Kann ich nicht nachvollziehen. Ich muss aber gestehen, dass ich den 
Dragon nur selten als Debugger nutze. Und da ich in ASM programmiere 
genügt mir meist auch der 1MHz-Takt.

...

Autor: M.B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zusatz:

Welche ISP-Frequenz für Dragon-Betrieb hat sich als gut erwiesen? Bei 
mir hakt es schon mal mit dem debug-Modus.

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Immer ruhig und gediegen, 1/8 MHz reicht völlig zu. Man muss nicht immer 
am Limit arbeiten.

Es kann durchaus sein, dass Deine Anschließerei nicht ganz korrekt ist, 
schau mal in der Hilfe zum Dragon nach, da gibt es eine Liste der 
unterstützten AVR-Typen mit Links zu Anschluss-Schaltbildern für die 
jeweils unterstützten Betriebsarten.

...

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Immer ruhig und gediegen, 1/8 MHz reicht völlig zu. Man muss nicht immer
>am Limit arbeiten.

Richtig. Deswegen habe ich mich bisher ruhig gehalten. Ich habe aber 
jetzt eine Anwendung, bei der ich hoch auflösende Timer und schnelle 
Interrupt-Antwortzeiten brauche.

Da ich bei meinen Prototypen mit DIL Gehäusen arbeite, habe ich mir 
Adapter gebaut. Wenn ich die von dem Rest der Schaltung trenne, habe 
ich:
GND, VTref(verbunden mit Vcc) und RESET sonst nix. Auch dabei kommt es 
sehr schnell zu Fehlern. Wie (vielleicht noch nicht) gesagt: Mit CLKDIV8 
/ 1MHz kann ich debuggen bis der Arzt kommt.

Der einzige Fehler, den ich 1-2* pro Tag bekomme ist, dass nach einer 
Debug Sitzung der Dragon nicht mehr korrekt erkannt wird. Da kann ich 
mir aber behelfen, indem ich
- den Dragon abklemme
- beim Windows-Geräte-Manager das Device Jungo/WinDriver deaktiviere und 
wieder aktiviere
- den Dragon wieder anklemme

Autor: Martin Vogel (oldmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Auch ich kenne das Problem, nicht immer zu wissen, wo meine Fehler sind. 
Daher habe ich mir ein kleines Programm auf dem PC geschrieben, welches 
die Variablen über die serielle Schnittstelle des MC ausliest 
(Momentaufnahme oder alle 100 ms). Da ich das Pollin - Board benutze, 
ist das kein allzugroßes Problem. Die serielle Verbindung brauche ich 
sowieso, und daher ist der zusätzliche Aufwand im MC gering. Falls 
Interesse besteht, kann ich die SW gern zur Verfügung stellen. Ist nix 
besonderes, daher stellt keine zu großen Erwartungen....
Gruß oldmax

Autor: Martin Vogel (oldmax)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Ich hab das Programm gestern nochmal etwas überarbeitet und stelle es 
nun zur Verfügung. Es besteht aus einer Dokumentation in Word und einem 
kleinen Programm zur seriellen Kopplung mit einem Controler. Das 
Programm ist ausgelegt für Programmierung in Assembler, kann aber auch 
für andere Sprachen genutzt werden.
Falls Fragen sind, laßt es mich wissen.
Gruß oldmax

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.