Hallo zusammen, ich bin noch recht neu auf diesem Gebiet und habe deshalb hier gleich mal eine Frage. Ich habe einen Tiny13 NUR auf 128 KHz runter gefused und hinterher gelesen, dass mein MySmartUSB Light Programmer damit jetzt nicht mehr klar kommt. Nun treibt mich der Verlust zwar nicht in den finanziellen Ruin aber ich würde es trotzdem gerne wissen... Besteht denn evtl. eine Chance den Tiny13 mit einem Eigenbau Programmerkabel für die parallele Schnittstelle zu retten? Googlen hat nicht wirklich was gebracht oder ich hatte nicht die passenden Suchbegriffe naja... Gruß Marcel
matze klein schrieb: > Ich habe einen Tiny13 NUR auf 128 KHz runter gefused und hinterher > gelesen, dass mein MySmartUSB Light Programmer damit jetzt nicht mehr > klar kommt. Wende Dich doch mal an den myAVR-Kundendienst und bitte darum, Dir mitzuteilen, wie man die ISP-Frequenz so weit herunterstellt, dass man auf übliche AVRs zugreifen kann. matze klein schrieb: > Besteht denn evtl. eine Chance den Tiny13 mit einem Eigenbau > Programmerkabel für die parallele Schnittstelle zu retten? Suche mal nach "Ponyprog" und "veryslow", da müsstest Du Hinweise finden, wie weit Ponyprog mit der ISP-Frequenz runter gehen kann. Auch in AVR-Dude müsste die ISP-Frequenz einstellbar sein. Ich kenne mich aber mit beiden Programmen nicht aus, da ich Original-Equipment von Atmel benutze, das unter AVR-Studio läuft. ...
matze klein schrieb: ... > Ich habe einen Tiny13 NUR auf 128 KHz runter gefused und hinterher > gelesen, dass mein MySmartUSB Light Programmer damit jetzt nicht mehr > klar kommt. > Hatte auch mal das Problem. Vielleicht hilft Dir das weiter. Beitrag "ATtiny13 mit 128kHz und PonyProg2000 betreiben" Bernd_Stein
nimm avrdude, da kannst Du beliebig langsam programmieren
... schrieb: > nimm avrdude, da kannst Du beliebig langsam programmieren Nicht Jeder mag Kommandozeilen-Programme. Und ehe man das "richtige" Frontend aus dem Riesenangebot gefunden hat, ist einem die Lust darauf vergangen. ...
> Nicht Jeder mag Kommandozeilen-Programme.
fuer einen verfusden Attiny wird man doch mal 1 Zeile eintippen koennen,
die meisten Rechner haben nicht nur eine Maus, sondern auch eine
Tastatur
... schrieb: >> Nicht Jeder mag Kommandozeilen-Programme. > > fuer einen verfusden Attiny wird man doch mal 1 Zeile eintippen koennen, > die meisten Rechner haben nicht nur eine Maus, sondern auch eine > Tastatur Viele jüngere Computerbenutzer, die nicht mehr mit DOS aufgewachsen sind, können das aber nicht mehr. Sie können halt nur klicken oder daddeln, die Tastatur ist nur für Texte da. Ist zwar traurig, aber leider wahr... ...
So hallo nochmal ... Danke erst mal für die vielen Antworten. Ponyprog läuft im Moment nicht wegen Win 7 64 bit :-( ... Wollte aber sowieso demnächst den Rechner neu installieren. Aber Konsolenprogramme stellen auch kein Problem dar. Das werde ich mal als nächstes testen. Ich berichte dann wieder ... Gruß Marcel
>Viele jüngere Computerbenutzer, die nicht mehr mit DOS aufgewachsen >sind, können das aber nicht mehr. Pech gehabt, gehört in einigen Fällen nunmal dazu. Und es wird doch wohl nicht so schwer sein, nach Doku ne Zeile mit nem Befehl zu tippen... Aber ich weiss, das suchen ist ja immer die Sache...
So nun der versprochene Bericht. Der Tiny konnte gerettet werden :-) , ok er war ja auch NUR runter getaktet. DT006 Nachbau + Ponyprog (SPIBUSSPEED=VERYSLOW) und schon konnten die Fusebits neu gesetzt werden. AVRDUDE lief auch damit. Das schwierigste an dieser "Nummer" war, einen PC mit einer "echten" LPT Schnittstelle zu finden. SUNIX PCI Schnittstellenkarten gehen scheinbar nicht dafür weil die Adresse sonstwo liegt. Also Ende gut alles gut und danke an alle für die Tips und Ratschläge. Gruß Marcel
Vielleicht hilft es ja dem Einen oder Anderen : http://homepage.hispeed.ch/peterfleury/avr-hvsp-fuse-restore.html Eine Rückmeldung wäre schön. Beitrag "Re: ATtiny13 und STK200 über PonyProg2000 flashen" Bernd_Stein
Du buddelst das Thema nach 8 Jahren aus, um einen unpassenden Link zu posten. Warum?
Angehängte Dateien:
-
ATm16_AVRISP_mkII_Error.jpg
140 KB
Ich arbeite sehr gerne mit dem ATmega88PA, weil dieser dieses DebugWire besitzt. Der ATmega16-16PU, besitzt dies nicht, dafür dieses *On Chip Debugging ( OCD )*, was allerdings über die JTAG-Schnittstelle läuft. Irgendwie schaffe ich es immer wieder mal, mir meine µC über diese JTAG-Schnittstelle abzuschiessen ( Siehe auch den Link ). Ich kann dann den µC weder per ISP noch über JTAG ansprechen. Die 4,3V im Screenshot kommen daher, dass ich mittlerweile eine Schottky-Dummheitsdiode in Reihe zu Vcc des µC verwende. Aber dies ist nicht das Problem, denn selbst bei 4,9V kommt die gleiche Fehlermeldung. Mit einem neuen µC habe ich erstmal keine Probleme. Mir ist aufgefallen, dass ich die FUSE OCDEN, gar nicht aktivieren muss ( Häkchen setzen ), denn Debugging funktioniert auch so im ATMEL STUDIO 7 ( AS7 ). Seltsamerweise wurde aber hierdurch, durch dass Debugging, die *FUSE EESAVE* aktiviert. Ist nicht schlimm, aber ich finde es seltsam. Debugging mach ich natürlich mit dem ATMEL-ICE, denn der *AVRISP mkII*, unterstützt kein Debugging. Ich kann doch nicht der Einzige sein, der diesen sporadischen Fehler hat. Beitrag "AtMega6490P per JTAG & ISP" Bernd_Stein
Angehängte Dateien:
Bernd S. schrieb: > Vielleicht hilft es ja dem Einen oder Anderen : > > http://homepage.hispeed.ch/peterfleury/avr-hvsp-fuse-restore.html > > Eine Rückmeldung wäre schön. > > Beitrag "Re: ATtiny13 und STK200 über PonyProg2000 flashen" > > > Bernd_Stein > Tja, da muss ich mir wohl selber eine Rückmeldung geben ;-) Da ich jetzt doch bei einigen ATtiny13A diesen FUSE-RESETTER erfolgreich eingesetzt habe, aber diesmal wieder den Verdrahtungsplan suchte, ist es an der Zeit dass mal hier zu hinterlegen. Bernd_Stein
:
Bearbeitet durch User
> http://homepage.hispeed.ch/peterfleury/avr-hvsp-fuse-restore.html ******************************************************************* MY HOMEPAGE Der Service "My Homepage" wurde am 30.11.2019 eingestellt. http://www.peterfleury.epizy.com/avr-hvsp-fuse-restore.html
A. B. schrieb: > MY HOMEPAGE > Der Service "My Homepage" wurde am 30.11.2019 eingestellt. > Nicht so schlimm. C-Code hier : Beitrag "Re: ATtiny13 und STK200 über PonyProg2000 flashen" Hexfile hier : Beitrag "Re: ATtiny13 und STK200 über PonyProg2000 flashen" Schaltplan hier : Beitrag "AVR: HVSP Fuse Resetter ;-) ( Restore )" Bernd_Stein
Angehängte Dateien:
-
AVRISP_mkII_ID-Read_OK.png
11 KB -
AVRISP_mkII_ID-Read_NOK.png
12 KB -
AVRISP_mkII_ID-Read.png
22 KB -
AVRISP_mkII_Read_Error.jpg
130 KB
Hallo zusammen, habe wieder einmal das Problem auf meine länger in einem Breadboard eingebauten ATMega88PA uC, per AVRISP mkII, über ISP zugreifen zu können. Beim Drücken auf Read bei Device signature kommt die Fehlermeldung im Anhang. Im Anhang die DSO-Bilder bei einem neuen ( OK ) und einem der nicht Ansprechbaren ( NOK ). HVSP, also Hochvolt-Seriell-Programmierung geht ja bei den ATMega88PA nicht. Mittlerweile habe ich die vier ( NOK ), so durcheinander gebracht, dass ich nicht mehr weiß, welcher über einen Quarz getaktet wurde und welcher mit dem internen RC-Oszillator. Einen externen Takt an XTAL1 anzulegen hat auch nichts gebracht. Auch habe ich bei 125kHz Takt angefangen bis runter auf Minimun zu gehen, jedoch immer kein Zugriff auf die vier uC. Was kann ich tun um generell wieder Zugriff auf diese uC zu erlangen ? Bernd_Stein
Bernd S. schrieb: > Mittlerweile habe ich die vier, so durcheinander gebracht Ich will dich nicht beleidigen, aber es ist schon erstaunlich, wie oft dir das nach so vielen Jahren immer noch passiert. Ich fürchte dass dein Aufbau mangelhaft ist. Vielleicht führen schlechte Stromversorgung oder andere relevante Leitungen zu kritischen Kommunikationsfehlern. Fotos vom Aufbau wären mal interessant. Noch ein Tipp: Lasse die Finger von den Fuses, so weit es geht. Viele Schaltungen laufen auch prima mit dem internen R/C Oszillator und bei vielen AVR Modellen kann man die Taktfrequenz per Software (CLKPR Register) ändern ohne die Fuses anfassen zu müssen. Manche Leute beschreiben die Fuses bei jedem einzelnen Flash-Vorgang, davon kann ich nur abraten. Ein Bootloader könnte eine wirksame Alternative sein, solche Fehler zu vermeiden. Der Arduino Bootloader ist mit der Arduino IDE kinderleicht installiert, auch wenn man sonst mit Arduino nichts zu tun haben will.
Stefan ⛄ F. schrieb: > Ich fürchte dass dein Aufbau mangelhaft ist. Vielleicht führen schlechte > Stromversorgung oder andere relevante Leitungen zu kritischen > Kommunikationsfehlern. > > Fotos vom Aufbau wären mal interessant. > Hallo Stefan, ja ist wie verhext. Der Breadboardaufbau ist ja immer gleich, d.h. Neuer uC in den gleichen Schaltungsaufbau ( Nur ISP-Anschlüsse und KerKo an Vcc ) geht, die Alten eben nicht. Und vor Monaten oder Jahren funktionierten sie ja noch in der Schaltung, das heißt die Firmware wurde immer wieder geändert bzw. geflashed. Echt seltsam. Bernd_Stein
Irgendwann ist der Flash Speicher auch einfach verschlissen.
Angehängte Dateien:
-
DebugWIRE.jpg
130 KB -
START_Debugging.jpg
130 KB -
DebugWIRE_Vcc.jpg
120 KB -
Disable_DW_and_Close.jpg
140 KB
Ich bin ja damals vom ATmega8 zum 88 gewechselt, weil DebugWIRE für die Fehlersuche eine gute Sache ist. Und genau dies wurde mir jetzt zum Verhängnis, weil ich diesen noch eingeschaltet hatte und somit kein ISP-Zugriff möglich ist. Erschwerend kommt hinzu dass DebugWIRE nicht mit dem AVRISP mkII nutzbar ist. Mit dem ATMEL ICE konnte ich jedoch drei von den vier uC wieder zum Leben erwecken und habe als erstes die FUSES auf Werkseinstellungen gebracht ATMega88PA -> ID $1E 93 0F EX = $F9 Hi = $DF Lo = $62 Lock Bits $FF War, wie man neudeutsch sagt, zwar tricky, aber es geht immerhin. Grundsätzlich empfehle ich das Micochip Studio als Administrator zu öffnen. Hoffe das alles noch vernünftig auf die Reihe zu kriegen, da es viele Fallstricke gibt. Einige uC hatten als Taktquelle den internen RC-Oszillator und andere halt einen Quarz. So musste ich also, wenn es nicht funktionierte z.B. einen 8Mhz Quarz, plus die obligatorischen 2x 22pF anschließen, wenn es nicht klappte. Hin und wieder hatte ich aber auch vergessen, die Schaltung wieder an die 5V-Spannung zu legen. *Das der 100nF KerKo an Vcc und Gnd anzuschließen ist erwähne ich trotzdem mal.* 1. Man öffnet also irgend ein Projekt und setzt am besten sofort beim ersten Befehl ein Breakpoint. 2. Stellt dann im Reiter neben dem uC-Typ als Interface DebugWIRE ein ( siehe Screenshot DebugWire.jpg ). 3. Dann drückt man den grünen, vollflächigen, dreieckigen Button -> Start Debugging(F5) (START_Debuging.jpg). 4. Falls es zur Fehlermeldung kommt, kann es sein dass ein Quarz benötigt wird oder und man vergessen hat die 5V-Spannung anzulegen ( DebugWIRE_Vcc.jpg ). 5. Wenn beim Breakpoint ( gelber Pfeil ) angehalten wurde, geht man beim Reiter Debug auf " Disable DebugWIRE and close "( Disable DW and Close.jpg ). 6. Jetzt kann normalerweise wieder über den Button Device Programming ( gelber Blitz ), normal auf den uC zugeriffen werden. Bernd_Stein
Habe so im Hinterkopf, dass bei DebugWire das Close der Debug-Schnittstelle nicht vergessen werden darf. Außerdem werden Breakpoints in den Flash-Speicher eingefügt und die reduzieren die Lebensdauer des Chips. Ich hoffe das stimmt so??
BlaBla schrieb: > Habe so im Hinterkopf, dass bei DebugWire das Close der > Debug-Schnittstelle nicht vergessen werden darf Darauf bezieht sich Bernds Prozedur, womit er die Fuse zurück setzt. > Außerdem werden Breakpoints in den Flash-Speicher > eingefügt und die reduzieren die Lebensdauer des Chips. Aber nicht weil man die Fuse vergessen hat, sondern weil der Debugger bei jedem Single-Step eine neuen Breakpoint setzt, wenn man denn den Debugger auch tatsächlich 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.