Hallo, bei dem Versuch einen ATtiny13 in den DebugWire Modus zu bringen, bekomme ich die angehängte Fehlermeldung. Das Atmel Studio 6 (Version: 6.1.2730 - Service Pack 2) läuft dabei in einer VirtualBox unter Ubuntu und ist mit einem JTAGICE MK2 über USB (laptop) verbunden. Flashen, Fuses lesen/schreiben etc. über ISP funktioniert. OS ist winXP, gemeldet als: --------------------------------------------------------- OS Version: Microsoft Windows NT 5.1.2600 Service Pack 3 Platform: Win32NT Installed Packages: Shell VSIX manifest - 6.1 Shell VSIX manifest Version: 6.1 Package GUID: 5aa6ea3e-da7b-48c1-9b2a-cab2329d32ac Company: Atmel Corporation Installed Packages: Atmel Gallery - 1.3.1 Atmel Gallery Version: 1.3.1 Package GUID: AtmelStudioExtensionManager Company: Atmel Installed Packages: Atmel Kits - 1.2.147 Atmel Kits Version: 1.2.147 Package GUID: bea809ab-462e-4535-99f1-3f9ced2f09ff Company: Atmel Installed Packages: AtmelToolchainProvider - 6.1.0.447 AtmelToolchainProvider Version: 6.1.0.447 Package GUID: AtmelToolchainProvider.Atmel.83804b14-6626-4e13-bfdc-3a0135fa98f1 Company: Atmel Installed Packages: Visual Assist X for Atmel Studio - 10.7.1930.2 Visual Assist X for Atmel Studio Version: 10.7.1930.2 Package GUID: 7997A33C-B154-4b75-B2AC658CD58C9510 Company: Whole Tomato Software --------------------------------------------------------- Ich würde nun gern mit DebugWire debuggen, bekomme aber bei "Start debugging and break" nur die Meldung s.A. Reset-Leitung ist frei, Takt intern (Auslieferungszustand) joh
Angehängte Dateien:
-
DW-Problem_1.png
41 KB
DWEN Fuse gesetzt? Pullup an Reset 10 - 20 KOhm? ... (Datenblatt Kap. 15 gelesen ... ?)
Dieter F. schrieb: > DWEN Fuse gesetzt? ich habs mit und ohne programmierter DWEN Fuse probiert, gleiche Fehlermeldung. Nur das ich 2 13er mit programmierter DWEN Fuse jetzt nicht mehr zurück zu ISP bekomme... > Pullup an Reset 10 - 20 KOhm? ja. Leitungslänge alles original Atmel max 20cm. > ... > > (Datenblatt Kap. 15 gelesen ... ?) ja, das war die Basis
neuer PIC Freund schrieb im Beitrag #4233730: > Bei Rev.B niemals SUT auf 0 setzen. So wird ein OTP daraus. ?? Rev.B wovon? und woran siehst Du einen auf 0 gesetzten SUT?
Hat mich jetzt interessiert, da ich auf einem Tiny13 noch nie ein Debugging gemacht habe (und schon gar nicht mit debug wire). 2 Tinys habe ich jetzt auch schon dem direkten Zugriff entzogen :-( Fehlermeldung bekomme ich keine, kann auch das Debugging starten (und werde gefragt, ob ich im SPI-Modus DWEN setzen möchte). Dat tue ich ... Ich komme dann auch ins Debugging - kann aber den Debug-Modus des Tiny13 nicht mehr beenden (Menu - Debug - Disable debugWire and Close). Nutze Atmel Studio 6.2 und einen JTAGICE-Clon. Ich spiele später nochmal weiter (habe noch ein paar Tiny13)
Also - funktioniert jetzt bei mir. Auslieferungszustand - ABER CH8DIV-Fuse deaktiviert. Dann geht alles wunderbar - bei mir zumindest. Man muss das Debuggen aber mit o.g. Menu-Punkt beenden. Nach Aktivieren der Fuse startet der Tiny13 nur noch im Debug-Mode - erst durch das ausschalten im Debug-Menu kann er wieder normal genutzt werden. Geht aber auch nach Restart wieder aus dem debuggen heraus. UND ich habe den Pullup (lt. debug wire Hinweis https://www.mikrocontroller.net/articles/DebugWIRE) auf 4,7 KOhm gesetzt. Für die beiden "Opfer" werde ich wohl mal einen "high voltage programmer" basteln. Wollte ich sowieso schon immer mal ... PS: Lt. errata muss man bei debug wire immer die höchste Start-Wartezeit fusen (ist im AUslieferungszustand so) - daher kam ich auf die Idee, auch mal die CH8DIV-Fuse auszuschalten.
Und - funktioniert es bei Dir (mit vorgenannten Anpassungen) auch?
Dieter F. schrieb: > Also - funktioniert jetzt bei mir. > > ... > Für die beiden "Opfer" werde ich wohl mal einen "high voltage > programmer" basteln. Wollte ich sowieso schon immer mal ... > dazu würde mich jetzt auch mal ein link oder eine Kaufempfehlung interessieren, ich habe auch den dritten und letzten meiner tiny13 ent-ISP'et. Damit ist nun erst mal Schluß mit probieren.
Das http://homepage.hispeed.ch/peterfleury/avr-hvsp-fuse-restore.html dürfte der einfachste für den Tiny13 sein. Da geht auch Steckbrett :-) Da habe ich den Link her https://www.mikrocontroller.net/articles/AVR_HV-Programmer und dort gibt es auch noch mehr
Die Lösung von P. Fleury funktioniert prima - meine Tiny13 melden sich wieder :-)
Dieter F. schrieb: > Und - funktioniert es bei Dir (mit vorgenannten Anpassungen) auch? nein, sowohl mit als auch ohne CKDIV8 fuse bei SUT_CKSEL: INTRCOSC_4MHZ8_14CK_64MS lässt sich der DW nicht einschalten: das Studio (extra auf 6.2 upgedatet) fragt erst, ob es die DWEN brennen soll (bejaht) und fordert dann zum cyclen der targetpower auf. Danach ist Ruhe, Meldung ist: ------ Failed to enable DM: Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00 (Command has failed to execute on the tool) ------ joh Danke für den Tip mit dem Fleuromat, der funktioniert :)
Probier mal den ATtiny13A. Hatte auch schon mal das "A" unterschlagen und debugwire versteht dabei kein Spaß. Fehlermeldung wie bei dir. Erst setzten der DW-Fuse, danach Ruhe. Got 0xC0 heisst wohlmöglich "dw on". Neues Projekt erstellt, derselbe Prozessor als A-Version. Und schon lief dW. Insofern wieder pfui Atmel, wenn der Debugger nicht mal die uc identifizieren kann und der User mit so tollen Fehlermeldungen beglückt wird.
danke für den Gedanke. Neues Projekt mit tiny13 A angelegt, aber DW will weiterhin nicht :( ich gebe hier erstmal auf und debugge halt mit Porttogglern weiter. Gruß joh
Jörg H. schrieb: > SUT_CKSEL: INTRCOSC_4MHZ8_14CK_64MS Standard ist aber 9MHZ6_14CK_64MS mit aktivierter CK8DIV-Fuse. Wenn ich bei dieser Einstellung die CK8DIV-Fuse abschalte funktioniert das debuggen bei mir. Tiny13A habe ich nicht probiert - es funktioniert mit dem "normalen" Tiny13.
Dieter F. schrieb: > Jörg H. schrieb: >> SUT_CKSEL: INTRCOSC_4MHZ8_14CK_64MS > > Standard ist aber 9MHZ6_14CK_64MS mit aktivierter CK8DIV-Fuse. Wenn > ich bei dieser Einstellung die CK8DIV-Fuse abschalte funktioniert das > debuggen bei mir. > > Tiny13A habe ich nicht probiert - es funktioniert mit dem "normalen" > Tiny13. es geht jetzt mit beidem 13 wie 13A bei deaktivierter CKDIV8. ((step over ok, aber run (F5) startet nicht wirklich die Abarbeitung)) Könnte vielleicht ein aktivierter PU an pin5 (MOSI) im Anwenderprogramm die Probleme bewirkt haben? Nur von der Theorie her..?
Hast Du die hier https://www.mikrocontroller.net/articles/DebugWIRE berschriebenen Einschränkungen beachtet? Ein PU an Pin5 spielt keine Rolle, da der Reset-Pin genutzt wird. Hast Du ggf. einen Kondensator am Reset-Pin? Der darf da nicht sein .. Ich konnte (bei 9,6 MHz ohne CLK8DIV) einen Breakpoint setzen und nach Stop am Breakpoint mir aktuelle Register etc. ansehen. Intensivere Tests habe ich nicht vorgenommen.
Dieter F. schrieb: > Hast Du die hier > > https://www.mikrocontroller.net/articles/DebugWIRE > > berschriebenen Einschränkungen beachtet? Ja, s.o. > Ein PU an Pin5 spielt keine > Rolle, da der Reset-Pin genutzt wird. Hast Du ggf. einen Kondensator am > Reset-Pin? Der darf da nicht sein .. gewollt nicht, aber es gibt ja offb. ein delta zw. meinem Design und dem breadboard Aufbau. Das muß ich jetzt überprüfen. Erstmal vielen Dank! joh > Ich konnte (bei 9,6 MHz ohne CLK8DIV) einen Breakpoint setzen und nach > Stop am Breakpoint mir aktuelle Register etc. ansehen. Intensivere Tests > habe ich nicht vorgenommen.
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.