Habe bei einem ATtiny13 die Clock auf 4,8 MHz gestellt und den 8x Vorteiler eingeschaltet (was problemlos ging). Dann habe ich ein Programm reingeladen, was CLKPR auf den Teilerfaktor 256 setzt. Das Blink-Programm wurde auch richtig langsam. Dummerweise komme ich nun per ISP nicht mehr an den Controller (ich dachte, nach einem Reset ist der kleine CLKPR weg und der per fuse eingestellte Takt wieder da): als Programmer habe ich einen AVRISP (bzw. einen Arduino mit entsprechender Software. AVRDUDE meldet nun: avrdude -p attiny13 -P com11 -c avrisp -v v -b 19200 -U flash:w:test.hex avrdude: Version 5.10, compiled on Jan 19 2010 at 10:45:23 avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny13 avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.13s avrdude: Device signature = 0x000000 avrdude: Yikes! Invalid device signature. Wenn ich die Geschwindikeit runtersetze (etwa auch 2400) gibt es keine Verbindung: avrdude: stk500_getsync(): not in sync: resp=0x00 Was nun? Habe ich etwas übersehen? Hilft nur noch ein HV-Programmierer? Danke! Martin
>ich dachte, nach einem Reset ist der kleine CLKPR weg und der per fuse >eingestellte Takt wieder da so sollte es auch sein. welche chip revision hast du? (auf der rückseite) es gab bei einigen chips in frühen revisionen einen bug siehe extras im datenblatt. ansonsten isp tackt auf kleiner als 4688hz stellen.
syn_error schrieb: >>ich dachte, nach einem Reset ist der kleine CLKPR weg und der per fuse >>eingestellte Takt wieder da > so sollte es auch sein. Dachte ich auch mal, ist aber nicht so.... Ich habe ihn gerettet, indem ich Reset vorübergehend fest auf GND gelegt habe, damit er beim Power-On nicht anlaufen kann. > > welche chip revision hast du? (auf der rückseite) > es gab bei einigen chips in frühen revisionen einen bug siehe extras im > datenblatt. > > ansonsten isp tackt auf kleiner als 4688hz stellen.
>>>ich dachte, nach einem Reset ist der kleine CLKPR weg und der per fuse >>>eingestellte Takt wieder da >> so sollte es auch sein. >Dachte ich auch mal, ist aber nicht so.... ich bin jetzt spontan vom atmega88 ausgegangen der sich beim reset auf default werte zurücksetzt aber in den ersten revisionen einen bug hatte wo dies nicht passierte. der tiny13 hat den gemeinten bug jetzt nicht aber dafür auch einen der das programmieren nicht mehr zulässt unter bestimmten voraussetzungen.
Auch dem Chip steht unten "L8 Taiwan A5", oben "Atmel 0917 ATTINY13 20PU" Hab gerade das aktuellste Datenblatt runtergeladen - finde leider nicht, wie man die Revision identifiziert. Die unter 24.3.3 gelisteten fuses habe ich jedenfalls nicht gesetzt. Habe gerade durch den Aduino-AVRISP-Code geblättert: der ist auf 19200 fixiert, kann also nur 19200. Dort wird die SPI-Sendefunktion des ATmega328p aufgerufen. Sie ist auf fosc/128 geschaltet, langsamer geht nicht. (ich vermute, dass ein Runtertakten des Arduino von 16MHz weitere Nebeneffekte hat - möchte mir den nicht auch noch zerbasteln)
>Auch dem Chip steht unten "L8 Taiwan A5", oben "Atmel 0917 ATTINY13 >20PU" hmm, beim atmega kann man recht gut die revision aus den buchstaben der rückseite herrausfinden. hier also revision L oder A was ja nicht sein kann. nachdem der chip aber produktionsdatum 17 woche 2009 hat wird das sicherlich die neueste revision sein. >finde leider nicht, wie man die Revision identifiziert. das kann man nicht per software auslesen, entweder der händler weiß welche revision er verkauft oder aber auf der rück oder vorderseite steht das drauf. >Die unter 24.3.3 gelisteten fuses habe ich jedenfalls nicht gesetzt. einen versuch war`s wert. :) >der ist auf 19200 fixiert, kann also nur 19200 das ist nur die übertragungsgeschwindigkeit vom pc zum programmer und in dem fall nicht ausschlaggebend. >Sie ist auf fosc/128 geschaltet, langsamer geht nicht. dann sieht es schlecht aus. ich benutze nicht das stk500 protokoll aber es gibt vielleicht eine möglichkeit darüber den isp takt zu verlangsamen. >ich vermute, dass ein Runtertakten des Arduino von 16MHz weitere >Nebeneffekte hat sehr gut möglich, die timings des programmers werden dann nicht mehr stimmen und müssen angepasst werden.
@Kluchscheißer: RESET fest auf GND legen hilft nicht: AVRDUDE kann dann nicht syncen (resp=0x00)
@syn_error: danke für die Hintrgrundinfos. Scheint also so, dass ich entweder im Arduino eine SPI-Emulation schreibe, die gaaanz langsam ist - oder den Chip als Lehrgeld abschreibe (ok, bringt mich nicht um; fuchst aber schon ein wenig - und kostet Zeit)
> Dort wird die SPI-Sendefunktion des >ATmega328p aufgerufen. Sie ist auf fosc/128 geschaltet, langsamer geht >nicht >im Arduino eine SPI-Emulation schreibe, die gaaanz langsam ist nachdem glaube ich der vorteiler 128 schon der größte ist bleibt nur den quarz oder auch die CLKPR zu setzten um auf einen niedrigeren takt zu kommen dabei werden aber die timings des restlichen programms nicht mehr stimmen was eine programm anpassung erfordert. dies gilt allerdings nur für das hardware spi interface. du könntest aber z.b. spi in sofware schreiben und dort die zeiten nach belieben verkleinern wobei das restliche programm bis auf den ersatz des hardware spi gleich bleibt.
edit: alternative hv programmieren. der hv programmer muss im endeffekt nur einen chip erase machen und dann geht`s wieder mit isp.
Ja, die paar Bits zum chip erase kann ich ja noch von Hand reinmorsen :-) (die 12V machen aus einen 9V-Block und +3V die aus einem Spannungsteiler an VCC kommen: da fließt doch kein großer Strom, so dass das gehen sollte?!)
>da fließt doch kein großer Strom, so dass >das gehen sollte?! der reset pull-up hat laut datenblatt mindestens 30kohm und max. 80kohm. 12V - 5V = 7V 7V / 30kohm = 233µA
Martin Gerken schrieb: > @Kluchscheißer: RESET fest auf GND legen hilft nicht: AVRDUDE kann dann > nicht syncen (resp=0x00) Ich benutze den Dude nicht, ich nehme das AVR-Studio, also das Original.
hab ich gerade durch zufall entdeckt: http://www.mikrocontroller.net/articles/AVR_Fuses#Reaktivieren_beim_CLKPR-Problem_.28Attiny13.29 vielleicht hilft dir das ja weiter.
syn_error schrieb: > hab ich gerade durch zufall entdeckt: > > http://www.mikrocontroller.net/articles/AVR_Fuses#Reaktivieren_beim_CLKPR-Problem_.28Attiny13.29 > > vielleicht hilft dir das ja weiter. Was ist daran anders als an dem bereits genannten? Beitrag "ATtiny13 nicht mehr programmierbar (CLKPR-Unfall?)" Es geht ja darum, den Reset-Pin auf Low zu legen um das Anlaufen vor dem Start der Programmiersequenz zu verhindern. Klar, ein PullDown ist vorsichtiger als direkt an Masse legen, es erfüllt aber beides denselben Zweck.
Danke nochmal - habe nach em Hinweis den Quellcode des Arduino-Programmers durchsucht. Tatsächlich gibt er kurz HIGH auf /RESET, also der ATtiny konnte anlaufen. Auch wenn ich das rausnehme (per Software, oder durch Verkabelung) kommt trotzdem ein Sync-Fehler vom AVRdude. Werde die HV-Programmierung die Tage mal testen.
Hallo, hatte eben genau das gleiche Problem. CLKPR hatte ich auf 256 stehen. Mein Arduino Programmer war also zu schnell. Zum Glück hatte ich noch einen alten Rechner mit PonyProg und einen selbstgebastelten paralell-Programmer zur Verfügung. Wichtig ist dann noch, dass man in der PonyProg.ini folgenden Eitrag macht: SPIBusSpeed = VERYSLOW. Ponyprog konnte dann auf den Chip zugreifen und ich konnte ihn löschen. Danach ging die Programmierung natürlich auch wieder mit dem Arduino. Hoffe das hilft Leuten mit demselben Problem weiter. Alles Gute.
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.