Atmega8 läßt sich nicht umprogrammieren

Hallo,

wieder mal das leidige Thema Fuses. Habe mir die Laufschrift aus Elektor mit programmierten Controller von Elektor gebaut. Funktioniert prima.
Jetzt habe ich den Text geändert und in BASCOM AVR compiliert. Das Auslesen der ELEKTOR CPU Atmega8 ergab folgende Werte
Read Signature: 0x1E 0x93 0x07
Lock Byte: FF
Fuse Bytes: DF D9
V target: 5.1
AREF 5.0
Osc.: 00 01
Frequ. 3.686 Mhz
Ich benutze den STK500 zum programmieren, lese eine neue CPU aus und habe bei den Fuse Bytes E1 D9, also 1 Mhz. Ich ändere E1 in DF (16Mhz und 4ms Startup) lade das Input file Schrift.hex in Flash, Mode auch auf Flash, Erease Device - ok, Program - ok, Verify - ok.
Trotz allem ist das Fusebyte High nicht umprogrammiert, nach dem Auslesen ist es immer noch auf E1. Wenn ich nun beim Auslesen das High Byte in DF ändere und write betätige ist die CPU verbrannt und läßt sich weder programmieren, noch auslesen.
Was mache ich falsch? (Und gibt es eine Möglichkeit die verbrannten CPUs wieder zu beleben?)
Die neue CPU mit E1 funktioniert, allerdings mit 1 Mhz, d.h. sie hat das Programm angenommen.
Gruß Lutz27

Zitat:

---

...und habe bei den Fuse Bytes E1 D9, also 1 Mhz. Ich ändere E1 in DF (16Mhz und 4ms Startup) lade das Input file Schrift.hex in Flash, Mode auch auf Flash, Erease Device - ok, Program - ok, Verify - ok.
Trotz allem ist das Fusebyte High nicht umprogrammiert, nach dem Auslesen ist es immer noch auf E1.

---

Mit dem Highbyte stellst Du aber nichts an der Taktquelle und -frequenz herum... bist Du Dir sicher, dass Du High- und Lowbyte nicht verwechselst?

Einen coolen Fuse-Calculator gibt´s hier:
http://www.engbedded.com/fusecalc/

Mittelgradig "verbrannt" wäre der Chip, wenn Du im Highbyte Bit7 gesetzt hast - dann ist der Reset-Eingang deaktiviert, d.h. der Controller kann nicht mehr seriell programmiert werden.

Ansonsten könnte es schlimmstenfalls sein, dass der Controller einen externen Takt erwartet. Organisier Dir einfach mal ein Rechtecksignal mit ein paar 100kHz und lege es an XTAL1 (= B.6) - vielleicht spricht der Controller dann wieder mit Dir...

Gutes Gelingen!

Hallo Sauerbruch,

vielen Dank für die Tipps. Es sieht so aus, als ob ich tatsächlich High und Low Byte verwechselt habe. Werde noch mal in mich gehen und versuchen die CPU zu reanimieren. Der Fuse Calculator ist wirklich cool. Danke für die Info.
Gruß Lutz27

Hallo Sauerbruch,

habe die Original ELEKTOR CPU mit BASCOM AVR und STK500 ausgelesen und das gab folgendes Ergebnis:
Fusebytes: DF (High) - D9 (Low)
Im Fusecalculator habe ich rumexperimentiert und bin bei Ext 16Mhz/0ms fündig geworden, bzw habe dasselbe Bild erreicht:
FuseBytes: DF (Low) - D9(High)
Das heißt, das Bild ist genau umgekehrt. Wenn ich jetzt die Daten in BASCOM richtig eingebe, d.h. DF bei Low und D9 bei High und die CPU programmiere, habe ich sie wieder verbrannt. Also entweder ist die Bezeichnung High/Low beim Fusecalculator oder bei BASCOM AVR falsch.
Ich habe Screenshots gemacht zum Beweis gemacht, weiss aber nicht, wie ich die in diese Antwort bekomme.
Gruss Lutz27

...Screenshots klingt großartig!!

Wen Du eine Antwot schreibst, ist am unteren Ende des Fensters eine Schaltfläche "Attachment hinzufügen". Damit geht´s.

Bin gespannt!

Hallo Sauerbruch,

anbei die versprochenen Screenshots. Ich habe eine Linie eingezogen, die den Bezug zu dem Fenster herstellt, in dem der Cursor steht.
Gruß Lutz27

Zitat:

---

Also entweder ist die Bezeichnung High/Low beim Fusecalculator oder bei BASCOM AVR falsch.

---

Hmmm... so etwas würde ich erst ganz am Schluss vermuten. Die Jungs die sowas programmieren schlafen ja auch nicht auf´m Baum.

Hast Du die "verbrannten" Chips denn wieder flott bekommen - und wenn ja, wie?
Und einen externen Quarz hast Du auch dran? Denn beide Möglichkeiten des Low-Bytes (DF und D9) legen einen externen Quarz als Taktquelle fest.

Wir kriegen das schon raus :-)

Hallo Sauerbruch,

als Referenz habe ich ja die von ELEKTOR programmierte CPU, die in die eingesetzte Schaltung mit dem 16 Mhz Quarz auch einwandfrei arbeitet. Ich habe das Original HEX-File aus der CPU ausgelesen und separat abgespeichert. Das Transferieren in eine nagelneue CPU funktioniert auch. In der Schaltung wird das Elektor Original gegen die gerade geflashte CPU getauscht und arbeitet falsch, das heißt, wenn ich den Arm ganz langsam von Hand drehe, kann ich erahnen, daß die Schrift auch erscheint. Allerdings scheint die CPU mit den internen 1 Mhz zu arbeiten, was mich wieder zu den Fuse Bytes bringt, da die ELEKTOR CPU in genau derselben Schaltung einwandfrei mit 16 Mhz arbeitet (siehe Bild).
Gruß Lutz27

Hallo Sauerbruch,

in dem Tutorial habe ich gelesen, daß man verfuste CPUs nur wieder in Parallel Mode reanimieren soll. Dazu soll man Die Jumper entsprechend setzen und die Brücken laut Muster (STK500) Port B und Port D setzen. Habe natürlich in den Options auch Parallel Mode selected. Ich habe auch probiert an Pin 9 (XTAL1) 250 Khz anzulegen (1/4 Takt bei 1 Mhz). Die CPUs ließen sich leider nicht resetten. So gut so schlecht.
Noch einmal zu meinem Verdacht, daß in dem BASCOM Programm etwas vertauscht sein könnte (natürlich ist mir klar, daß die Jungs ausgeschlafen sind), wenn ich die funktionierende CPU auslese (Fuses) dann bekomme ich in dem Textfenster "Fuse byte 0 DF" und "Fuse byte 1 D9". Gehe ich mit dem Mauszeiger auf das Fenster, in dem DF steht, öffnet sich ein Fenster, in dem Fuse High byte steht und bei D9 Fuse Low byte. Also muß byte 0 = high und byte 1 = low sein. Vertausche ich high und low Bytes und gehe auf den write-Button, bestätigt mir das Textfenster, die Programmierung. Auch das Verify ist ok. Wenn ich das Bascom Programm resette (STK500 ausgeschaltet) und die CPU erneut auslese, sind die Fuse Bytes wieder an der alten Stelle wie vor dem Vertauschen. Also hat die CPU die Umprogrammierung scheinbar nicht vorgenommen, obwohl ich garkeine Fehlermeldung bekommen habe.
Mann, das muß doch möglich sein den Atmega8 genauso einzustellen, wie das die ELEKTOR Leute gemacht haben.
Gruß Lutz27

Hmmm...
Also, mit Parallel-Programmierung habe ich noch nie was gemacht - habe auch kein STK500 (ich programmiere meine Chips entweder auf ´nem ollen Steck-Experimentierboard oder direkt in der Anwendung).

Dass die Chips auch unter einem externen Takt tot bleiben, klingt wenig verheißungsvoll... aber vielleicht weiß dazu jemand anders aus diesem Forum einen Rat. Habe da mal was von HV-Programmierung gehört - diese Spielart aber zum Glück noch nie gebraucht :-)

Um mal auszuloten, ob an den Fuses tatsächlich das ankommt was Du möchtest, könntest Du mal folgendes machen:
Häkele einfach einen Code, der einen Port alle 1Mio Taktzyklen toggelt.
z.B. so:

Code:

---

...
DDRX.Y = 1
Dim Zahl as Byte
Config timer1 = timer
On Timer1 ISR1
Enable Timer1
Enable Interrupts

Do

If Zahl = 20 then
 Zahl = 0
 Toggle PortX.Y
End if

Loop

ISR1:
Zahl = Zahl + 1
Timer1 = 15535
Return

---

Und an diesen PortX.Y hängste eine LED dran. Und dann stellst Du mal den internen RC-Oszillator auf 1, 2, 4 und 8MHz (LowByte 0xC1, 0xC2, 0xC3 und 0xC4). So könntest Du schon mal eindeutig erkennen, ob das LowByte korrekt programmiert wurde. Und vielleicht kommt dann ja etwa Licht ins Dunkel, was das Auslesen und Programmieren anbetrifft...

Bin gespannt, wie´s weitergeht!

Hallo Sauerbruch,

habe das Testprogramm wie folgt geschrieben:

$regfile = "m8def.dat"
$crystal = 16000000
$framesize = 32
$hwstack = 8
$swstack = 16
$baud = 9600

Ddrc.0 = 1

Dim Zahl As Byte

Config Timer1 = Timer
On Timer1 Isr1
Enable Timer1
Enable Interrupts

Do
If Zahl = 20 Then
Zahl = 0
Toggle Portc.0
End If
Waitms 10
Toggle Portc.0
Loop

Isr1:
Zahl = Zahl + 1
Timer1 = 15535
Return

End

Die LED war dauernd an. Dann habe ich in die Loop Waitms 10 und Toggle geschrieben und die High Fuse auf D9 und die Low fuse auf C1 gesetzt und write an der Fuse-Zeile gedrückt. D9 - C2 bis D9 - C4 ---> write und jedesmal hat die LED schneller geblinkt. Die CPU hat die Frequenzwahl also angenommen. Jetzt hat mich der Teufel geritten und ich habe die Low Fuse von C4 auf DF gesetzt ( Ext. 16 Mhz) --> write. Nun hat die LED im 10 Sec. Abstand geblinkt. Als ich wissen wollte, was die CPU angenommen hatte und an der Fuse-Zeile read gedrückt habe, stand da nicht mehr D9 - DF, sondern DF - D9. Zur Verification habe ich wieder, renitent, wie ich bin, D9 - C1 (1 Mhz int) eingetippt und write gedrückt und die LED hat wieder langsam geblinkt. Mit C2 bis C4 wieder schneller. Jedesmal wenn ich read drücke, tauschen sich High und Low Bytes aus.
Das verstehe einer, wer will.
Gruß Lutz27

Zitat:

---

Jedesmal wenn ich read drücke, tauschen sich High und Low Bytes aus.

---

Das ist in der Tat putzig - und verstehen tu ich es auch nicht. Aber es scheint ja, als ob Du zumindestens mal einigermaßen sicher die Fuses setzen kannst, wie Du sie brauchst.

Und wenn Du mal ein anderes Programm zum auslesen und schreiben der Fuses benutzt??

Hallo Sauerbruch,

also so sicher mit dem Fuses setzen bin ich mir da nicht. Habe heute den Tag über rumprobiert und den Original Chip (Hexfile) ausgelesen und abgespeichert und mir auch die Optionen genau aufgeschrieben. Danach habe ich einen neuen ATMEGA8 mit den Daten programmiert und er hat zwar funktioniert, aber nur jeden 4. Buchstaben gezeigt. Daraufhin habe ich das Lowfuse von DF (16 MHz/ +4ms) auf FF (16 MHz + 64ms) gesetzt und siehe da, es hat funktioniert. Von ELEKTOR habe ich mir der Quellcode bas - file heruntergeladen, ohne Änderung compiliert und versucht erneut mit genau den Optionen wie vorher zu flashen und das hat wieder nicht funktioniert, das heißt, die Anzeige war jeder 4. Buchstabe, egal, ob mit lowbyte DF oder FF.
Eins habe ich gelernt, ich muß in den Fusebytes solange D9FF eingeben, bis im Text nach dem write Befehl steht Byte 0 ---> FF (lowbyte) und Byte 1 ---> D9 (highbyte). damit verfuse ich wenigstens die CPUs nicht mehr, auch wenn die Anzeige in den Fusebyte - Fenstern nicht stimmt. Wichtig ist, was unten links im Text steht.
Aber das Ändern des Textes habe ich noch nicht hinbekommen, obwohl ich mindestens 10cm hochgesprungen bin, da ich jetzt schon 2 funktionierende CPUs habe.
Gruß Lutz27