AVRDUDE EEMPROM Fehler mit ATtiny1634

[muli (Gast)]

Hallo,

ich versuche eine .eep Datei zu schreiben, und bekommen immer den 
Fehler: "verification error, first mismatch at byte 0x0000"

Ich habe das Problem inzwischen mit dieser Code-Sequenz eingeschränkt 
(_writeNumber gibt ein Byte auf dem UART aus):

uint8_t test[5]    EEMEM =  { 3, 4, 5, 6, 7};
uint8_t test2[128]     EEMEM =  { 9, 8, 9, 9, 9};

(...)

 _writeNumber (eeprom_read_byte(&test[1]));
 _writeNumber ((uint8_t)(int)&test[1]);
 _writeNumber (eeprom_read_byte(&test2[1]));
 _writeNumber ((uint8_t)(int)&test2[1]);
 
 eeprom_write_byte (&test[1], 25);
 eeprom_write_byte (&test2[1], 26);
 
 _writeNumber (eeprom_read_byte(&test[1]));
 _writeNumber ((uint8_t)(int)&test[1]);
 _writeNumber (eeprom_read_byte(&test2[1]));
 _writeNumber ((uint8_t)(int)&test2[1]);

Das Ergebnis ist das Folgende:

000129 >> test Wert 2 in EEPROM Adresse 129: ist 0, sollte 4 sein
004001 >> test2 Wert 2 in EEPROM Adresse 1: ist 4, sollte 8 sein
025129 >> schreiben innerhalb des Programs auf Adresse 129 klappt
026001 >> schreiben innerhalb des Programs auf Adresse 1klappt

Es scheint, als wenn alle Adresse ab 128 in Wirklichkeit ab Adresse 0 
geschrieben werden. Ich habe den selben Code auf einem ATmega1284 
getestet, dort funktioniert er ohne Probleme. Daher vermute ich, dass 
die .eep Datei korrekt ist (erzeugt mit avr-gcc). Ich habe bereits etwas 
in der avrdude.conf geschaut, kann aber nicht sagen, ob das Problem von 
dort oder woanders kommt. Im Anhang die eep-Datei und der entsprechende 
Abschnitt der conf Datei.

Vielen Dank schon mal für jeden weiteren Hinweis aus das Problem!

Grüße,
muli

[Karl M. (Gast)]

Guten Morgen,

passt die Versorgungsspannung laut Atmel?
Wie hoch ist die µC Taktfrequenz?

Wie sehen die FuseBits aus, in Bezug auf die Atmel Application Note bei 
Nutzung eines EEProm?

[muli (Gast)]

Versorgungsspannung ist 5V, Taktfrequenz ist 3.6864 MHz - sollte 
eigentlich beides passen.

Fuse-Bits:
- low sind alle gesetzt, außer CHSEL1=0 (ext. Quarz), und SUT=0
- high sind auch alle gesetzt, außer SPIEN=0
- ext sind alle unverändert gesetzt.

Welche Fuse-Bits sind denn noch relevant, EESAVE? Werde auf jeden Fall 
mal die AppNote suchen...

Grüße,
muli

[Karl M. (Gast)]

Hallo,

einfacher wäre es die Hex-Werte der Fuse-Bits anzugeben.

Dass Du nicht langen suchen must, hier einer der vielen Link zum Thema
"brown out detection" bei EEpromnutzung:

Beitrag "Datenverlust internes EEPROM AVR"

Wir kennen ja auch nicht die Funktionen für den EEpromzugriff da könnte 
auch etwas nicht stimmen.

Microchip hat auch hier eine Application Note veröffentlicht.

AVR100: Accessing the EEPROM on tinyAVR and megaAVR devices
http://ww1.microchip.com/downloads/en/AppNotes/doc0932.pdf

[Karl M. (Gast)]

Nachtrag,

ich denke Du nutzt einen avr gcc mit Libc <avr/eeprom.h> "EEPROM 
handling"

http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html

[muli (Gast)]

Richtig, EEPROM Zugriff läuft über avr/eeprom.h. Ich denke aber nicht, 
dass hier oder bei der Hardware/Versorgungsspannung das Problem liegt. 
Im Programm kann ich ja korrekt auf den eeprom zugreifen.

Das Problem liegt bei der Programmierung mit avrdude - hier wird 100% 
reproduzierbar die Bytes ab Adresse 128 ab Adresse 0 geschrieben (und 
überschreiben diese entsprechend). Schreibe ich später im Code auf 
Adresse 128, landen die Daten sehr wohl an Adresse 128...

[Tuxpilot (Gast)]

Womit programmierst du denn? Eher so ein STK500, oder mit Parallelport 
und Widerständen?

Klingt so, als würde avrdude ein Bit aus den EEPROM-Adressen ignorieren. 
Du könntest versuchen, ab Zeile 58 die „a9“-Bits hinzuzufügen (statt dem 
„x“). Dort stehen bereits mehr Adressbits als nötig, aber weniger als im 
Datenblatt vorgeschlagen.

[muli (Gast)]

Ja, ich nutze einen STK500.

Ja, vermute auch, dass irgendwie das höchste Bit ignoriert wird...

Was meinst du genau, mit a9 statt x. So hier?

        read            = " 1 0 1 0 0 0 0 0",
                          " 0 0 0 x x x a9 a8",
                          " a7 a6 a5 a4 a3 a2 a1 a0",
                          " o o o o o o o o";

        write           = " 1 1 0 0 0 0 0 0",
                          " 0 0 0 x x x a9 a8",
                          " a7 a6 a5 a4 a3 a2 a1 a0",
                          " i i i i i i i i";

Ich habe leider busher niergends eine Dokumentation zur avrdude.conf 
gefunden... was genau bedeutet die Ziffernfolge denn?

[Uwe S. (de0508)]

Hallo muli,

dies ist mein avrdude.conf Anpassung für den attiny1634.

Teste Sie bitte mal bei Dir.

[muli (Gast)]

Hallo Uwe,

danke für due conf. Sehr komisch, immer noch der gleiche Fehler! kannst 
du bestätigen, dass du bei dir damit schon mehr als 128bit EEPROM 
geschrieben hast?

danke,
muli

[muli (Gast)]

Hallo Uwe,

Sorry, meinte natürlich, ob du schon mal mehr als 128  Byte mit avrdude 
in den EEPROM geschrieben hast?

Danke,
muli

[Uwe S. (de0508)]

Hallo,

nein, ich arbeite mit einem Bootlader ohne EEpromunterstützung, so dass 
mein Programm das EErpom "initialisiert" und eine Kennung hinterlässt.

Auf die Daten wird immer als Block (Stuktur) zugegriffen.

Einmalig werden die initialen Daten von Flash-Speicher in's EEprom 
kopiert.

Danach erfolgt nur eine Kopieren der Daten zwischen EEprom --> SRam und 
zurück. Doppeltes Schreiben in's EEprom der gleichen Daten erfolgt 
nicht.

So mal in kurz..

[muli (Gast)]

Danke für den Hinweis... habe inzwischen auch eine Lösung, bei der ich 
den EEPROM Inhalt via UART nachlade, und somit das avrdude Problem 
umgehe.

Grüße,
muli

[Jörg W. (dl8dtl) (Moderator)]

Schreib mal bitte einen formalen Bugreport:

https://savannah.nongnu.org/bugs/?func=additem&group=avrdude