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... :-/
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.
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.
@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... :-(
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.
"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.
> [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... ...
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 :-)
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)
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... :-)
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.
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.