ATtiny auslesen und einen neuen ATtiny damit beschreiben

Gast #138305
Lesenswert?

Hi,

ich habe einen programmierten ATtiny, der mir bei meinem Hobby
"Modelleisenbahn" einige Dienste für mich übernimmt.
Der M-Controler wurde mal von meinem Onkel programmiert, der dafür eine
Menge schlafloser Nächte verbracht hatte, bis dieser endlich fertig
war.
Leider existiert von den Programmdateien, die durch einen
Festplatten-Gau verloren gegangen sind, nicht ein Exemplar mehr.
Ich habe nun angefangen, mich mit der Materie AVR's ein wenig näher zu
beschäftigen und habe auch schon, den einen oder anderen ATtiny
programmiert. Was mir nun noch überhaupt nicht gelungen ist, diesen
programmierten ATtiny mit einem neuen ATtiny (gleicher Typ) zum Laufen
zu bekommen.
Der ATtiny läßt sich mit PonyProg ohne Probleme auslesen und die
ausgelesenen Daten , lassen sich auch ohne Probleme mit einem neuen
ATtiny wieder beschreiben. Nur leider funktioniert der neu
programmierte ATtiny aber nicht!!! Auch ein zweiter neuer ATtiny
brachte kein Erfolg.
Was für ein fehler tritt hierbei auf und wie kann man da Abhilfe
schaffen??????

Gruß Teo
Gast #138308
Lesenswert?

Lesen kannst du auch bei gesetzten Fusebits, kontrollier mal ob du
"sinnvolle" Daten ausliest oder nur FF. Wenn das stimmt liegts
ziemlich sicher an den Fusebits oder der Beschaltung.

grüße leo
Gast #138310
Lesenswert?

Stell doch mal den Hex-Code hier rein (Anhang), oder wenn Du ihn nicht
rausgeben willst, die ersten paar Zeilen. Dann kann man sagen, ob der
Code sinnvoll ist oder der ATtiny lesegeschützt war.

Sven
Gast #138311
Lesenswert?

Hi,

klingt jetzt echt bescheuert, aber was in Gottes Namen ist Fuses.
Als ich schrieb, das ich den einen und anderen ATtiny schon
programmiert habe, meinete ich damit, dass ich eine vorhandene
HEX-Datei über das PonyProg Programm in den ATtiny gegeben habe. Die
ATtyni's funktionierten auch alle nach der Programmbeschreibung der
HEX-Datei.

Gruß Teo
Gast #138312
Lesenswert?

Welcher ATiny???

ATiny12?
ATiny13??
ATiny15???
ATiny22????
ATiny26?????
ATiny2313??????

ATiny10, ATiny11 oder ATiny28 wird es ja mangels ISP nicht sein...

Hast du die Dinger nun "programmiert", also ein Programm dafür
geschrieben, oder nur eine vorhandene Programmdatei mittels Ponyprog
ins Flash transferiert?

Die AVRs haben neben dem Flash auch noch EEPROM, in das man evtl. Daten
transferieren muss und Fuses, mit denen man Einstellungen zur
Betriebsart vornehmen muss. Diese sind aber bei jedem AVR-Typ etwas
anders. Um dort einen Rat geben zu können, wirst du wohl etwas mehr
Info preisgeben müssen.

AVRs haben auch Lockbits, mit denen man den Chip vor unbefugtem
Auslesen durch Programmdiebe schützen kann. Gewerblich hergestellte
Modelleisenbahnmodule mit MCs haben mit Sicherheit Ausleseschutz, wenn
der AVR also nicht von deinem Onkel stammt, dann vergiss es.

...
Gast #138314
Lesenswert?

Ja woher willst du wissen, dass die ausgelesene Hex-Datei dem
Flash-Inhalt entspricht? Denn wenn der Original-Tiny15 vor Auslesen
geschützt war, dann hast du statt der Programmdatei nur Müll
ausgelesen.

Es kann auch sein, dass das EEPROM weitere Daten enthält. Dann musst du
auch das EEPROM auslesen und in die Duplikate übertragen.

Es kann sein, dass die Fusebits anders gesetzt sind als im
Auslieferungszustand. Damit würde ich aber nicht unvorbereitet
herumspielen, die Gefahr, den Tiny15 zu "lähmen" ist zu groß. Da
sollte man schon die Funktion der Fusebits im Datenblatt des Tiny15
gelesen und verstanden haben.

Es kann sein, dass eigentlich alles klar gegangen ist, das Programm
aber sehr zeitkritisch ist (Digitaldecoder?) und sie Kalibration des
internen RC-Oszillators nicht stimmt. Zur Kalibration hat jeder Tiny15
sein persönliches Kalibrationsbyte, welches vom ISP-Programmer
ausgelesen werden muss und in den Programmcode eingebunden werden muss,
damit das Tiny15-Programm dieses Kalibrationsbyte in das
Kalibrationsregister OSCCAL des Tiny15 schreiben kann. Beim unbesehenen
Kopieren von einem Exemplar auf das andere wird dann das falsche
Kalibrationsbyte verwendet. Somit läuft der kopierte AVR mit falscher
Taktfrequenz. Lies doch mal mittels Ponyprog die "CalibrationsBytes"
der verschiedenen Tiny15 aus und vergleiche die mal miteinander.
Viele Programmierer legen das Kalibrationsbyte in das Low-Byte der
letzten Flash-Zelle. Das ist bei byteorientierter Anzeige das vorletzte
von Ponyprog im Hexdump angezeigte Byte. Überprüfe doch mal, ob dieses
Byte mit dem Kalibrationsbyte des Original-Tiny15 übereinstimmt. Wenn
ja, dann kannst du die zu kopierenden Tiny15 kalibrieren, indem du
diesen Wert durch das jeweilige frisch ausgelesene Kalibrationsbyte
ersetzt. Dann könnte das Timing wieder stimmen.

Um Genaueres sagen zu können, müsste ich aber die Hexdatei sehen und
analysieren können.

...

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren