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?
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
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?
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
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.
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...
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
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?
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.
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.
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.
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?
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.
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.
> ... und 51,1 Hz einstellen, das sollte reichen
'Low Frequency Crystal Oscillator' mit 32 KiHz /256 /4 = 32 Hz.
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.
> ... 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?
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?
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.
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.
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.
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.
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.
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.
> 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.'
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.
Johnny S. schrieb: > Das es ein Hardwareproblem ist, bezweifle ich, da die Software ja > einwandfrei funktioniert. Echte Profis seit ihr.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.