mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATmega1284p lässt sich nur einmal laden


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Johnny S. (sgt_johnny)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es geht um folgendes:

Professionell gefertigte Leiterplaten in grösserer Stückzahl haben einen 
ATMEGA1284p drauf, welcher keinen externen Quarz hat. Nun muss die 
Software ja auf den Mega kommen, hierzu wird AVRDUDE benutzt. Das 
Problem ist nun, dass man die Software genau einmal laden kann, danach 
kommt nur noch eine komische Device-Signatur als Antwort 0x000100

Egal was man lädt, es geht genau einmal, ob man nun die echte Software, 
ein beliebiges Hexfile, oder sogar versucht einen Arduino-Bootloader zu 
brennen, nach dem ersten Mal is Schluss.

Das es ein Hardwareproblem ist, bezweifle ich, da die Software ja 
einwandfrei funktioniert.

An was kann sowas liegen?

Autor: Magnus M. (magnetus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reset disable fuse gesetzt?

Autor: Johnny S. (sgt_johnny)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir führen folgenden Command aus:

C:\avr\bin>avrdude 
-CC:\avrdatapack\packages\MightyCore\hardware\avr\1.0.8/avrdude.conf -v 
-patmega1284p -cstk500v1 -PCOM8 -b19200 
-Uflash:w:-Uflash:w:C:\eclipseout\test.hex:i -Ulock:w:0x0f:m

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johnny S. schrieb:
> Das Problem ist nun, dass man die Software genau einmal laden kann, danach
> kommt nur noch eine komische Device-Signatur als Antwort 0x000100

Und die Software läuft dann auch?
Oder drehst du dem ATmega beim Flashen den Takt ab?

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Magnus M. schrieb:
> Reset disable fuse gesetzt?

Beim Mega1284p?
Seit wann hat der die?

Autor: Johnny S. (sgt_johnny)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Johnny S. schrieb:
>> Das Problem ist nun, dass man die Software genau einmal laden kann, danach
>> kommt nur noch eine komische Device-Signatur als Antwort 0x000100
>
> Und die Software läuft dann auch?
> Oder drehst du dem ATmega beim Flashen den Takt ab?

Die Sotware läuft, also zumindest die blinkende Status-LED welche vom 
Atmega gesteuert wird.

Den "Takt" abdrehen kann man ja nur in dem man z.b.  so flasht das ein 
Quarz benutz wird, aber keinen anschliesst. Wir wollen ja bewusst keinen 
Quarz einsetzen, da dieser nicht benötigt wird

Autor: Karl M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wer hat sich den das (falsch) ausgedacht?
"-Uflash:w:-Uflash:w:C:\eclipseout\test.hex:i -Ulock:w:0x0f:m"

Es gibt eine Command- und Onlinehilfe zu den Parametern, die sollte man 
mal lesen.

Autor: c-hater (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Johnny S. schrieb:
> Es geht um folgendes:
>
> Professionell gefertigte Leiterplaten in grösserer Stückzahl haben einen
> ATMEGA1284p drauf, welcher keinen externen Quarz hat. Nun muss die
> Software ja auf den Mega kommen, hierzu wird AVRDUDE benutzt. Das
> Problem ist nun, dass man die Software genau einmal laden kann, danach
> kommt nur noch eine komische Device-Signatur als Antwort 0x000100

Schaltplan!

Ziemlich sicher: Irgendwas hängt an HW-SPI und das (was immer es ist) 
wird nicht durch die Reset-Leitung in einen bezüglich ISP 
"ungefährlichen" Zustand gebracht und auch durch keinen anderen 
sinnvollen Mechanismus. Ich würde mal tippen: da fehlt schlicht ein 
Pulldown, nämlich am SS/CS-Eingang von (was immer es ist, was da am SPI 
hängt)...

Wenn es so ist: eindeutig superkrasses Fehldesign. Und wenn sowas erst 
auffällt, wenn "Professionell gefertigte Leiterplaten in grösserer 
Stückzahl" vorhanden sind, hat wohl irgendwer seinen Job nicht richtig 
gemacht...

Autor: Stefan E. (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wird im Programm der Systemtakt (über den Prescaler) runter gesetzt?

Edit:

Johnny S. schrieb:
> Egal was man lädt, es geht genau einmal, ob man nun die echte Software,
> ein beliebiges Hexfile

Wenn es tatsächlich bei beliebigem Hex-File so ist, dann vergiss meine 
Frage.

: Bearbeitet durch User
Autor: Johnny S. (sgt_johnny)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl M. schrieb:
> Hallo,
>
> wer hat sich den das (falsch) ausgedacht?
> "-Uflash:w:-Uflash:w:C:\eclipseout\test.hex:i -Ulock:w:0x0f:m"
>
> Es gibt eine Command- und Onlinehilfe zu den Parametern, die sollte man
> mal lesen.


Magnus M. schrieb:
> Reset disable fuse gesetzt?


Hm, es gibt Parameter für Fuses, müssten die nicht eigentlich irgendwo 
in der Kommandozeile stehen?

Kann es sein dass garkeine Fuses gesetzt sind?

Autor: Voll Profi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> eindeutig superkrasses Fehldesign.

Nein! Nicht doch! Das kann nicht sein! Lies doch nochmal:

Johnny S. schrieb:
> Professionell gefertigte Leiterplaten

Das musst auch du verstehen.

Autor: Maxim B. (max182)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Johnny S. schrieb:
> An was kann sowas liegen?

1284 hat (anders als z.B. 328 ) separate XTAL. Wird Quarz nicht benutzt, 
so bleiben sie sowieso frei.
Deshalb würde ich es mit einem Quarz oder besser ext. Oszillator 
probieren.

Autor: Hermann (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Stefan E. schrieb:
> Wird im Programm der Systemtakt (über den Prescaler) runter gesetzt?

Das war bei mir mal das Problem. Wird einmal der Systemtakt runter 
gesetzt, lässt er sich danach nur mit einem entsprechend niedrigen Takt 
programmieren. Es geht erst wieder, wenn man mit dem niedrigen Takt ein 
Programm mit dem hohen Takt lädt. Der Grund: Reset löscht nicht das 
CLKPR-Register obwohl das im Manual steht. Wenn man Vcc anlegt, kommt er 
vor dem Programmieren im alten Programm auf die CLKPR-Statements und 
dann geht der schnelle Takt nicht mehr.
Beschrieben habe ich das hier:
Beitrag "ISP-MKII-Problem bei kleinen Taktfrequenzen"
dort steht am Schluss auch, wie man aus der Klemme heraus kommt: Eine 
Warteloop vor den CLKPR-Statements. Sie muss länger sein als die Zeit 
zwischen Vcc und Reset.

Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist sehr interessante Phänomen, gut zu wissen.
Die Frage:
in Manual in 9.12.2 steht:
"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 8 at start up."

Wenn aus deinem Bericht kommt, daß " If CKDIV8 is unprogrammed, the 
CLKPS bits will be reset to “0000”" nicht funktioniert, ob das auch für 
programmierte CKDIV8 gilt?
Oder ist hier unter "reset" nur Power-on Reset gemeint?

Autor: Stefan E. (sternst)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Maxim B. schrieb:
> Wenn aus deinem Bericht kommt, daß " If CKDIV8 is unprogrammed, the
> CLKPS bits will be reset to “0000”" nicht funktioniert

Das funktioniert schon, aber der Default-Wert wird erst geladen, wenn 
der Controller los läuft, also aus dem Reset raus kommt. Beim 
Programmieren ist er aber die ganze Zeit im Reset, und dort gilt dann 
noch der vorher eingestellte Wert.

Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann ist mir nicht klar, wie man das vermeiden könnte, wenn man CLKPR 
benutzt. Auch bei F_CPU = 20 MHz kann man mit CLKPR 78125 Hz einstellen. 
Z.B. in ISR wird 20 MHz benutzt und dazwischen 78125. Dann weiß man nie, 
wie CLKPR beim Programmieren wirklich steht!

Ich habe gleich angekuckt: bei meinem Programmierer kann man auch 
Frequenzen 6,48 kHz, 100 Hz und 51,1 Hz einstellen, das sollte 
reichen... Aber... Irgendwie komisch...

Aber in jedem Fall gut zu wissen.

Autor: S. Landolt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... und 51,1 Hz einstellen, das sollte reichen

'Low Frequency Crystal Oscillator' mit 32 KiHz /256 /4 = 32 Hz.

Autor: Stefan E. (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. Landolt schrieb:
>> ... und 51,1 Hz einstellen, das sollte reichen
>
> 'Low Frequency Crystal Oscillator' mit 32 KiHz /256 /4 = 32 Hz.

Wenn es so extrem kommt, dass man den Programmer nicht langsam genug 
einstellen kann, kann man als Alternative immer noch einfach verhindern, 
dass der Controller zwischen Power-Up und Programmieren das Programm 
startet (also verhindern, dass vor dem Programmieren CLKPR verändert 
wird). RESET hart auf Low ziehen, Power-Cycle machen, Programmieren 
starten.

Autor: S. Landolt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... Alternative ... RESET hart auf Low ziehen,
> Power-Cycle machen, programmieren starten.

Bei ISP: hängt das nicht auch von der gegebenen Schaltung ab, z.B. was 
beim  Power-up auf SCK passiert?

Autor: Stefan E. (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. Landolt schrieb:
> Bei ISP: hängt das nicht auch von der gegebenen Schaltung ab, z.B. was
> beim  Power-up auf SCK passiert?

Mir ist nicht ganz klar, worauf du hinaus willst. Wenn bei Reset=Low die 
externe Hardware an SCK "rumwackelt", wäre das nicht ganz grundsätzlich 
eine ziemlich schlechte Idee, nicht nur in dieser speziellen Situation?

Autor: S. Landolt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das weiß ich nicht, ich will auch nirgendwo hinaus, es war nur eine 
Frage, basierend auf dem Datenblatt:
'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 ...'

Ich selbst war damit nie konfrontiert, habe also auch keinerlei 
Erfahrung.

Autor: Hermann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan E. schrieb:
> Default-Wert wird erst geladen, wenn
> der Controller los läuft, also aus dem Reset raus kommt

Ja, so passt es endlich zusammen. Beim Programmieren bleibt er in Reset 
und ist auf der niedrigen Frequenz. Damit muss man mit dem 
Programmiertakt auf 1/4 der CLKPR-Einstellung.
Das passt auch zu meinen umfangreichen Tests. Nach power-on lässt er 
sich mit der hohen Frequenz programmieren, nach Setzen von CLKPR aber 
nicht mehr.

Da gibt es nur die Möglichkeit immer mit niedrigem Takt zu 
programmieren, oder die beschriebene Warteloop einzubauen.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hermann schrieb:
> Nach power-on lässt er
> sich mit der hohen Frequenz programmieren, nach Setzen von CLKPR aber
> nicht mehr.

So ist es. Nur ein POR lädt das CLKPR neu, alle anderen Resetquellen 
lassen CLKPR unverändert, also auch das externe Reset beim 
Programmieren.
Ist mir mal beim ATtiny25 aufgefallen, ich konnte ihn dann nur noch mit 
HV-Programming wiederbeleben.
Im Datenblatt findet man aber nichts darüber.

Autor: Hermann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Nur ein POR lädt das CLKPR neu, alle anderen Resetquellen
> lassen CLKPR unverändert, also auch das externe Reset beim
> Programmieren

Das stimmt so nicht!
Ich habe gerade folgenden Test gemacht:
Ein M328 mit Default-Fuses, d.h. der RC-Oszillator läuft auf 1MHz nach 
POR.
Über CLKPR habe ich ihn auf 8MHz gesetzt.

Danach lade ich ein Programm ohne Setzen von CLKPR.
Vcc steht die ganze Zeit an. Nach deiner Aussage müsste er jetzt 
weiterhin mit 8MHz laufen, da ja kein POR sondern nur der externe Reset 
durch das Programmieren gekommen ist. Er läuft aber ordnungsgemäß mit 
1MHz. Also hat das externe Reset die CLKPR-Bits auf die Werte der Fuses 
gesetzt.

Meine Erkenntnis: es ist wohl so, wie Stefan Ernst gesagt hat: die 
Default-Werte werden geladen, wenn er aus dem Reset herauskommt und das 
bei POR und externem Reset. Dieses späte Setzen der Default-Werte führt 
leicht zu Fehleinschätzungen, so auch ursprünglich bei mir.

Nur so lassen sich meine umfangreichen Tests schlüssig erklären.

Autor: TM F. (p_richner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich vermute stark, dass es die Fuses sind.

Hat du eventuell das SPIEN-Bit auf "1" gesetzt. So könntest du nur 
einmal über SPI programmieren, danach ist es ausgeschaltet. (Seite 378 
im DB)

SPIEN(2) 5 Enable Serial Program and Data Downloading
0 (programmed, SPI programming enabled)

Ich denke nicht, dass der Clock das grosse Problem ist. Ein kluger 
Programmer sollte den Takt automatisch erkennen.

Autor: Hermann (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wenn das alles stimmt, muss auch die Idee von Stefan funktionieren:
Stefan E. schrieb:
> RESET hart auf Low ziehen, Power-Cycle machen, Programmieren starten

Habe ich also getestet: Reset hart auf Low, dann Vcc anlegen.
Ich hatte erst Bedenken, das mein MKII meckert. Tut er auch: hecktischen 
Blinken der LED. Aber das Programmieren mit AVR-Studio geht trotzdem. 
Nach fertigem Programmieren in aller Ruhe den Hart-Reset weg. Und das 
Programm läuft ohne über die alten CLKPR-Bits zu stolpern.

Autor: S. Landolt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hat du eventuell das SPIEN-Bit auf "1" gesetzt.
> SPIEN(2) 5 Enable Serial Program and Data Downloading...

Und dazu gehört natürlich eben diese Fußnote (2):

'2. The SPIEN Fuse is not accessible in serial programming mode.'

Autor: Hermann (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
TM F. schrieb:
> Ich denke nicht, dass der Clock das grosse Problem ist. Ein kluger
> Programmer sollte den Takt automatisch erkennen.

Es mag bei Jonny ein anderes Problem sein. Bei mir ist es eindeutig das 
Setzen des niedrigen Takts über CLKPR.
Der MKII und AVRStudio 7 sind nicht klug genug um das automatisch zu 
erkennen.

Autor: Mad (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johnny S. schrieb:
> Das es ein Hardwareproblem ist, bezweifle ich, da die Software ja
> einwandfrei funktioniert.

Echte Profis seit ihr.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hermann schrieb:
> Meine Erkenntnis: es ist wohl so, wie Stefan Ernst gesagt hat: die
> Default-Werte werden geladen, wenn er aus dem Reset herauskommt

Du hast recht, das CLKPR wird erst mit der 0-1 Flanke des Reset neu 
gesetzt. Das ISP erzeugt aber nur eine 1-0 Flanke und damit bleibt der 
Takt, wie ihn die Applikation gesetzt hat.

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.