Hallo, Ich bin gerade mit einem AVR-Projekt beschäftigt. Zur Zeit schreibe ich den Code für den verwendeten ATmega32L im AVR-Studio mit WinAVR (jeweils neuste Versionen). Ging auch alles ziemlich gut. Konnte bis vor kurzem schreiben und lesen. Als Programmer benutze ich den AVRISP mkII. DANN (vor ein paar Tage) ging es los: Nach dem Beschreiben des ATmega32 hatte das Verify ein Problem und brachte eine Fehlermeldung: "Verify failed at xxxx expected 0x??" Der Controller-Flash war zu etwa 12% voll. Das fehlerhafte Byte war auch ziemlich am Ende der 12%. Der Controller lief trotzdem... Also machte ich mir keine Sorgen. Habe nun weiteren Code geschrieben und wollte den deutlich angewachsenen Code (~20k ~40% full) in den Controller schreiben. Der Fortschrittsbalken läuft auch los - bricht aber kurz vorm Ende ab und bringt eine Fehlermeldung: "Write failed" Habe ich irgendwelche Einstellungen / Fuses zu beachten, die den Code beschränken? Danke für Eure Hilfe!
Fuses die den Code beschränken sind mir keine bekannt.
Einstellungen:
Richtiger Controllertyp eingestellt?
Die Codegröße wird schlimmstenfalls durch den Controller selbst
beschränkt, will heißen: Er sollte reinpassen!
Sollte bei dir aber wegen
> Code (~20k ~40% full)
gegeben sein.
Optimierung zur Reduktion des Codes einschalten!
Habe den richtigen AVR-Typ eingestellt. Code-Optimierung verwende ich auch: Compiler-Option -Os Hatte aber mal versehentlich den falschen Typ beim Programmieren eingestellt. Ging dann nicht - logisch. Nach dem Rückändern gings wieder. Kann der ATmega dadurch Schaden genommen haben? Muss ich im AVR-Studio bei den Projekt-Optionen bei den Memory Settings Einstellungen vornehmen?
> Hatte aber mal versehentlich den falschen Typ beim Programmieren > eingestellt. Ging dann nicht - logisch. Nach dem Rückändern gings > wieder. > Kann der ATmega dadurch Schaden genommen haben? Denke ich nicht. Das sollte eigentlich kein Problem sein. > Muss ich im AVR-Studio bei den Projekt-Optionen bei den Memory Settings > Einstellungen vornehmen? Normalerweise ebenfalls nicht. Die sollten bei richtigem Controllertyp automatisch gesetzt werden. Hängt evtl. noch was anderes mit an den Leitungen (z.B. benutzt du SPI?). Das kann Störungen geben. Controller defekt? Mal nen anderen (evtl gleichen Typs) versuchen.
Da fällt mir nochwas ein: Der Controllertyp ist zweimal einzustellen! Einmal unter Project->Configuration Options->General und unter Debug->Select Platform and Device...
> Hängt evtl. noch was anderes mit an den Leitungen (z.B. benutzt du > SPI?). Ja - es hängt noch ein Nokia 3310-Display am SPI-Bus. Das könnte es sein. Werde das heute abend mal ausprobieren. Allerdings verwendet ich für das Display nur den MOSI-Pin. Das Display kann also nicht "dazwischenquatschen". Ich habe aber keinen Pull-Up Widerstand für die /CS-Leitung verwendet - Vielleicht ist es ja das. > Controller defekt? Mal nen anderen (evtl gleichen Typs) versuchen. Das sagt sich leicht - das ist ein SMD-Typ - handgelötet. Nur als allerletztes Mittel!
> Allerdings verwendet ich für das Display nur den MOSI-Pin. Das Display kann also
nicht "dazwischenquatschen".
Es dreht sich auch nicht ums "dazwischenquatschen" sondern darum, dass
mit an den "PROGRAM-PINs" hängende Gerätschaften die Signale verfälschen
können.
Versuchs mal ohne Zusätze am SPI.
Gruß,
Erik
> ... die Signale verfälschen können. Ich werde mal das Oszi anschließen und die Signale überprüfen. Denke aber nicht, dass das wirklich der Grund ist, da es ja vor kurzem (mit kleinerem Code) noch funktioniert hatte - auch mit dem Display. Ich überprüfe das Problem noch mal mit weniger Code (kleineres Programm). Kann ich irgendwo festlegen, dass das Codesegment in einen höheren Speicherbereich des Controller geschrieben wird? Dann könnte ich ja einen defekten AVR ausschließen... Vielen Dank vorerst - ich melde mich heute abend noch mal, Philipp
Hallo, ich habe speziell beim Testen fast immer was an den SPI-Pins hängen, ohne daß es stört. Natürlich muß Du dafür sorgen, daß das Bauteil sicher im TriState bzw. als Eingang geschaltet und möglichst inaktiv ist. /CS also sicher auf H halten. Stören kann es trotzdem, wenn der Programmer wenig Reserven bei der Last hat. Mein STK200-Dongle mit dem 74HC244 ist da eher hart im nehmen. Gruß aus Berlin Michael
Hallo, Weitere Erkenntnisse des Abends: Habe einen 10k Pull-up Widerstand an das /CS des Nokia Displays gelötet. Das Display sollte also während des Programmierens tri-state sein. A) Habe den Code wieder abgespeckt: Device: atmega32 Program: 8502 bytes (25.9% Full) (.text + .data + .bootloader) Data: 1043 bytes (50.9% Full) (.data + .bss + .noinit) Ich erhalte während des Programmierens mit dem AVRISP mkII: Setting mode and device parameters.. OK! Entering programming mode.. OK! Erasing device.. OK! Programming FLASH .. OK! Reading FLASH .. OK! WARNING: FLASH byte address 0x1F01 is 0x9B (should be 0x93).. FAILED! Leaving programming mode.. OK! Das Programm läuft auch nicht auf dem Controller - wen wundert's! Die fehlerhafte Adresse ist reproduzierbar. B) Mit dem ursprünglichen (längeren) Code: Program: 19590 bytes (59.8% Full) Data: 1748 bytes (85.4% Full) Und dann beim Schreiben: Erasing device.. OK! Programming FLASH .. FAILED! Leaving programming mode.. OK! Der Fortschrittsbalken ist immer an der gleichen Stelle, wenn der Fehler erscheint! Das widerspricht doch dem zufällig gestörten SPI-Bus! Sieht das nach einem defekten Controller aus? Oder habe ich etwas übersehen? Wie kann ich gezielt den Flash-Speicher des AVR testen?? Philipp
Es gib µC die an definierten Adressen nicht lesbare Bytes im Flash haben. Das dient zur Flashprotection. Ist die Flashprotection aktiviert kann nur dann geflasht werden, wenn die im Hexfile an dieser Adresse stehenden Werte mit denen im Flash identisch sind. Auslesen kannst du diese Werte nicht. Für dein Programm musst du dann im Linker diesen Adressbereich ausblenden, bzw die richtigen Bytes an diese Adresse linken. Ist die Flashprotection nicht aktiv kannst du diese Adressen überschreiben, allerding nicht auslesen. Es werden definierte Werte zurückgeliefert zb 0xFF. Das führt zu dem Verifyfault. Ich kann dir jetzt aber nicht sagen ob dein AVR diesen Flashbereich hat oder nicht. Das solltest du aber im Flashmapping im Datasheet finden können. Bei TI im TMS470 (ARM7 TDMI) heißen diese Bytes "Protection Keys"
Hallo, na, da hast Du wohl wirklich einen Mega mit einem kaputten Bit im Flash. Mir ist noch keiner begegnet, nur ein 32MB-PS/2-modul mit genau einem defekten Bit an einer einzigen Adresse hatte ich schon mal... Gruß aus Berlin Michael
@ Ralph: Der ATmega32 hat keine solche Prüfbits. Ich kann aber mit entsprechenden Steuer-Bits festlegen, ob der Speicherinhalt ausgelesen werden darf oder nicht. Diese sind aber nicht gesetzt. @ Michael: Habe mich schon intensiv mit dem SMD-entlöten auf diesen Seiten informiert. Dumm ist nur, dass seit der Erstbestückung des Controllers benachbarte Bauteile hinzugekommen sind, die das Bestücken erschweren. Bevor ich das mache: Wie kann ich sicher überprüfen, dass das Bit defekt ist; bzw. dem Compiler/Linker sagen, dass er das Byte überspringen soll (also eine Art Mapping des Codes)? Philipp
Guten morgen allerseits... > Die fehlerhafte Adresse ist reproduzierbar. Du hast Recht, das deutet nicht auf Störungen durch weitere Geräte hin. Es wäre nur eine Möglichkeit da ich schon öfter Probleme mit weiteren Bausteinen (ob tristate oder nicht) an den Prog.leitungen hatte. Dann unterscheiden sich normalerweise aber die Adressen bei jedem Schreibvorgang. > dem Compiler/Linker sagen, dass er das Byte überspringen soll Da könnte sich evtl. über die Memory Settings in der Projektkonfig was tun lassen. Das habe ich aber noch nie versucht. Vielleicht bringt die Hilfe im Studio selbst oder die Anleitungen zum Studio von Atmel was??? Habe da in beides aber leider noch nie reingeschaut!
Bitte 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.