Hallo! Hab heute das Experiment gewagt meinen ATiny13 mit dem AVR-Dragon über DebugWire zu debuggen. Die sache war auch erfolgreich aber wie zum Teufel bekomme ich den jetzt wieder in den normal Zustand, so das er wieder über ISP programmiert werden kann? Kennt sich jemand damit aus?
Klaus schrieb: > Kennt sich jemand damit aus? Ja sicher kennt sich jemand damit aus. Blättere mal im Debugger durch das Menü, da findest Du sicher einen Punkt zum Deaktivieren der DWEN-Fuse. Danach kannst Du den Tiny13 wieder mit ISP ansprechen. ...
@Hannes Lux Danke! Aber leider scheint was nicht zu stimmen. Wenn ich den ATiny über die ISP Anspreche kommt imme Read Fuses filed. Was nu?
Hi
>Wenn ich den ATiny über die ISP Anspreche kommt imme Read Fuses filed.
Kannst du auch nicht solange DW aktiviert ist. Zum Abschalten musst du
den Debugger noch mal starten. Dann findest du unter Debug->AVR Dragon
Options einen Button 'Disable Debugwire'. Damit dann DW deaktivieren.
MfG Spess
@Spess 'Disable Debugwire' hab ich gefunden hat auch funktioniert! Danach wollte ich über ISP programmieren aber irgendwie ist der jetzt nicht ansprechbar. Kann es sein das man den HVP wieder zum leben erwecken muss? Aber wie? Wie sieht die Beschaltung dann aus AVR-Dragon --> Atiny13 und zwar so das mir der Drafon icht draufgeht.
Hi >Danach wollte ich über ISP programmieren aber irgendwie ist der jetzt >nicht ansprechbar. Der Dragon reagiert manchmal etwas zickig. Trenne mal deine Schaltung von der Stromversorgung und den Dragon vom USB. MfG Spess
@Spess! Wie vorgeschlagen die den Atinny getrennt und Stromversorgung USB! Leider kommt nach dem wieder anschliessen die gleiche Meldung. "Reading fuses failed."
@Spess! Ich muss dazu sagen das Der Atinny direkt verbunden ist über s.g. grabbers.
Hi Kommst du noch in den Debug-Mode? MfG Spess
Debug->"Start debugging and Break" dann nicht starten sondern Debug->Disable DebugWire(oder so ähnlich hab grade meinen Dragon nicht da) dann müsste der Dragon sich ein paar mal aktivieren und deaktivieren und dann müsste es eigentlich wieder gehen. Gruß Matthias
@Stone Das gebimmel also Abmelden, Anmelden tut auch so weit aber irgend scheint mir der ATiny verfust zu sein.
Ja, dass gebimmel. Ehm meckert er irgendwas oder führt er das ohne murren aus? Hab mir auch schon öfter gedacht das ich jetzt einen mit Debugwire zerlegt habe aber irgendwie hat er sich immer wieder gefangen. Nimm auch mal den Attiny komplett von Strom, Dragon ISP abstecken und dann nochmal versuchen. Gruß Matthias
@Matthias Ja am schluss kam ein fehler: Vllt. hilft das weiter! Failed to read fuse register. However, Debugwire was temporarily disabled. Cycle target power and restart debug session to continue. Timestamp: 2011-12-28 10:58:20.755 Severity: ERROR ComponentId: 20100 StatusCode: 0 Programming session setup failed: TCF command: Device:startSession failed: Code:1 ,Service: ,Message from peer:Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00
Nur mal als Hintergrundinfo, wie das mit dem debugWIRE funktioniert: Aktiviert wird es durch Setzen der DWEN-Fuse. Danach hat der /RESET-Pin die Funktion "debugWIRE" und steht nicht mehr als Reset zur Verfügung. Daher geht ab diesem Moment auch kein ISP mehr. Das ist insofern kritisch, als dass man vor dem Aktivieren von DWEN noch gar nicht weiß, ob das Setup überhaupt debugWIRE-tauglich ist, man danach aber zwingend ein funktionierendes debugWIRE (oder HV-Programmierung) benötigt, um es wieder zu deaktivieren. Das Deaktivieren geschieht in zwei Stufen. Die erste läuft über debugWIRE selbst und aktiviert vorübergehend (bis zum nächsten power cycle) den /RESET-Pin wieder als solchen. Danach kann man folglich wieder ISP machen, und im ISP-Modus kommt man an die Fuses ran. Programmiert man die Fuses nicht um, ist man nach dem nächsten power cycle wieder im debugWIRE-Modus, denn da wird dann die DWEN-Fuse neu bewertet. debugWIRE selbst ist nur eine Art fest eingebautes Monitor-Programm, daher kann es nur auf Dinge zugreifen, die die CPU zugreifen darf. Aus diesem Grunde lassen sich im debugWIRE-Modus die Fuses nicht programmieren. Sorry, mit deinem AVR-Studio-Problem kann ich dir nicht helfen, da ich das nicht benutze.
Also die sache liegt wohl darin das der DebugWire nicht zurück gesetzt wird, weil AVR-Studio 5 probleme mit dem ändern der Fuses hat. Naja zumindestens kann ich noch debuggen: lol.
Juuhuuu! So mit Studio 4 und älterer Version der AVR-Dragon-Firmware hatt es doch noch geklappt. Hab da DW-Modus gestartet und gleich danach DW-Disablet ohne Fehlermeldung sondern das es erfolgreich war. Danach hab ich über die ISP erst eine READ der Fuses ausgeführt und für gut befunden und wieder zurück geschrieben. Jetzt ist der ATiny13 wieder am leben. Ich bedanke mich für eure hilfe. Gruß Klaus
Klaus schrieb: > Also die sache liegt wohl darin das der DebugWire nicht zurück gesetzt > wird, weil AVR-Studio 5 probleme mit dem ändern der Fuses hat. Nochmal: debugWIRE zurücksetzen ist das eine, die Fuses zurücksetzen ist eine andere Geschichte. Beides ist voneinander entkoppelt. Nach dem Rücksetzen des debugWIRE-Modus kann man bis zum nächsten power cycle erst einmal wieder ISP ganz normal machen, und erst in diesem ISP-Modus kann man sich dann an den Fuses schaffen. Wird dein ATtiny13 eventuell vom Dragon mit Betriebsspannung versorgt? Falls AVR STudio 5 nach dem Rücksetzen des debugWIRE-Modus zufällig den Dragon vom USB abmeldet (so, wie ich das derzeit bei AVRDUDE auch mache), dann bricht in diesem Moment die Spannungsversorgung des target-AVRs zusammen. Damit hat dieser sofort wieder einen power cycle, der dann dazu führt, dass die DWEN-Fuse neu eingelesen wird. Bei AVRDUDE muss ich dafür noch was ändern (es gibt irgendwo schon einen Patch), falls das bei AVR Studio auch der Fall ist, solltest du wohl Atmel einen Bugreport schreiben. Workaround: externe Versorgung des target-AVRs bei Betrieb mit debugWIRE.
Eh, welche Version vom AVR Studio 5 verwendest du? Eine der ersten Betas hatte da Probleme bei der 5.0.1163 geht das eigentlich problemlos. Gruß Matthias
Hi! Jörg Wunsch hat recht! >Wird dein ATtiny13 eventuell vom Dragon mit Betriebsspannung versorgt? JA! Wurde so versorgt. >Workaround: externe Versorgung des Target-AVRs bei Betrieb mit debugWIRE. Also die esterne Versorgung ist bei AVR-Studio 5 auf jedenfall zwingend. Das mit der externen Stromversorgung habe ich die ganze Zeit Ignoriert, weil es ja in AVR-Studio 4 noch ging. Ich habe die Beta Version von AVR-STudio 5 durch den Release ersetzt und kann bestätigen, das beim Betrieb vom DebudWire eine externe Stromversorgung notwendig ist. Sonst wird tatsächlich die Verbindung Unterbrochen,weil der USB Port zwischen abgeschaltet wird warum auch immer! Danke! Jörg
Klaus schrieb: > weil der USB Port zwischen abgeschaltet wird warum auch > immer! Nach dem Umschalten des target-AVRs vom debugWIRE-Modus weg ist es Vorschrift (von Atmel), dass man die Emulator-Sitzung neu aufbaut. Da es schon immer so vorgeschrieben war, habe ich das auch im AVRDUDE erzwungen, indem ich danach das aktuelle Kommando beende und den Nutzer auffordere, das gleiche Kommando nochmal einzugeben (denn das ist auf der Kommandozeile ganz einfach). Durch das Beenden der Emulator-Sitzung melden sich JTAGICEmkII oder AVR DRagon vom USB ab und neu an. Daraus entsteht oben genanntes Problem, auf das mich dann irgendwann AVRDUDE-Nutzer hingewiesen haben. Da es irgendwo einen Patch gibt, mit dem es problemlos klappt, scheint es gar nicht so essenziell zu sein, dass man die Sitzung wirklich beendet (wie eigentlich von Atmel vorgeschrieben), und wenn das mit AVR Studio 4 noch anders war, dann haben sie sich ja offenbar nicht an ihre eigene Vorschrift gehalten. ;-) Ich würde trotzdem einen Bugreport an Atmel schreiben an deiner Stelle.
Hallo, Wie währe es denn dann, wenn wir gemeinschaftlich einen Bugreport an Atmel schreiben? Ist doch sonst etwas lästig. :S Gruß Jannis
Jannis C. schrieb: > Wie währe es denn dann, wenn wir gemeinschaftlich einen Bugreport an > Atmel schreiben? Ich habe kein Windows und daher kein AVR Studio. Damit habe ich keinen Grund für den Bugreport.
Naja, aber der Rest der Dragon-Nutzer, die auch das Studio verwenden, währe es aber sinnvoll. Gruß Jannis
Jannis C. schrieb: > Naja, aber der Rest der Dragon-Nutzer, die auch das Studio verwenden, > währe es aber sinnvoll. Ja, es kann ja ruhig jeder einen Bericht schreiben, der das Problem auch hat. Aber ich kann schlecht einen Bugreport für etwas schreiben, das mir gar nicht passiert ist.
Jörg Wunsch schrieb: > Aber ich kann schlecht einen Bugreport für etwas > schreiben, das mir gar nicht passiert ist. Ich auch nicht, denn unter AVR-Stusio 4.15 funktioniert der Dragon einwandfrei. Und derzeit sehe ich keinen Grund für ein Update. ...
Hannes Lux schrieb: > funktioniert der Dragon > einwandfrei Nitpicking: "der Dragon" funktioniert auch sonst einwandfrei. ;-) Es ist ja lediglich die Konstellation "debugWIRE && target is Dragon- powered", die ein Problem bereitet.
Jörg Wunsch schrieb: > Es > ist ja lediglich die Konstellation "debugWIRE && target is Dragon- > powered", die ein Problem bereitet. Habe ich auch schon gemacht, dabei aber (in AS4) kein Problem festgestellt. Ich kann auch nicht nachvollziehen, dass das Deaktivieren des DW-Modus im Debugger die DW-Fuse nicht zurücksetzen soll. Ich will mich da aber nicht streiten, dazu habe ich den Debugger zu selten benutzt. ...
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.