Hallo,
ich nutze einen Attiny45 mit 16MHz PLL µC Takt.
Die zugehörigen Fusebits in Avrdude-Schreibweise sind:
-U lfuse:w:0xf1:m -U hfuse:w:0xdd:m -U efuse:w:0xff:m
Wenn der Attiny45 seine "Arbeit" getan hat, setze ich
a) den µC Clockvorteiler auf 1/16 also 1MHz µC Takt und
b) versetze ihn dann in den Sleep Mode "ADC Noise Reduction".
Will ich dann per ISP eine neuen Programmcode aufspielen und testen, so
kann ich den Attiny45 nicht mit 2MHz ISP-Takt beschreiben.
Die Frage ist: /warum ist das so ?/
Ich muss den ISP-Takt auf 1MHz/4, also kleiner als 250kHz setzen !
Sehr eigenartig.
Also suche ich Erfahrungen mit diesem Phänomen und evtl. auch eine
Referenz/ Verweis im Datenblatt.
#Vielen Dank#
Der Aufruf im Hauptprogramm (LunaAVR) ist:
1
'morecode..
2
avr.Interrupts.disable
3
AVRClock.Prescaler=16
4
Powerdown.Now=adcdenoise
5
halt()
Hier sehr ihr den Inhalt, der von mir geschriebenen
Bibliotheksfunktionen.
Der Aufruf Bibliotheksfunktion |AVRClock.Prescaler = 16| wird wie folgt
codiert:
Ich beobachte das Gleiche, auch bei ATmegas, hatte bislang den Effekt
aber auf mein Eigenbau-Programmiergerät geschoben und mich nicht weiter
darum gekümmert.
user schrieb:> Der ISP Takt darf maximal 1/2 oder 1/4 des internen Takts sein.
Ja das ist uns Programmierern bekannt: der Takt ist auf 16MHz gesetzt,
siehe oben im Test - nur scheinbar gilt das nicht bei der
ISP-Programmierung.
Hallo S. Landolt schrieb:>> der Takt ist auf 16MHz gesetzt> Zu dem Zeitpunkt, an welchem das Reset für das ISP kommt, eben nicht, da> ist der Takt 1 MHz.
Ich dachte eher an: CPU-Takt=0,5MHz * 16 = 8MHz RC-Oszillator, da
CKDIV8=1 ist.
> Ich dachte eher an: CPU-Takt=0,5MHz * 16 = 8MHz RC-Oszillator
Verstehe ich nicht ganz, Sie schreiben doch
> a) den µC Clockvorteiler auf 1/16 also 1MHz µC Takt
Lbr Spess,
nichts anders steht da, im Datenblatt:
8MHz RC Oszillator x8 PLL = 64MHz;
der CPU Takt wird durch einen weiteren Vorteiler von /4 auf 16MHz
festgelegt.
Die Frage ist, welche Taktfrequenz liegt bei einem Soft-Reset (ISP
Programmer) an der CPU an, wenn die obigen Einstellungen vorgenommen
wurden und der Clock-Prescaler auf 1/16 steht ?
>Die Frage ist, welche Taktfrequenz liegt bei einem Soft-Reset (ISP>Programmer) an der CPU an, wenn die obigen Einstellungen vorgenommen>wurden und der Clock-Prescaler auf 1/16 steht ?
Der Takt der über die Fuses eingestellt ist.
Was in deinem Programm passiert interessiert da nicht.
Holger schrieb:
> Der Takt der über die Fuses eingestellt ist.> Was in deinem Programm passiert interessiert da nicht.
Welches Programmiergerät verwenden Sie? Und können Sie etwas über dessen
Programmierablauf sagen?
Hallo Holger,
die Logik zeigt mit, dass das so leider nicht ist, da der ISP-Takt auf
<250kHz gestellt werden musste, mit aktivierten Clock-Prescaler auf 1/16
im Sleep-Mode.
Lasse ich den Clock-Prescaler auf 1, so kann ich mit 2MHz ISP-Takt
weiter arbeiten.
Aber wo ist das Dokumentiert ?
S. Landolt schrieb:> Holger schrieb:>> Der Takt der über die Fuses eingestellt ist.>> Was in deinem Programm passiert interessiert da nicht.>> Welches Programmiergerät verwenden Sie? Und können Sie etwas über dessen> Programmierablauf sagen?
Einen USBTinyISP Programmer auf Basis eine Attiny85 der wird von Avrdude
5.11 unter Linux angesteuert.
Beitrag "AVR USBtinyISP Programmer mit atTiny85"
> die Logik zeigt mit, dass das so leider nicht ist
Bei mir auch; als ich einmal einen Stromspartest mit einem ATmega1284
machte, 128 kHz RC mit Vorteiler /256, musste ich anschließend mein
Programmiergerät um eine untere Stufe von 100 Hz erweitern.
>Tja, Uwe, offenbar hat Holger etwas Besseres als wir beide.
Nein, habe ich nicht;)
Vieleicht ist das hier ja das Problem:
The contents of the Register File and SRAM are unaltered when the device
wakes up from
sleep. If a reset occurs during sleep mode, the MCU wakes up and
executes from the Reset Vector.
Wenn man sich das auf der Zunge zergehen lässt könnte man folgendes
interpretieren:
1. Wenn die CPU aus dem Sleep kommt werden keine Register verändert.
2. Bei einem Reset während Sleep wacht die CPU auf und springt an den
Reset Vector.
Von einem echten Hardware Reset ist hier nicht die Rede.
Alle Register bleiben unverändert weil aus Sleep aufgewacht,
und damit auch die letzte Takteinstellung.
Ein bisschen weit hergeholt, ich weiss.
Danke Holger,
genau dass ist die Erklärung, ich hatte bisher Tomaten auf den Augen..
Steht auch im Abschnitt "Power Management and Sleep Modes".
Damit sind unsere Beobachtungen geklärt.
Perfekt. Schönen Abend noch.
-closed-
Ein Test mit einem ATmega48 zeigt, dass der beschriebene Effekt nichts
mit 'sleep' zu tun hat. Es scheint, als käme man nur daran vorbei, wenn
bei gesetztem /reset Spannung an den Controller gelegt wird.
So die Beobachtung mit meinem Eigenbau-Programmiergerät. Für
gegenteilige Hinweise und Lösungsvorschläge wäre ich dankbar; zumal
holger ja schrieb:
> Der Takt der über die Fuses eingestellt ist.> Was in deinem Programm passiert interessiert da nicht.
S. Landolt schrieb:> Ein Test mit einem ATmega48 zeigt, dass der beschriebene Effekt nichts> mit 'sleep' zu tun hat. Es scheint, als käme man nur daran vorbei, wenn> bei gesetztem /reset Spannung an den Controller gelegt wird.
Richtig. Das hat nichts mit Sleep zu tun. Und natürlich kriegt der µC
über den ISP einen "echten Hardware Reset".
Der beobachtete Unterschied ist der zwischen einem external reset und
einem power-on reset. Der letztere setzt alle Register auf ihre
Defaultwerte, der erstere anscheinend nur ein paar; insbesondere scheint
er den Prescaler für den Systemtakt nicht zurückzusetzen, so daß der µC
mit reduziertem Takt weiterläuft.
Das Datenblatt erwähnt davon nichts, sondern sagt im Gegenteil ganz
eindeutig: "During reset, all I/O Registers are set to their initial
values" (in 8.1 Resetting the AVR) und "The CKDIV8 Fuse determines the
initial value of the CLKPS bits. If CKDIV8 is unprogrammed, the CLKPS
bits will be reset to 0000. If CKDIV8 is programmed, CLKPS bits are
reset to 0011, giving a division factor of eight at start up." (in 6.5.2
CLKPR - Clock Prescale Register).
Ich würde das daher für mindestens einen Dokumentations-Bug halten, wenn
nicht gar für einen echten Hardware-Bug.
Axel S. schrieb:> Ich würde das daher für mindestens einen Dokumentations-Bug halten, wenn> nicht gar für einen echten Hardware-Bug.
Weder das eine noch das andere.
Das geschilderte Verhalten zeigt sich weder mit einem AVRISPMKII noch
mit einem JTAGICEMKII. Wohl eher eine Unzulänglichkeit des verwendeten
Programmers, der Entwicklungsumgebung oder sonst irgend etwas, was nur
Kurt erklären kann.
Getestet mit Attiny45 und Atmega168 im Sleepmode PWR_DOWN mit AVR-Studio
und den o.g. Programmern.
mfg.
Thomas E. schrieb:> Axel S. schrieb:>> Ich würde das daher für mindestens einen Dokumentations-Bug halten, wenn>> nicht gar für einen echten Hardware-Bug.>> Das geschilderte Verhalten zeigt sich weder mit einem AVRISPMKII noch> mit einem JTAGICEMKII. Wohl eher eine Unzulänglichkeit des verwendeten> Programmers, der Entwicklungsumgebung oder sonst irgend etwas, was nur> Kurt erklären kann.
Mir ist jetzt nicht klar, was man dabei falsch machen kann, wenn man den
Reset-Pin auf L zieht.
Meine Beobachtung: Nach einem Reset wird der Vorteiler erst mit Ablauf
der start-up-time zurückgesetzt. Bislang hatte ich in meinem
Eigenbau-Programmiergerät eine Wartezeit von 2 ms, was mehr ist als das
von Atmel vorgegebene "... /RESET must be given a positive pulse of at
least two CPU clock cycles duration", aber eben auch nur dann ausreicht,
wenn die Fuses im Controller auf eine kürzere Zeit eingestellt sind
(gilt offenbar auch für den 'USBTinyISP Programmer' von Uwe S.). Bei
längerer start-up-time bleibt die alte Einstellung des Vorteilers
erhalten. Wähle ich 100 ms, so klappt es immer, aber natürlich kann man
sich eine Anwendung vorstellen, in der dann bereits der Vorteiler
umprogrammiert wurde. Außerdem wird das zur Anpassung automatische
Herunterfahren des SPI-Taktes spürbar langsamer. Wie professionelle
Programmiergeräte dieses Dilemma lösen, ist mir unklar.
Axel S. schrieb:> Mir ist jetzt nicht klar, was man dabei falsch machen kann, wenn man den> Reset-Pin auf L zieht.
Das Laden der Default-Werte in die Register geschieht nicht von jetzt
auf gleich. Das hat S.Landolt auch so beobachtet:
S. Landolt schrieb:> Meine Beobachtung: Nach einem Reset wird der Vorteiler erst mit Ablauf> der start-up-time zurückgesetzt.
Das Fehlverhalten des Programmers zeigt sich dann eben darin, dass
dieser nach dem Runterziehen von Reset offenbar sofort loslegt. Dass die
Original-Atmel-Programmer das nicht machen und ein passendes Delay
einfügen, kann man natürlich auch erwarten.
mfg.
S. Landolt schrieb:> Eigenbau-Programmiergerät eine Wartezeit von 2 ms, was mehr ist als das> von Atmel vorgegebene "... /RESET must be given a positive pulse of at> least two CPU clock cycles duration",
In der ISP-Spezifikation steht aber nach dem Reset:
"Wait for at least 20 ms and then enable serial programming by sending
the Programming Enable serial instruction to the MOSI pin"
Ich bin selber schon auf dem RasPi drüber gestolpert:
Beitrag "ATtiny841 per AVRDUDE auf Rasberry Pi programmieren"
A. K. schrieb:> "Wait for at least 20 ms and then enable serial programming by sending> the Programming Enable serial instruction to the MOSI pin"
Na, da kann man ja noch schnell eine Tasse Kaffee trinken, bevor es
losgeht.
MfG Paul
A. K. schrieb:> In der ISP-Spezifikation steht aber nach dem Reset:>> "Wait for at least 20 ms and then enable serial programming by sending> the Programming Enable serial instruction to the MOSI pin"
Danke. Mein Vertrauen in Atmel (die Hardware genauso wie die Doku) ist
damit wiederhergestellt :)
Mir scheint, wir reden aneinander vorbei. Sie zitieren Punkt 2, ich
bezog mich auf Punkt 1:
1. Power-up sequence:
Apply power between VCC and GND while RESET and SCK are set to “0”. In
some systems, the programmer can not guarantee that SCK is held low
during power-up. In this case, RESET must be given a positive pulse of
at least two CPU clock cycles duration after SCK has been set to “0”.
2. Wait for at least 20ms and enable serial programming by sending the
Programming Enable serial instruction to pin MOSI.
Könnte mal jemand mit einem Atmel-Programmer einen Controller
ansprechen, der in den Fuses die kürzestmögliche start-up-time
eingestellt und als Programm nur das Setzen des Vorteilers auf Maximum,
also /256, mit anschließender Endlosschleife (rjmp pc) hat - mit welchem
SPI-Takt geschieht das dann?
(auf eigene Gefahr, für 'abgeschossene' uCs hafte ich nicht)
Woraus willst du damit raus, was bringt dir das?
Beim ATtiny841 konnte ich jedenfalls feststellen, dass die Wartezeit des
programmierten Oszillators beim ISP-Verfahren eine Rolle spielt. Der R/C
Oszillator mit seiner kurzen Startzeit benötigt keine Wartezeit im ISP,
der Quarzoszillator jedoch schon.
Den Auslieferungszustand von 8 MHz / 8 voraussetzend, müsste also nach
der bisherigen Theorie ein SPI-Takt von 230 kHz reichen?
Was mir das bringt? - Erkenntnisgewinn, aber entscheidend wichtig ist es
nicht. Es wäre trotzdem nett, wenn es jemand mal durchführte.
S. Landolt schrieb:> Den Auslieferungszustand von 8 MHz / 8 voraussetzend, müsste also nach> der bisherigen Theorie ein SPI-Takt von 230 kHz reichen?
Ja. Das gilt ziemlich durch die Bank für viele bis alle AVRs. Mit
weniger als 1MHz effektiven Taktes kommt meiner Erinnerung nach keiner
zu Welt.
Der exakte Ablauf könnte auch vom Typ abhängig sein. So ist bei fast
allen ATmega/tiny Typen die Taktquelle ausschliesslich von den Fuses
festgelegt, nur der Teiler ist variierbar. Erst der ATtiny841 erlaubt
eine Konfiguration zur Laufzeit. Es würde mich nicht überraschen, wenn
sich das auf das Startverhalten auswirkt.
S. Landolt schrieb:> Was mir das bringt? - Erkenntnisgewinn, aber entscheidend wichtig ist es> nicht. Es wäre trotzdem nett, wenn es jemand mal durchführte.
Die Erkenntnis ist ernüchternd.
Mit 8Mhz geht es bis CLKPR = 16, mit 16MHz bis CLKPR = 32. Was beides
jeweils 500KHz CPU-Clock ergibt. Darunter ist Schluss mit Lustig.
Delay ist egal. ISP-Clock 2 bzw. 4MHZ.
Attiny45. Ob mit JTAGICE oder AVRISP: gleiches Verhalten.
Hab jetzt keine Lust mehr, das weiter zu untersuchen.
mfg.
Ein herzliches Dankeschön. Ich hätte nicht geglaubt, dass sich jemand
noch um diese Zeit die Mühe macht.
An der Interpretation der Antwort muss ich noch etwas arbeiten.
Thread beobachten
Seitenaufteilung abschalten