mikrocontroller.net

Forum: Compiler & IDEs make.exe: *** [program] Error 1


Autor: Daniel Schillinger (enton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute

Hab follgendes Problem.
Wenn ich mein Program auf den Atmega flashen will kommt folgende 
Fehlermeldung:
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x0c != 0xff
avrdude: verification error; content mismatch

avrdude done.  Thank you.

make.exe: *** [program] Error 1

> Process Exit Code: 2
> Time Taken: 00:11

Das passiert aber hauptsächlich nur bei einem Program.
Hatte diese Meldung früher auch schon öfters. Aber wenn ich dann den 
Programmer einmal aus und wieder eingesteckt habe, oder es mehrmals 
probiert habe, hat es als geklappt. Aber jetzt will er gar nicht mehr.
Das witzige an der Sache ist, das es eben nur bei einem Program ist, das 
ich aber vor nem Monat noch problemlos flaschen konnte.
Bei allen anderen Programmen funktioniert es.

Hat jemand ne Idee an was das liegen könnte?(WinAVR, Windoof, Programmer 
oder Atmega kaputt)......

Dann wollte ich mal noch wissen, welche Datei genau auf den Atmega 
geflasht wird, weil ich schauen wollte, wie groß die Datei ist. Gehe ich 
richtig in der Annahme, das das die *.hex Datei ist?
Wenn ich die anklicke zeigt mir Windoof folgendes an:
Größe: 28,5KB
Größe auf Datenträger: 32KB.

Da sie nicht größer als 32KB ist, sollte es ja kein Problem sein für nen 
Atmega 32, oder?

Woher kommt eigentlich die differenz zwischen den 28,5KB und den 32 KB.
Für mich dürften ja die 32KB interresant sein, da der Atmega ja ein 
"Datenträger" ist, oder sehe ich das falsch?

Gruß Enton

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Grösse der HEX-Datei ist nicht vergleichbar mit der FLASH-Grösse des 
µC. In der HEX-Datei ist der Inhalt des FLASHs (oder des EEPROMS) in 
Kodierter Form enthalten. Daher ist die Grösse der HEX-Datei in Bytes 
normalerweise grösser als das zu programmierende FLASH in Bytes.

Auf modernen Rechnern kann es bei einfachen Programmieradaptern 
("Bitbanger") zu Problemen kommen, weil diese Rechner zu schnell für die 
Programmierverfahren der Programmiersoftware (AVRDUDE) sind. Abhilfe ist 
ein Verzögern der Programmierverfahren in der Programmiersoftware über 
das Kommandozeilenargument -i <delay>
http://www.nongnu.org/avrdude/user-manual/avrdude_4.html

Ich kann mir vorstellen, dass diese Probleme bei rel. grossen 
HEX-Dateien (gross im Sinn von: es ist viel zu programmieren, d.h. ein 
umfangreiches Programm liegt vor) verschärft vorkommen.

Die Differenz tatsächliche Dateigrösse und Platzbedarf auf dem 
Datenträger hängt mit der Blockgrösse (Cluster) des Datenträgers 
zusammen.
http://www.hardwaregrundlagen.de/oben05-006.htm

Anm.: Slang ala "Windoof" ist cool, wenn man was von der Sache versteht. 
Bei zu wenig Wissen wirkt es eher peinlich.

Autor: Daniel Schillinger (enton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo kann ich das -i <delay> denn Einfügen?
Geht das im Makefile oder muss ich dann direkt über die Komandozeile 
flashen?

Was für einen Wert sollte man für i-delay wählen?
(Prozesor hat 2Ghz, Atmega hat 16MHZ).

Bei welchen Programmertypen tritt dieses Problem nicht auf?
Wollte mir sowieso mal nen neuen holen.

P.s. das Windoof kommt daher, das ich mich in letzter Zeit etwas mit 
Vista rum ärgern durfte.

Gruß Enton

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Muss ich auch erst im Forum suchen, um einen Praxiswert zu finden...
Hier in Beitrag "ATMEGA8 mit avrdude flashen macht Probleme" ist was 
angegeben.

Du kannst das selbstverständlich im Makefile erledigen, und gibt es eine 
Variable AVRDUDE_FLAGS und dort kannst du das reinpacken

AVRDUDE_FLAGS = -p $(MCU) -P $(AVRDUDE_PORT) -c $(AVRDUDE_PROGRAMMER)
AVRDUDE_FLAGS += $(AVRDUDE_NO_VERIFY)
AVRDUDE_FLAGS += $(AVRDUDE_VERBOSE)
AVRDUDE_FLAGS += $(AVRDUDE_ERASE_COUNTER)
# Zusätzlich:
AVRDUDE_FLAGS += -i 50                   


Also nimm keinen ISP-Adapter, der an den Parallelport kommt oder am 
seriellen Port ohne Protokoll mit den Leitungen klappert. Wenn die 
Programmiersoftware ein notorisches Bitbanging-Programm ist (z.B. 
PonyProg), wäre das für mich auch ein Ausschlussgrund.

OK sind denke ich Programmieradapter, die das AVR910 oder das STK500 
Programmierprotokoll beherrschen. Ich habe da aber nicht so den Plan, 
ich habe ein Evertool mit STK500 Protokoll und einen ältere AVR-ISP 
Nachbauten mit Parallelportanschluss (bisher aber keine Probleme, 
vielleicht weil ich auch einen PC aus 1999 habe).

Vista? Bist entschuldigt ;-)

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

Bewertung
0 lesenswert
nicht lesenswert
Stefan "stefb" B. wrote:

> OK sind denke ich Programmieradapter, die das AVR910 oder das STK500
> Programmierprotokoll beherrschen. [...]

Naja, AVR910 auch nur (noch) bedingt.  Es setzt auf dem Konzept eines
"device code bytes" auf, das für jeden AVR festgelegt werden muss.
Da Atmel selbst diese device codes nun schon seit Jahren nicht mehr
pflegt, weil es AVR910 aufgegeben hat, existiert da ein unglaublicher
und zueinander inkompatibler Wildwuchs.

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.