mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Schreiben bricht ab


Autor: Philipp S. (philipp-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Erik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Philipp S. (philipp-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Erik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Erik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da fällt mir nochwas ein:
Der Controllertyp ist zweimal einzustellen!
Einmal unter Project->Configuration Options->General
und unter Debug->Select Platform and Device...

Autor: Philipp S. (philipp-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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!

Autor: Erik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Philipp S. (philipp-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... 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



Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp S. (philipp-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp S. (philipp-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Erik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

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.