Habe augenscheinlich (auch) einen CKLPR Unfall - allerdings beim HVSP Programming eines ATTiny13 mit einem STK500. Habe den folgenden Hinweis gefunden, allerdings ist mir der Hintergrund nicht klar: Extra precaution should be made when using the CKDIV fuse and/or Clock Prescaler Register (CLKPR) on parts supporting this. Wie soll ich das verstehen ? Augenscheinlich habe ich genau hiergegen verstoßen, indem ich CLKPR |=(1 << CLKPS0); gesetzt habe und bei CKDIV8 ein Häkchen gemacht habe. Zudem habe ich die folgende Weisung nicht korrekt eingehalten To avoid unintentional changes of clock frequency, a special write procedure must be followed to change the CLKPS bits: 1. Write the Clock Prescaler Change Enable (CLKPCE) bit to one and all other bits in CLKPR to zero. Wie sieht denn für ein GLEICHZEITIGES Schreiben die Befehlszeile in C aus ? Etwa so ? CLKPR |= (1 << CLKPCE) & ~((1 << CLKPS0) | (1 << CLKPS3) | (1 << CLKPS2) | (1 << CLKPS1)) 2. Within four cycles, write the desired value to CLKPS while writing a zero to CLKPCE. Und demenstsprechend die folgende so ? CLKPR &= ~(1 << CLKPCE) | (1 << CLKPS0) | (1 << CLKPS3) | (1 << CLKPS2) | (1 << CLKPS1) Der Chip läßt sich noch programmieren (Programmverifzierung sagt o.k., bei den Fuses ebenfalls), aber augenscheinlich läuft der Prozessor nicht an. Nun meine Frage: Ich dachte, ich verändere mit CLKPR nur "temporär" den Prescaler, soll heißen mit einem neu geflashten Programm (ohne CLKPCE Veränderung im Programm) ist die Welt wieder in Ordnung. Kann es sein, dass die Veränderung dauerhaft (fehlerhaft) ist ? Aber wieso läßt sich der Chip dann noch programmieren? Für das Flashen braucht er doch auch einen Takt. Oder habe ich hier etwas grundsätzliches mißverstanden ? Ist HVSP grundsätzlich "gefährlicher" als ISP ? Grüße un Danke!
Hi
>Ist HVSP grundsätzlich "gefährlicher" als ISP ?
Nein. Was hast du für ein Netzteil am STK?
MfG Spess
Hi OK. Das sollte eigentlich reichen. MfG Spess
Wenn du bei ISP-Programming-Mode den Takt so verstellst, das der Controller nicht mehr den internen Takt verwendet, sondern den extern angelegt haben möchte, kannst du den mit ISP nicht mehr zurückstellen. Es fehlt ja der Takt. Aber bei HVSP ist das anders. Der Controller ist nicht mehr auf den Takt angewiesen. Das ist ja grad das schöne, dass du den Controller mit der Methode immer wieder retten kannst! Gruß
Ich habe aber per HVSP geflashed !!! Und nun bekomme ich trotzdem nicht den MC gestartet (scheint mir). Grüße
John Schmitz schrieb: > Extra precaution should be made when using the CKDIV fuse and/or Clock > Prescaler Register (CLKPR) on parts supporting this. > > Wie soll ich das verstehen ? Vielleicht schreibst du ja dazu, wo du das gefunden hast? > Augenscheinlich habe ich genau hiergegen verstoßen, indem ich > > CLKPR |=(1 << CLKPS0); > > gesetzt habe und bei CKDIV8 ein Häkchen gemacht habe. CKDIV8 ist ja standardmäßig aktiv, damit läuft der Prozessor mit einem Vorteiler von 8 an. Der Grund ist, dass ein Betrieb mit den vollen 9,6 MHz nicht über den gesamten Betriebsspannungsbereich garantiert wird. > Zudem habe ich die folgende Weisung nicht korrekt eingehalten Dann wird deine Prescaler-Änderung einfach ignoriert. > > 1. Write the Clock Prescaler Change Enable (CLKPCE) bit to one and all > other bits in > CLKPR to zero. > > Wie sieht denn für ein GLEICHZEITIGES Schreiben die Befehlszeile in C > aus ? > Etwa so ? > CLKPR |= ... Warum willst du den partout etwas ver-ODER-n? Nein, diese Anweisung ist kompletter Unsinn. Nimm sie mal auseinander (also: aus a |= b; machst du a = a | b;) und schreib sie bitweise auf, dann sollte dir klar werden, was du da fürn Quatsch gezimmert hast.
1 | CLKPR = (1 << CLKPCE); |
2 | CLKPR = (1 << CLKPS0); |
Mal in der Annahme, dass du CLKPS0 setzen willst, also einen Vorteiler von 2 haben möchtest. Für Vorteiler 1 müsstest du als zweiten Schritt eine 0 schreiben. Funktioniert aber im AVR-GCC nur dann, wenn du die Optimierungen einschaltest, sonst wird der Code u. U. zu langsam für die vier- Takte-Zeitforderung. Besser ist daher:
1 | #include <avr/power.h> |
2 | |
3 | ...
|
4 | clock_prescale_set(clock_div_2); |
> Der Chip läßt sich noch programmieren (Programmverifzierung sagt o.k., > bei den Fuses ebenfalls), aber augenscheinlich läuft der Prozessor nicht > an. Dann hast du sehr wahrscheinlich was ganz anderes vergurkt.
John Schmitz schrieb: > John Schmitz schrieb: > >> Extra precaution should be made when using the CKDIV fuse and/or Clock >> Prescaler Register (CLKPR) on parts supporting this. >> >> Wie soll ich das verstehen ? > > Vielleicht schreibst du ja dazu, wo du das gefunden hast? Ich meine, in Verbindung mit der STK500 Handhabung, weiß aber nicht mehr ganz genau. Der ATTiny13 unterstützt doch genau diese Modi- daum fühlte ich mich angesprochen. Danke!
Jörg Wunsch schrieb: > Funktioniert aber im AVR-GCC nur dann, wenn du die Optimierungen > einschaltest, sonst wird der Code u. U. zu langsam für die vier- > Takte-Zeitforderung. Besser ist daher: > #include <avr/power.h> > > ... > clock_prescale_set(clock_div_2); Danke - das kannte ich noch gar nicht. Werde einen neuen ATTiny13nehmen und schauen, was dann passiert. Grüße
John Schmitz schrieb: > Der ATTiny13 unterstützt doch genau diese Modi- daum fühlte ich mich > angesprochen. Jeder moderne AVR hat das. John Schmitz schrieb: > Werde einen neuen ATTiny13nehmen > und schauen, was dann passiert. Nimm doch den, den du hast. Du vermutest doch bisher nur, dass er nicht mehr gehen würde. Bei deinen weiter oben gezeigten C-Künsten (sorry) würde es mich nicht wundern, wenn du einfach völlig normale Bugs in deinem Code hast, die dich zu dieser Vermutung führen. Schreib doch einfach erstmal ein Minimalprogramm in den existierenden Baustein, völlig ohne CLKPR, alle Fuses auf Standardeinstellung, und lass ihn mit einem IO-Pin wackeln. Dann guckst du dir an einem Oszi an, ob das Pin auch wirklich wackelt. Dann gehst du einen Schritt weiter, nimmst die Prescaler-Einstellung rein, und guckst am Oszi, ob sich die Frequenz des Pins geändert hat.
Jörg Wunsch schrieb: > Schreib doch einfach erstmal ein Minimalprogramm in den existierenden > Baustein, völlig ohne CLKPR, alle Fuses auf Standardeinstellung, und > lass ihn mit einem IO-Pin wackeln. Dann guckst du dir an einem Oszi > an, ob das Pin auch wirklich wackelt. Er wackelt - danke! Man sollte nicht mitten in der Nacht Fehlersuche begehen ...! Die CLKPR settings waren sicherlich ein untauglicher Versuch ein ganz anderes Problem zu beheben (Umschreiben eines Timer getriggerten Programms von einem 16 Bit Timer auf einen 8 Bit Timer). Schnellschüsse lohnen nicht ! Aber ich habe etwas wichtiges gelernt, es gibt eine Routine in der Library, die mir die Thematik erledigt - Klasse! Danke für die Hilfe.
Bitte 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.