www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATtiny13 nicht mehr programmierbar (CLKPR-Unfall?)


Autor: Martin Gerken (mager)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: syn_error (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Kluchscheißernder Nixwisser (kluchscheisser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: syn_error (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>>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.

Autor: Martin Gerken (mager)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: syn_error (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Martin Gerken (mager)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kluchscheißer: RESET fest auf GND legen hilft nicht: AVRDUDE kann dann 
nicht syncen (resp=0x00)

Autor: Martin Gerken (mager)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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)

Autor: syn_error (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: syn_error (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
edit:
alternative hv programmieren.
der hv programmer muss im endeffekt nur einen chip erase machen und dann 
geht`s wieder mit isp.

Autor: Martin Gerken (mager)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?!)

Autor: syn_error (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Kluchscheißernder Nixwisser (kluchscheisser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: syn_error (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab ich gerade durch zufall entdeckt:

http://www.mikrocontroller.net/articles/AVR_Fuses#...

vielleicht hilft dir das ja weiter.

Autor: Kluchscheißernder Nixwisser (kluchscheisser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
syn_error schrieb:
> hab ich gerade durch zufall entdeckt:
>
> 
http://www.mikrocontroller.net/articles/AVR_Fuses#...
>
> 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.

Autor: Martin Gerken (mager)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.