www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATMEGA88 kaputtprogrammiert --- NICHT via Fuse-Bits!


Autor: Daniel Weiss (daniel2008)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe folgendes Problem:
Ich habe ein kleines Testprogramm geschrieben (mit CodeVisionAVR
evaluation), das auch einwandfrei lief.
Dann habe ich im Anwendungsprogramm, das auf dem Controller ausgeführt
wird, das Register CLKPR verändert, um den Taktteiler auf 256 zu
setzen. (zuerst CLKPR=0x80, dann [max. 4 Takte später] CLKPR=0x08)

Leider ohne vorher die Interrupts zu deaktivieren (jedoch sollte das
schlimmstenfalls dazu führen, dass die Anweisung wirkungslos ist; ein
125 kHz-Timer-IRQ ist zu dem Zeitpunkt übrigens bereits aktiv) und noch
dazu innerhalb einer while-Schleife, die alle 10 mS Wiederholt wird. Ein
4-Sekunden-Watchdog-Timer ist auch aktiv und wird in der Schleife direkt
vor den Beiden Zuweisungen für die Taktänderung zurückgesetzt.

[b]Nun hat diese Programmänderung aber dazu geführt, dass der
Controller zwar Strom spart (0,35 mA statt 4 mA), aber weder das
Programm ausführt, noch sich neu Flashen lässt.[/b]

Ich habe ihn also IM ANWENDERPROGRAMM de facto "zerstört", wie mir
scheint. Wahrscheinlich startet er dank auf 0 ms eingestellter
SUT-Fuses so schnell, dass der Programmer nach dem Reset gar nicht mehr
dazu kommt, ihn in den Programmiermodus zu versetzen. (Schade, dass
Atmel nicht sowas vorgesehen hat, wie "10 kHz oder mehr am Reset-Pin
== programmiermodus aktivieren, egal was man wie falsch gesetzt hat)

Beim nächsten Versuch werde ich auf jeden Fall testweise als erstes 300
ms Delay einbauen, bevor das eigentliche Programm losläuft.

Vielleicht ist es wihctig, insbesondere die SUT-Bits spielen bei dem
Problem evtl. eine Rolle, könnte ich mir vorstellen, deshalb hier die
Fuse-Bits, die ich gelöscht habe (das sind die mit 0 hinter dem "=",
bzw. 1 in Klammern dahinter, letztere verquere invertierte "Logik"
kann man dann 1:1 so auch im Datenblatt lesen):
CKSEL0=0 (1)
CKSEL1=1 (0)
CKSEL2=0 (1)
CKSEL3=0 (1)
SUT0=0   (1)
SUT1=0   (1)
WDTON=0  (1)

(die Zahlen hinter dem "="-Zeichen gelten für die tatsächlichen Werte
der Fuse-Bits, die Zahlen in Klammern geben die invertierten Werte an,
wie sie irgendein zerstreuter Professor bei Atmel sich ausgedacht hat
[mal ehrlich: Atmel definiert bei den Fuse-Bits mal eben die 1 als 0
und umgekehrt... was soll das, außer Verwirrung stiften?])


Tja, weiß vielleicht jemand die Lösung, ggf. auch für andere Leute mit
dem gleichen Problem? Üblicherweise "zerschießt" man sich ja den
Controller, weil man die wirre invertierte Notation der Fuse-Bits
durcheinanderbringt, hier habe ich aber mal eine neue Möglichkeit
ausgegraben, einen Atmel unbrauchbar zu machen, wie's scheint... ganz
ohne Fuse-Bits, rein per Programmcode... :-/

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich deine Bitverdreherei und das Datasheet richtig verstehe, hast
Du einen 3-8MHz Resonator eingestellt, mit 65ms Einschwingzeit. Passt
das?

ISP findet bei aktivem Reset statt, das Programm kommt also garnicht
zum Zuge. Einzige Voraussetzung ist ein vorhandener Controller-Takt,
wobei es zwischen dem Tempo des ISP-Takts und dem Controller-Takt
allerdings eine Beziehung gibt, d.h. der ISP-Takt muss deutlich unter
dem Controller-Takt liegen.

Autor: mmerten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim AVRSTUDIO 4.11 in Verbindung mit STK500/AVRISP hat man als Option
extrem niedrige ISP Raten eingebaut für solche Fälle, oder halt mit
Parallel-Programmierung zurücksetzen.

Autor: Daniel Weiss (daniel2008)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A.K. (Andreas Könemann?)
Nein, die Einstellung ist 8 MHz internal calibrated RC resonator, habe
es oben leider genau falsch rum erklärt.  Ich habs' also gerade mal
wieder erfolgreich durcheienadergebracht...
SUT sind 14 Takte + 4,1 ms. (Nicht 0 ms wie ich oben geschrieben
hatte)

Hier nochmal die Fuse-Bits 0, 2 und 3 aktiviert (also gelöscht):
Ich habe also CKSEL 3..0 auf
0010 gesetzt (Datenblatt S.26, 7.2, Tabelle 7-1)
Und SUT0 und SUT1 auch aktiviert (also gelöscht), also:
00 (S. 28, Tabelle 7-4)


Lief ja auch alles, solange bis ich die Befehle
CLKPR=0x80
CLKPR=0x08
noch mit eingebaut habe.

---> Vielleicht habe ich auch das auf "S.349, 33.2.3, Rev.A, 2."
beschriebene Problem:
"...wenn man den System-Clock Prescaler innerhalb der ersten 10
Nanosekunden nach dem Booten ändert, hängt sich der Controller auf..."
Und nach dem Einschalten rennt er ja erstmal mit 8 MHz los (CKDIV8 Fuse
habe ich nicht aktiv), allerdings setzt auch der von Codevision
erzeugte Code den Prescaler, noch dazu an viel früherer Stelle.
(allerdings auf 1, also CKPR=0x80; CLKPR=0x00; )
Atmel scheint nicht vor zu haben, das Problem zu beheben, denn der Bug
für Chip-Revision A, dass das EEPROM nur ab 4,5V programmiert werden
kann ist immerhin mit dem Hinweis "This will be fixed in Revision B"
versehen... beim Hardware-Bug mit dem Prescaler allerdings wird
stattdessen einfach empfohlen, den Prescaler nicht zu verändern...


Dass der Controller nun zu langsam für das Programmiergerät läuft kann
eigentlich nur dann sein, wenn der Controller sich nach dem ändern von
CLKPR durch einen Reset nicht wieder auf die 8 (oder 1 MHz) zurücksetzt,
was ich mir aber nicht vorstellen kann. Denn CLKPR wird ja im
Programmcode verändert, der aber dürfte ja gar nicht ausgeführt
werden.
(Oder wird die per Software in CLKPR eingestellte Teilerrate etwa
permanent im EEPROM gespeichert? Kann ich mir eigentlich nicht
vorstellen)
Ich kann ja mal versuchen, Reset mit einem Pulldown, statt einem Pullup
zu versehen, so dass der Controller nach dem Anlegen der Spannung gar
nicht erst losrennt...


Als Programmiergeärt habe ich das Atmel STK500 --- kann man da was
einstellen an der Geschwindigkeit? (habe mir die beigelegte CD noch gar
nicht angeguckt).

Vielen Dank jedenfalls für die schnellen und ganz guten Ideen. Nur
fürchte ich, dass ich vermutlich den Controller letztlich doch
wegwerfen kann, wenn ich mal alles genau durchüberlege... :-(

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem STK500 solltest Du den Spuk auch per paralleler Programmierung
loswerden können, da braucht's auch keinen Takt für.
ISP-Geschwindigkeit lässt sich bei Programmierung via STK500 wie von
mmerten erwähnt einstellen.

Was die Bitverdreherei angeht: Ich hatte aus deiner Irritation
geschlossen, dass dir der STK500 nebst Programmierung via Atmel Studio
nicht zur Verfügung steht. Denn wie konfus Atmel das auch gemacht hat,
mit dem Studio lassen sich die Fuses m.E. nur mit Absicht falsch
einstellen.

Der Bug klingt nicht so ganz passend. Immerhin ist der von sehr
stochastischer Natur, kaum systematisch hinzukriegen.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"auch aktiviert (also gelöscht)"

Mit dieser Sprachregelung stellst Du dir selber ein Bein. Atmel:
0=programmed, 1=unprogrammed. Du: 0=gelöscht. Gibt programmed=gelöscht
und unprogrammed=gesetzt, folglich also gewissermassen
ungelöscht=gelöscht. Kein Wunder das Du dabei konfus wirst.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> [mal ehrlich: Atmel definiert bei den Fuse-Bits mal eben die 1 als 0
> und umgekehrt... was soll das, außer Verwirrung stiften?])

Nunja, das hat sich kein verwirrter Prof ausgedacht, das ist
physikalisch, technologisch und historisch bedingt.

Wenn du einen etwas älteren nichtflüchtigen Speicher (EPROM) löscht
(UV-Licht bei EPROM), dann stehen da nicht etwa Nullen (Low) drin,
sondern Einsen (High). Und durch das Programmieren werden die
jeweiligen Bits auf 0 (Low) gesetzt.
Somit ist die Aussage, dass ein programmiertes Bit Low bzw 0 ist,
schonmal richtig.

Gewöhne dir möglichst schnell diese Betrachtungsweise an, dann
verhedderst du dich auch nicht mehr.

Die physikalischen Gesetze stehen nunmal nicht im Gesetzbuch, du kannst
sie also weder ändern, noch umgehen noch ignorieren. Du kannst dich nur
danach richten oder verzweifeln...

...

Autor: Daniel Weiss (daniel2008)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin noch recht frisch in dem Bereich, habe zwar schon ein wenig
rumprogrammiert, hatte die Fuse-Bit-Einstellungen aber vorgekaut
bekommen.
also werde ich wohl mal die CD einlegen und AVRStudio hernehmen (habe
codevisionAVR genommen, da kann man lediglich den COM-Port einstellen,
an dem der STK500 läuft)
Danke für die Hilfe, melde mich dann, falls ich ihn wiederbeleben
konnte :-)

Autor: Daniel Weiss (daniel2008)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,   ER *LEBT* WIEDER ! <freu über gesparte Lötarbeit>

...es hat mir keine Ruhe gelassen und ich habe nun doch noch schnell
AVRStudio draufgebügelt... es war tatsächlich so, dass der Programmer
zu schnell für 32 kHz Prozessortakt eingestellt war!

Habe ihn auf 4 kHz runtergeschraubt und danach hat er dann mit dem
Controller wieder geredet. Es ist also offensichtlich tatsächlich so,
dass der Controller sich nach dem man CLKPR verändert hat nach einem
durch den Programmer ausgelösten reset NICHT auf mindestens 1 MHz
zurückstellt, sondern den veränderten Wert beibehält. (Wenn Reset
während der gesamten Programmierung auf Low ist) Da hat Atmel offenbar
nicht dran gedacht beim Hardware-Design...
(Wahrscheinlich wird erst bei High-Flanke neu initialisiert)

Vorher war er auf 14 kHz eingestellt (das hatte ich danach aber nicht
mehr zur Auswahl, aber egal, habe ihn nun auf 57600 kHz eingestellt)
Der Prozessor muss mindestens um Faktor 4 höher getaktet sein als der
Programmer.

Danke für die schnelle und kompetente Hilfe! Wohin soll ich das Bier
liefern? ;-)


PS: einen zweiten Programmer, den ich als defekt von der Firma
mitbekommen habe (LED rot, orange, aus, grün hat er noch gemacht wenn
er Saft bekommen hat), konnte ich mit AVRStudio weitgehend updaten, bis
dann beim verify was falsches zurückkam, nun macht er gar nix mahr, na,
egal -> Tonne) Hat vermutlich mal 'nen Spike aus dem Netz abbekommen
oder so...



Eine Frage noch: welche Frequenz sollte man für den Programmer
einstellen? geht ja bis 900 kHz hoch --- ist das Flash-ROM überhaupt so
schnell? (und der COM-Port macht ja auch max. 115200bps)

Autor: Daniel Weiss (daniel2008)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ich nun gar nicht kapiere: bis Teiler 128 (CLKPR=0x07) kann ich den
Programmer mit 921,6 kHz betreiben, es rast dann nur so (erase,
program, verify, alles zusammen keine 5 Sekunden!)
Erst bei Teiler 256 (CLKPR=0x08) geht es nicht mehr, DANN sind selbst
14 kHz am Programmer schon zu schnell.
(CKDIV8-Fuse nicht programmiert, startup also immer mit 8 MHz)

Aber wieso gehen dann bei ab 62500 Hz MCU-Takt trotzdem 921,6 kHz
Programmiergeschwindigkeit? (bei allen anderen Teilern kleiner 256
übrigens auch) das ist zwar nett und praktisch, aber doch irgendwie
inkonsequent und widerspricht dem, was bei AVRStudio steht (ISP
frequncy must be lower than 1/4 MCU clock)

Oder habe ich nun einen Hardware-Bug entdeckt, der sich so äußert, dass
ein Pulldown des Reset-Pins durch den Programmer in allen Fällen AUSSER
wenn der Taktteiler vorher 256 war, den Taktteiler reinitialisiert?

Auch egal, es läuft nun jedenfalls... :-)

Autor: Daniel Weiss (daniel2008)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen letzten hab' ich noch für heut Nacht, dann geht's ENDLICH ins
Bett!
-> da standardmäßig die CKDIV8-Fuse programmiert ist, ist es nicht
ratsam, den Programmer auf mehr als 230,4 kHz einzustellen, da man
sonst Fabrikneue MCUs gar nicht programmieren kann, da sie mit 1 MHz
starten...

Durch die Befehle:

#asm("cli")
CLKPR=0x80;  // unlock prescaler altering protection
CLKPR=0x04;  // set prescaler to 8
#asm("sei")

ändert sich nix, durch:

#asm("cli")
CLKPR=0x80;  // unlock prescaler altering protection
CLKPR=0x00;  // set prescaler to 1
#asm("sei")

erreicht man das gleiche, wie durch lösen der CKDIV8-Fuse (nämlich 8
MHZ Takt)
ggf. Interrupts nicht mit dem Asembler-Befehl "sei" hart einschalten,
sondern vor dem Abschalten den Zustand merken und dann wiederherstellen.

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.