Hallo,
ich habe zwei Tiny25, einen in einem Board einen im STK500, beide lassen
sich nicht mehr per ISP programmieren, nachdem die Fuses auf den
internen 128kHz Oszillator umgestellt wurden, egal welche ISP Clock man
setzt. HV Serial Prog. geht noch (auf dem im STK500) und das Programm
drauf läuft auch, die Chips selbst sind also OK.
Angehängt ist ein Bild der Fuses frisch aus dem Tiny ausgelesen.
Weiß jemand eine Lösung für das Problem?
Ich kann eine 128kHz Takt zwar mit dem Clock Prescaler von dem 8MHz Osc.
ableiten, würde es aber lieber ordentlich machen.
Danke für Hilfe
Daniel
Depending on CKSEL Fuses, a valid clock must be present. The minimum low
and high periods for the serial clock (SCK) input are defined as
follows:
Low: > 2 CPU clock cycles for fck < 12 MHz, 3 CPU clock cycles for fck
>= 12 MHz
High: > 2 CPU clock cycles for fck < 12 MHz, 3 CPU clock cycles for fck
>= 12 MHz
Oder umgekehrt: die ISP-Frequenz muss kleiner als 1/4 des Systemtaktes,
also der 128 kHz, sein.
Noch ein interessanter Nachtrag:
Nachdem ich den Chip im STK500 per HV wieder auf 8Mhz Osc. umgestellt
habe, lässt er sich trotzdem nur mit einer ISP Clock von <= 14khz
programmieren.
S. Landolt schrieb:> Oder umgekehrt: die ISP-Frequenz muss kleiner als 1/4 des Systemtaktes,> also der 128 kHz, sein.
Der Faktor ist mir bekannt. Wie oben geschrieben, habe ich es mit
jeglicher möglichen IPS Clock (bis runter zu 1kHz) getestet. Leider ohne
Erfolg.
S. Landolt schrieb:> Ist vielleicht auf dem uC ein Programm vorhanden, in welchem CLKPR> gesetzt wird?
LOL
Das wird sogar ziemlich sicher so sein, denn das ist die einzig
verbleibende logische Erklärung. Man könnte sogar aus den Angaben des TO
ermitteln, auf was genau CLKPR gesetzt wird.
Die Fragen sind also eigentlich:
1) Geschieht das absichtlich oder ist das Folge eines Programmfehlers?
2) Wenn absichtlich: warum weiß der TO nicht, dass das relevant ist?
Ja, im Programm ist ein CLKPR vorhanden. Aber inwiefern ist der relevant
für die ISP Clock?
Reset ist low bei Programmieren, daher sollte der CLKPR zurückgesetzt
sein und die System Clock auf maximaler Frequenz.
Dem ist nicht so; das wurde hier im Forum vor Jahren mehrfach in aller
Breite diskutiert, seit längerem aber nicht mehr, es wussten dann wohl
alle Bescheid.
Es hängt auch vom Programmiergerät ab. Eine Möglichkeit ist, wenn ich
mich nicht täusche, zu Programmbeginn ein oder zwei Sekunden zu warten,
bis man CLKPR setzt.
Daniel schrieb:> Reset ist low bei Programmieren, daher sollte der CLKPR zurückgesetzt> sein und die System Clock auf maximaler Frequenz.
Das habe ich auch mal gedacht, ist aber nicht so.
Was du aber tun kannst ist, den Reset Pin fest mit Low verbinden und
dann erst die Stromversorgung einschalten. Dann startet Programm nicht,
programmieren geht aber.
Vielen Dank für die Info. Im DB findet man dazu leider garnichts bzw.
genau das verhalten das vorhin beschrieben habe:
>If CKDIV8 is unprogrammed, the CLKPS bits will be reset to “0000”.
Dieser Reset scheint aber wohl nicht während RESET = low stattzufinden,
sondern beim "hochfahren" des uC.
Jetzt klappt es auch mit dem 128kHz Osc.
Daniel schrieb:> Ja, im Programm ist ein CLKPR vorhanden. Aber inwiefern ist der relevant> für die ISP Clock?
Vollkommen relevant.
> Reset ist low bei Programmieren, daher sollte der CLKPR zurückgesetzt> sein und die System Clock auf maximaler Frequenz.
Nein. CLKPR wird erst in dem Moment zurückgesetzt, wenn Reset wieder
high wird. Böse Falle. Sollte in den DBs besser erklärt werden. Die
setzen voraus, dass jeder weiss, dass ein Reset erst abgeschlossen ist,
wenn er abgeschlossen ist (also nicht mehr anliegt). Und die
Dokumentation bezüglich der Reset-States der SFIO-Register bezieht sich
auf genau diesen Moment.
Es gibt übrigens noch etliche andere SFIO-Register, die erst zum
Reset-Ende ihren dokumentierten initialen Zustand annehmen. Genau
genommen sind es sogar fast alle. Eigentlich reagieren nur die
DDRx-Register und ein paar wenige weitere Exoten (im NVM-Controller) auf
die fallende Flanke des Reset-Signals.
c-hater schrieb:> Dokumentation bezüglich der Reset-States der SFIO-Register bezieht sich> auf genau diesen Moment.
Würdest du mir schnell sagen wo ich die angesprochene Doku finde? Im DB
finde ich dazu nichts, oder ich suche nach den falschen Begriffen.
Daniel schrieb:> Würdest du mir schnell sagen wo ich die angesprochene Doku finde? Im DB> finde ich dazu nichts, oder ich suche nach den falschen Begriffen.
Soweit mir bekannt ist, steht das nirgends im Datenblatt. Ich bin auch
darüber gestolpert und hatte nach nach einer Erklärung gesucht - keine
gefunden.
Der Effekt ist aber eindeutig reproduzierbar. Ich bin beim ATtiny13A
darauf gestoßen und konnte es auch mit einem ATmega328P reproduzieren.
Wenn du Reset schon auf Low ziehst und hältst, bevor die Stromversorgung
eingeschaltet wird, läuft er auf der Frequenz, die durch die Fuses
vorgegeben sind.
Wohl ein Missverständnis - ich denke, c-hater meint den 'Initial value',
der im Datenblatt bei jedem SFR angegeben ist, zumindest verstehe ich so
sein
> Dokumentation bezüglich der Reset-States der SFIO-Register
Daniel schrieb:> Würdest du mir schnell sagen wo ich die angesprochene Doku finde? Im DB> finde ich dazu nichts
Ja, das ist so. Leider. Nicht wirklich deine Schuld, es sollte wirklich
besser im DB dargestellt sein. Ist es aber eben nicht.
Naja, das Einzige, wo die Sache normalerweise praktische Relevanz
bekommt, ist halt das CLKPR-Register. Und das auch nur beim
Programmieren eines nicht fabrikneuen Chips. Also in einer Situation,
die den Verkäufer von Millionenstückzahlen schlicht nicht sonderlich
interessiert.
Unbenannt.png
(50 KB)
