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):
1
uint8_ttest[5]EEMEM={3,4,5,6,7};
2
uint8_ttest2[128]EEMEM={9,8,9,9,9};
3
4
(...)
5
6
_writeNumber(eeprom_read_byte(&test[1]));
7
_writeNumber((uint8_t)(int)&test[1]);
8
_writeNumber(eeprom_read_byte(&test2[1]));
9
_writeNumber((uint8_t)(int)&test2[1]);
10
11
eeprom_write_byte(&test[1],25);
12
eeprom_write_byte(&test2[1],26);
13
14
_writeNumber(eeprom_read_byte(&test[1]));
15
_writeNumber((uint8_t)(int)&test[1]);
16
_writeNumber(eeprom_read_byte(&test2[1]));
17
_writeNumber((uint8_t)(int)&test2[1]);
Das Ergebnis ist das Folgende:
1
000129 >> test Wert 2 in EEPROM Adresse 129: ist 0, sollte 4 sein
2
004001 >> test2 Wert 2 in EEPROM Adresse 1: ist 4, sollte 8 sein
3
025129 >> schreiben innerhalb des Programs auf Adresse 129 klappt
4
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
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?
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
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
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...
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.
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
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..
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
