mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Programmieren von AVRs schlägt fehl nach Benutzung von CLKPR


Autor: No Name (birger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Experten,
ich entwickele grad eine Schaltung in der ein ATtiny2313 zum Einsatz 
kommt. Da das Ganze stromsparend aufgebaut sein soll, habe ich das 
CLKPR-Register zum Runterteilen des Quarztaktes am Anfang des Programms 
verwendet. Das Programm arbeitet soweit korrekt.

Leider kann ich den µC aber jetzt nicht mehr programmieren, da er laut 
meiner Berechnung mit internen 46,8 KHz arbeitet. Gibt es eine 
Möglichkeit mit meinem Programmieradpter AVR910 das Timing so zu 
reduzieren, dass er einen so langsamen Mikrocontroller programmieren 
kann?

Ich weiß, dass man mit einem sehr schnellen externen Quarzosszilator 
z.B. 50MHz den Controller wieder ansprechen kann. Nur, das hilft bei der 
Entwicklung nicht weiter und wird dem Leben des Controllers nicht 
förderlich sein.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Birger Z. wrote:
> Leider kann ich den µC aber jetzt nicht mehr programmieren, da er laut
> meiner Berechnung mit internen 46,8 KHz arbeitet.

Nö.
Bei SPI-Programmierung wird der MC im Reset gehalten, das CLKPR hat also 
den Resetwert.
Code wird da garkeiner ausgeführt.


> Ich weiß, dass man mit einem sehr schnellen externen Quarzosszilator
> z.B. 50MHz den Controller wieder ansprechen kann.

Wer erzählt denn sonen Quark?


Peter

Autor: No Name (birger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ganz hab ich das Geschehen auch nicht verstanden, denn genau wie du, 
hätte ich erwartet, dass mit dem Reset-Signal auch das CLKPR-Register 
wieder zurückgesetzt werden würde. Nur, es geschieht wohl nicht.

Und das mit den 50 MHz ist natürlich kein Quark, ich hab's vorhin mit 
'nem anderen Controller AT90CAN128, der das gleiche Verhalten zeigte, 
einfach ausprobiert.

Mich interessiert, ob es eine Möglichkeit gibt, den SPI-Takt während des 
Programmierens mit Avrdude und AVR910-Programmer zu reduzieren.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Birger Z. wrote:

> Mich interessiert, ob es eine Möglichkeit gibt, den SPI-Takt während des
> Programmierens mit Avrdude und AVR910-Programmer zu reduzieren.

Das musst du deinen AVR910-Programmer fragen, denn der legt den Takt
fest.

Autor: No Name (birger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin mittlerweile schon zu zwei Lösungen gekommen:
Mit einem STK200 kompatiblen Adapter und den von Jörg schon an einigen 
anderen Stellen gemachten Hinweisen zu der -i Option habe ich Erfolg 
gehabt. Bei meinem Athlon 3200 XP habe ich -i 80 als Parameter 
angehängt, wobei das Funktionieren ab -i 63 anfing.
Desweiteren habe ich mir den Assemblercode des AVR910 angeschaut und die 
Delayroutine des SCK-Signals identifiziert. Da ich zum Neuflashen der 
Firmware allerdings sowieso den Parallelportprogger brauche, habe ich 
lieber gleich diesen genommen.

Die von mir bislang nie genutzte bzw. unbekannte -i Option erklärt mir 
auch, warum ich seit längerem nichts mehr von den Paralleport-Flashern 
gehalten habe.

Autor: Marcus Woletz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mit diesem Problem kämpfe ich auch gerade (ATmega48). Schreibt man einen 
zu großen oder zu kleinen(!) Teiler nach CLKPR, lässt sich auch bei mir 
der Baustein nicht mehr programmieren. Der Trick liegt nun darin, den 
Programmer zu veranlassen, RESET auf low zu halten, und dann den ATmega 
aus- und wieder einzuschalten. Dadurch läuft das Programm erst gar nicht 
an, der CLKPR wird auch nicht beschrieben. Evtl. wird das CLKPR-Register 
bei einem "Warmstart" (ohne Wegnahme der Betriebsspannung) gar nicht auf 
den Initialwert gesetzt?
Am Timing kann's eigentlich nicht liegen, da ich ein selbstgebasteltes 
Downloadprogramm verwende, in welchem ich das Timing beliebig einstellen 
kann. Erst der Trick mit RESET low beim Einschalten brachte Erfolg.
Das ist laut ATMEL-Doku auch der beste Weg. Warum sich die Biester mit 
bestimmten Vorteilern nicht mehr programmieren lassen, ist eine 
interessante Frage. Ich werde mal auf den ATMEL-Seiten stöbern, ob ich 
dort etwas finde. Irgendwelche Timingbeschränkungen habe ich zumindest 
auch auf den zweiten Blick in der Doku nicht finden können. Seltsam das 
ganze...

ciao

Marcus

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Evtl. wird das CLKPR-Register bei einem "Warmstart" (ohne Wegnahme der
> Betriebsspannung) gar nicht auf den Initialwert gesetzt?

Den Eindruck habe ich auch, habe allerdings im Datenblatt keinen
entsprechenden Vermerk gefunden (vielleicht auch nur übersehen).

> Am Timing kann's eigentlich nicht liegen, da ich ein selbstgebasteltes
> Downloadprogramm verwende, in welchem ich das Timing beliebig
> einstellen kann.

Bei mir half allerdings das Ausbremsen der Datenübertragen mit der
-i-Option von AVRdude bei der Verwendung eines Parallelport-Bitbang-
Programmers.

> Irgendwelche Timingbeschränkungen habe ich zumindest auch auf den
> zweiten Blick in der Doku nicht finden können.

Im Kapitel "Serial Downloading" im Datenblatt ist die maximale
Übertragungsgeschwindigkeit wie folgt spezifiziert:

  "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"

Autor: Dan M. (killler07)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der USBASP Programmer (http://www.fischl.de/usbasp/) hat einen Jumper 
zum herabstellen der Programmiergeschwindigkeit, hat auch mich schon 
gerettet.

Nicht nur als Notfalllösung geeignet, ist ein super Programmer.

Autor: Marcus Woletz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

also ich habe jetzt das Problem gefunden, warum ich den ATmega48 nach 
dem ändern von CLKPR nicht mehr programmieren konnte, ohne die Spannung 
wegzunehmen, bei aktivem RESET (also low) einzuschalten und dann zu 
flashen: Ich habe mich beim Versuch, in den Programmiermodus zu 
schalten, an den Algorithmus von Atmel gehalten und nach einem 
erfolglosen Versuch RESET kurz auf High-Signal gelegt und dann wieder 
auf low (aktiv). Dabei hatte ich den High-Zustand sicherheitshalber auf 
100ms gesetzt. Das war viel zu lang! Gehe ich mit der Impulslänge sehr 
weit runter, z.B. auf 1ms, dann lässt sich der Controller problemlos in 
den Programmiermodus schalten. Ich habe die Vermutung, dass der 
Controller bei 100ms High-Signal an RESET anläuft und sich dann beim 
anschließenden RESET in einem Zustand befindet (evtl. durch das 
geänderte CLKPR), dass er sich nicht mehr in den Programmiermodus 
schalten lässt. Nun habe ich ja den BOD noch nicht aktiviert. Mit 
aktiviertem BOD wird ja die Hochlaufzeit erheblich kürzer, so dass der 
Controller evtl. schon nach 1ms wieder komplett hochgelaufen ist. Ich 
werde das mal testen. Vielleicht hat jemand eine Idee, wo das Problem 
liegen könnte. Ansonsten kein Problem, denn der Controller lässt sich ja 
problemlos programmieren.

ciao

Marcus

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.