Forum: Mikrocontroller und Digitale Elektronik ATTINY13: Noch ein CLKPR Unfall - bei HVSP Programming


von John S. (student)


Lesenswert?

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!

von spess53 (Gast)


Lesenswert?

Hi

>Ist HVSP grundsätzlich "gefährlicher" als ISP ?

Nein. Was hast du für ein Netzteil am STK?

MfG Spess

von John S. (student)


Lesenswert?

12 Volt, 450 mA Steckernetzteil!

von spess53 (Gast)


Lesenswert?

Hi

OK. Das sollte eigentlich reichen.

MfG Spess

von Jens (Gast)


Lesenswert?

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ß

von John S. (student)


Lesenswert?

Ich habe aber per HVSP geflashed !!!

Und nun bekomme ich trotzdem nicht den MC gestartet (scheint mir).

Grüße

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von John S. (student)


Lesenswert?

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!

von John S. (student)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von John S. (student)


Lesenswert?

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
Noch kein Account? Hier anmelden.