Hallo, ich habe ein Problem beim on-chip debugging meines Atmega168. Ich habe ein kleines Programm geschrieben und wollte es mittels Dragon debuggen. Wegen einer Fehlermeldung war dies aber nicht möglich. Nach Neustart von AVR-Studio ist es nun leider auch nicht mehr möglich überhaupt auf dem Controller zuzugreifen. Bei "Read Signature" kommt z.Bsp. folgende Fehlermeldung: Setting device parameters:..O.K.! Entering programming mode..FAILED! Leaving programming mode..O.K.! Das eigenartige dabei ist, das in den Fusebits auf einmal SPIEN gelöscht ist. Und SPIEN kann man ja nur über HV oder JTAG löschen. Liest der Dragon das einfach nur falsch aus ? Hat jemand eine Idee, wie ich meinen Controller wieder ansprechen kann ? Michael
Wenn Debugging per dW aktiviert ist, dann funktioniert ISP nicht, weil der Reset-Pin eine andere Funktion bekommen hat. Man muss zuerst mittels dW diesen Debug-Modus wieder beenden.
In verschiedenen Artikel steht, dass man eben nur über Jtag oder HV-Programmierung SPIEN löschen kann, deswegen verwundert mich das ja. Und warum löscht sollte sich in den fusebits was ändern, wenn ich irgenetwas mit den debuggen nicht funktioniert ?
Hi >Hat jemand eine Idee, wie ich meinen Controller wieder ansprechen kann ? Du startest noch mal in den Debugger und schaltest unter Debug->AVR Dragon Options mit Disable DW den AVR wieder in den normalen Betrieb. Dann funktioniert ISP wieder. MfG Spess
@Michael: Ich würde nicht drauf wetten, dass bei nicht funktionierendem ISP die per ISP ausgelesenen Fusebits korrekt angezeigt werden.
spess53 schrieb: > Du startest noch mal in den Debugger und schaltest unter Debug->AVR > > Dragon Options mit Disable DW den AVR wieder in den normalen Betrieb. > > Dann funktioniert ISP wieder. Das habe ich mitr auch gedacht, nur kommt vorher leider schon eine Fehlermeldung, sodass ich den Dragon micht mehr in den Normalbetrieb schalten kann. Der Chip ist anscheinend noch im "Debug-Mode" und lässt sich so eben nicht normal betreiben. Aber wie komme ich da wieder raus ?
Hi >Das habe ich mitr auch gedacht, nur kommt vorher leider schon eine >Fehlermeldung, sodass ich den Dragon micht mehr in den Normalbetrieb >schalten kann. Der Dragon ist manchmal etwas zickig. Im einfachsten Fall hilft es den Dragon mal von der Schaltung und USB zu trennen. MfG Spess
Das hilft leider auch nichts. Im übrigen ist der Dragon auch gar nicht mehr im Debug-Modus. Wenn ich nen anderen Atmega dranhänge, lässt sich auf den ganz normal zugreifen.
Michael schrieb: > Im übrigen ist der Dragon auch gar nicht mehr im Debug-Modus. Es geht nicht um den Modus des Dragon. Sondern um den des AVR. Solange der AVR seinen Reset-Pin als dW-Pin versteht gibt es kein ISP. Nicht mit den Dragon, nicht mit dem STK500 und nicht mit dem AVR-ISP. Wenn du mit dW arbeiten willst, dann wird per ISP der AVR auf dW-Betrieb umgestellt. Von dem Moment an gibt es kein ISP mehr. Rückwärts geht ähnlich einseitig: per dW wird der AVR wieder auf ISP-Betrieb umgestellt und von dem Moment an gibt es kein dW mehr.
Hi >Im übrigen ist der Dragon auch gar nicht mehr im Debug-Modus. Wenn ich >nen anderen Atmega dranhänge, lässt sich auf den ganz normal zugreifen. Der Dragon nicht. Aber wahrscheinlich dein AVR. Was passiert denn, wenn du mit dem ATMega das Debugging startest ('Start Debugging')? MfG Spess
Nur komme ich leider nicht mehr in den dW-Betrieb und kann den Zustand somit auch nicht abschalten. Als Alternative gibt's dann nur HV-Programmierung, oder gibt es noch eine andere Möglichkeit ?
spess53 schrieb: > Der Dragon nicht. Aber wahrscheinlich dein AVR. Was passiert denn, wenn > du mit dem ATMega das Debugging startest ('Start Debugging')? Zuerst sieht es danach aus, als ob es mit den debuugen funktionieren würde, unten erscheint im Textfeld ganz normal "load programming memory...", nach ein paar Sekunden kommt dann leider aber die Fehlermeldung: "Platform has been disconnected, leaving programming mode". Das passiert mir jetzt auch schon beim zweiten Controller. Es muss wohl irgendetwas mit meinen Programm zu tun haben.
Hi >Das passiert mir jetzt auch schon beim zweiten Controller. Es muss wohl >irgendetwas mit meinen Programm zu tun haben. Nicht sehr wahrscheinlich. Der richtige Controller ist eingestellt? Und wie sieht die Beschaltung vom Reset-Pin aus? MfG Spess
Michael schrieb: > Nur komme ich leider nicht mehr in den dW-Betrieb und kann den Zustand > somit auch nicht abschalten. AVRDUDE kann das, das interessiert sich (anders als AVR Studio) nicht für die Vorgeschichte. Du gibst einfach ein normales ISP-Kommando ein, also beispielsweise:
1 | avrdude -p m168 -c dragon_isp -P usb -U hfuse:w:0xdf:m |
AVRDUDE stellt dann fest, dass das Aktivieren des ISP-Modus nicht geht und versucht "im Weggehen" noch, das debugWIRE wieder abzuschalten. Nach dieser Aktion ist man (laut Atmel) ohnehin gezwungen, die Sitzung mit dem JTAG ICE / AVR Dragon zu beenden und neu zu beginnen, was AVRDUDE dadurch erreicht, dass es sich an dieser Stelle beendet. Danach muss man jedoch nur nochmal das gleiche Kommando eingeben (also im cmd.exe oder in der Unix-Shell: einmal <Cursor nach oben>, danach <Enter>), und sofern man zwischendurch nicht am AVR die Spannung abgeschaltet hatte, funktioniert diesmal der ISP-Modus. Obiges genanntes Kommando stellt die high fuse auf den Auslieferungs- zustand zurück, d. h. es wird (u. a.) DWEN abgeschaltet. Der temporäre ISP-Modus bleibt übrigens bis zum nächsten power cycle erhalten, danach wird DWEN neu eingelesen und bewertet, um darüber zu entscheiden, ob debugWIRE zu aktivieren ist oder nicht. Man ist daher keinesfalls gezwungen, in diesem temporären ISP-Modus überhaupt die DWEN-Fuse anzufassen: man kann genausogut einfach ein neues Flash-Image laden, danach einmal "power cycle", und man kann die Debugsitzung fortsetzen. (Geht allerdings vermutlich nicht mit'm AVR Studio, weil das den Zustand "debugWIRE ist schon aktiv" nicht verträgt, sondern diesen Zustand partout selbst herbeigeführt haben will, bevor es damit arbeiten kann.)
spess53 schrieb: > Nicht sehr wahrscheinlich. Der richtige Controller ist eingestellt? > Und wie sieht die Beschaltung vom Reset-Pin aus? Die Beschaltung vom Reset-Pin war falsch, d.h. der 10k Pullpu Widerstand hat gefehlt. Leider ändert es nichts an der Tatsache, dass der Controller nicht ansprchbar ist. Beim Versuch in den Debug-Modus zu wechseln, kommt jetzt aber der Hinweis, dass SPIEN enabled sein muss. Ich lade mir mal den AVRDUDE runter und teste es mal aus, ob es so funktioniert.
Michael schrieb: > Die Beschaltung vom Reset-Pin war falsch, d.h. der 10k Pullpu Widerstand > hat gefehlt. Der Pin hat einen internen Pullup. > Beim Versuch in den Debug-Modus zu > wechseln, kommt jetzt aber der Hinweis, dass SPIEN enabled sein muss. Unsinnige Aussage: wenn ISP nicht geht, lässt sich die Fuse gar nicht lesen, und die nicht (richtig) gelesene Fuse wird dann als deaktiviertes SPIEN misinterpretiert (weil vermutlich die Fuses allesamt als 0xff erscheinen).
Leider kommt folgende Fehlermeldung bei Eingabe von avrdude -p m168 -c dragon_isp -P usb -U hfuse:w:0xdf:m avrdude: usbdev_open(): Did not find any USB device "usb" Ich benutzte die Version avrdude gui v0.2.0. Ich habe bis jetzt leider noch gar nichts mit dem DUDE gemacht. Unterstützt wird der Dragon schon auch unter Windows vom AVRDUDE ?
Michael schrieb: > Leider kommt folgende Fehlermeldung bei Eingabe von > avrdude -p m168 -c dragon_isp -P usb -U hfuse:w:0xdf:m > > avrdude: usbdev_open(): Did not find any USB device "usb" Hast du die Filter-Version der libusb-win32 installiert? > Ich benutzte die Version avrdude gui v0.2.0. Was auch immer das ist. Was spricht dagegen, das AVRDUDE von WinAVR zu benutzen? (Aber auch die bringen den falschen USB-Treiber mit, den Filter-Treiber muss man m. W. dort trotzdem noch separat installieren.)
> > Unsinnige Aussage: wenn ISP nicht geht, lässt sich die Fuse gar nicht > lesen, und die nicht (richtig) gelesene Fuse wird dann als > deaktiviertes SPIEN misinterpretiert (weil vermutlich die Fuses allesamt > als 0xff erscheinen). Beim Versuch in den Debug-Modus zu wechseln erscheint folgende Meldung: " Unable to connect to device. ... For connection issues please press the help button xx Retry debug wire connection xx Use SPI to enable debug Wire interface Beim Anklick von "Retry debug wire connection" tut sich nichts, bei Anklick von "Use SPI to enable debug Wire interface" kommt die Fehlermeldung: Failes to enter SPI mode ... if the SPIEN fuse is not enabled, the part must be programmed using high-voltage.
Michael schrieb: > Beim Anklick von "Retry debug wire connection" tut sich nichts Bist du dir sicher, dass dein debugWIRE jemals funktioniert hat? Nicht, dass du da am /RESET was versaut hast und debugWIRE läuft rein gar nicht. In diesem Falle ist das Setzen der DWEN-Fuse natürlich purer Selbstmord für den Controller.
Jörg Wunsch schrieb: > Was auch immer das ist. Was spricht dagegen, das AVRDUDE von > > WinAVR zu benutzen? (Aber auch die bringen den falschen USB-Treiber > > mit, den Filter-Treiber muss man m. W. dort trotzdem noch separat > > installieren.) avrdude.exe ist unter den Installationspfad von WINAVR installiert. Wenn ich draufklicke erscheint nur kurz ein schwarzes Eingabefeld. Wie kann ich das öffnen ? Und wie kann ich libusb-win32 installieren ? Tut mir Leid um meine blöde Fragen, aber ich kenne mich leider noch nicht so gut aus.
Ich bin zwar selber noch Anfänger ... hatte aber mal ein Problem mit den gleichen Symptomen ... bei mir hatte ich die Fuse für den externen Quarz gesetzt obwohl gar keiner dran war und anschliessend ging garnichts mehr ... musste den ATmega168 tauschen (die Profis hier hätten bestimmt einen Tip gehabt was ich tun kann um den Controller zu retten, da kannte ich das Forum aber noch nicht).
Die fuses sind auf einen externen 8Mhz Quarz gesetzt worden, und es ist auch wirkliche in 8Mhz Quarz angelötet. UART Kommunikation war ja auch einwandfrei möglich. Daran kann's eigentlich nicht liegen.
Michael schrieb: > avrdude.exe ist unter den Installationspfad von WINAVR installiert. Wenn > ich draufklicke erscheint nur kurz ein schwarzes Eingabefeld. Nicht alles im Computerleben lässt sich anklicken. Die Kommandozeile schrob ich ja bereits weiter oben, die man dafür eingeben darf. Damit du das tun kannst, musst du einen Kommando- interpreter laufen haben (cmd.exe, im Windows-Jargon auch fälschlicherweise "MS-DOS-Fenster" genannt, obwohl das seit WinNT mit MS-DOS nichts mehr gemein hat). > Und wie kann ich libusb-win32 installieren ? Indem du den Namen in die Suchmaschine deiner Wahl eintippst, dem ersten Link zu sourceforge.net folgst und dir dort das Paket lädst und installierst, das das Wort "Filter" im Namen hat.
Jörg Wunsch schrieb: > Bist du dir sicher, dass dein debugWIRE jemals funktioniert hat? > > Nicht, dass du da am /RESET was versaut hast und debugWIRE läuft > > rein gar nicht. In diesem Falle ist das Setzen der DWEN-Fuse > > natürlich purer Selbstmord für den Controller. Also egnau genommen, hat die debugWire Funktion auch mit dieser Konstellation funktioniert. Ich habe dW dann nur abgebrochen (so wie es sich gehört, mit Umstellung von DebugWire auf Normalbetrieb unter AVR-Dragon debug options), weil ich am Programm noch was verändern wollte. Beim zweiten mal kam dann eben die Fehlermeldung und SPIEN wird seitdem als disabled angezeigt
Michael schrieb: > Also egnau genommen, hat die debugWire Funktion auch mit dieser > Konstellation funktioniert. OK, deshalb muss sie natürlich nicht zuverlässig funktionieren. Hast du /RESET komplett unbeschaltet gelassen (also direkt zum ISP-Stecker nur), oder hängt da noch was dran? Manchmal hilft es noch, an /RESET einen Pullup von 4,7 kΩ oder 10 kΩ zu klemmen, aber auf keinen Fall dürfen da größere Kapazitäten dran sein. > Beim zweiten mal kam dann eben die Fehlermeldung und SPIEN wird seitdem > als disabled angezeigt Wobei das eben nur eine glorreiche Fehlinterpretation der Tatsache ist, dass man im debugWIRE-Modus die Fuse gar nicht erst gelesen bekommt. Guck dir doch die Fuses mal als Hexcode an statt auf die blöden Checkboxes zu sehen, da steht bestimmt 3 x 0xFF drin.
Hi >Ich habe dW dann nur abgebrochen (so wie es >sich gehört, mit Umstellung von DebugWire auf Normalbetrieb unter >AVR-Dragon debug options), weil ich am Programm noch was verändern >wollte. Es ist wichtig beim Zurückstellen die Meldung:'Platform has been disconnected...' abzuwarten. Zum Ändern des Programms brauchst du nur das Debuggen zu beenden. Rückstellen auf ISP ist nicht notwendig. Das neue Programm wird über DW geladen. MfG Spess
Jörg Wunsch schrieb: > Hast du /RESET komplett unbeschaltet gelassen (also direkt zum > ISP-Stecker nur), oder hängt da noch was dran? Oh Mann, an der Reset Leitung hing noch eine I2C-Device dran. Also jetzt lässt er sich wieder ansprechen ! Danke für eure Hilfe. Mit dem Programm AVR-Brenner (eine Ausführung von AVRDUDE mit grafischer Bedienoberfläche) habe ich auch die fuses ausgelesen, und natürlich ist dort SPIEN gesetzt.
Hallo Jörg, ich habe das gleiche Problem wie Michael, nur kann ich mit AVRDUDE arbeiten und habe ein ATMega88PA. Wenn ich die Commandozeile: avrdude -p m88 -c dragon_isp -P usb -U hfuse:w:0xdf:m eingebe, erhalte ich folgende Meldung: : jtagmkII_setparm(): bad response to set parameter command: RSP_FAILED : jtagmkII_getsync(): ISP activation failed, trying debugWire : Target prepared for ISP, signed off. : Please restart without power-cycling the target. Wenn ich im DW Modus versuche zu schreiben kommt folgendes heraus. C:\WinAVR-20100110\avrdude-5.10>avrdude -p m88 -c dragon_dw -P usb -U hfuse:w:0xdf:m avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.02s avrdude: Device signature = 0x1e930f avrdude: reading input file "0xdf" avrdude: writing hfuse (1 bytes): Writing | | 0% 0.00s ***failed; Writing | ################################################## | 100% 0.00s avrdude: 1 bytes of hfuse written avrdude: verifying hfuse memory against 0xdf: avrdude: load data hfuse data from input file 0xdf: avrdude: input file 0xdf contains 1 bytes avrdude: reading on-chip hfuse data: Reading | | 0% 0.00savr_read(): error reading address 0x0000 read operation not supported for memory "hfuse" avrdude: failed to read all of hfuse memory, rc=-2 avrdude done. Thank you. Wie komme ich hier weiter? Am Reset sind nur 10k, sonst nichts. Debuggen geht auch einwandfrei. VG Stefan
Ich habe nun die Problemlösung gefunden.
Es hängt mit dem neuen Update auf den Dragon zusammen.
Wenn es hat funktioniert die DWEN zu deaktivieren, nachdem ich auf eine
externe Spannungsversorgung umgestellt habe.
There's a bug either in AVRS5 or in the new Dragon firmware which it
bundles and requires. It manifests while you try to use debugWire with a
target circuit powered by a Dragon's Vout connector. The problem is, the
Dragon is cycling its power output after leaving debugWire session
("Disable debugWire and close") which undoes the temporary disarm of the
DWEN fuse which, in turn, makes re-enabling the SPI functionality
virtually impossible without resorting to the not yet supported in AVRS5
parallel programming (well, to me at least). The problem disappeared
after I connected an external power source to my target board. Now after
leaving the dW session, SPI is properly restored automatically
VG Stefan
Stefan Rau schrieb: > Hallo Jörg, Sorry, lese ich jetzt erst. > Wenn ich die Commandozeile: > > avrdude -p m88 -c dragon_isp -P usb -U hfuse:w:0xdf:m > eingebe, erhalte ich folgende Meldung: > : jtagmkII_setparm(): bad response to set parameter command: RSP_FAILED > : jtagmkII_getsync(): ISP activation failed, trying debugWire > : Target prepared for ISP, signed off. > : Please restart without power-cycling the target. Ist doch OK. Hast du die letzte Zeile beherzigt? "Please restart without power-cycling the target." Du sollst also bitteschön das exakt gleiche Kommando nochmal absetzen. <Cursor nach oben>, <Enter>, fertisch. > Wenn ich im DW Modus versuche zu schreiben kommt folgendes heraus. Mist, logisch. Stell dir den debugWIRE-Modus vor wie ein Stück fest eingebrannte Firmware: mehr als das, was du aus einer Firmware zugreifen kannst, kann auch der debugWIRE-Modus nicht. Breakpoints macht der, indem die ganze Flash-Page neu geschrieben wird (bzw. organisiert das JTAG ICE dieses) und dabei ein BREAK-Befehl eingetragen wird. Was man von Firmware aus nicht erreichen kann, kann auch debugWIRE nicht, und insbesondere gehört dazu, dass man keine Fuses schreiben kann. Eigentlich ist debugWIRE weiter nichts als ein sogenanntes Monitor- Programm, wie es früher auf Microcomputern gang und gäbe war. Daher hieß das Teil ursprünglich auch "MonCon", den letzten Rest davon siehst du in der Appnote AVR067 im Kommando "Reset w/ MonCon disabled", das ist nämlich genau das, was man hier braucht, um aus debugWIRE zurück zu kommen: einen MCU-Reset, nachdem debugWIRE nicht mehr aktiv ist, sodass das /RESET-Pin danach für den ISP-Algorithmus wieder frei ist. Dummerweise ist das von Seiten des JTAG ICE so organisiert, dass man sich nach diesem Kommando zwingend vom ICE abmelden und neu dort anmelden muss. Das ist der wesentliche Grund, warum ich das in AVRDUDE so implementiert habe, dass sich dieses normal beendet und du es von der Kommandozeile neu aufrufen musst. Das war deutlich einfacher zu realisieren, als die Mimik zum Ab- und Wiederanmelden da noch nachträglich ins AVRDUDE zu zimmern (das meldet sich ansonsten immer genau einmal an und einmal am Ende ab).
Hallo Jörg, vielen Dank für Deine späte Nachricht. Ich hatte schon befürchtet Du ignorierst mich...:-( Ich habe das Problem gelöst siehe Beitrag vor Deinem.. Danke Stefan
Sehr hilfreich! Hätte ich auch selbst drauf kommen können. Dafür weiß ich nun, dass doch nichts mit dem Adapter ist. Andere Sache: Mit dem ATTiny13A komme ich nicht wieder in den ISP Modus (Atmel Studio 6). Hab das mit meinen beiden Drachen und mehreren Tinys probiert. Am Speicher kann es meines Erachtens auch nicht liegen, da ich nur diesen übliche "Blinkdings" (allerdings auf dem ganzen PortB) laufen ließ. Für mich nicht schlimm und wer nen Drachen hat, für den kein Problem. Dann kommt halt der HVSP Modus zum Einsatz, wenn man das wieder umstellen möchte. Nur so als Hinweis für diejenigen, die auch mal darüber stolpern.
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.