EEPROM lesen funktioniert nicht

Folgendes Neues habe ich herausgefunden.
Angenommen ich beschreibe das EPPROM manuell über eeprom_write_block() 
in den eeArray mit den Werten { 2,2,1,1,1 }. Danach lese ich das EPPROM 
über ISP aus.
Ich lösche den µC und spiele das ausgelesene EPROM ein. Das Programm 
funktioniert.
Irgendwie stimmt die Adresse der Zuweisung

1

uint8_t eeArray[] EEMEM = { 2,2,1,1,1 };

 nicht mit dem später zugegriffenen EPPROM Stelle überein. Daher liest 
mir das zunächst wohl nur "Schrott" aus.

Das ausgelesene EEPROM Image entspricht nicht dem, was mir der Compiler 
aus der Zuweisung erzeugt: der Zuweisung

1

uint8_t eeArray[] EEMEM = { 2,2,1,1,1 };

 die HEX-Datei oder die .eep Datei sind unterschiedlich.
Hat einer eine Idee wieso?

Hallo Peter,

ja, das macht der Compiler auch.
Dieses EEPROM File spiele auch per ISP auf den µC. Nur wenn ich das 
generierte EEPROM File auspiele, stehen dort nicht die Werte drin.

Programmiere ich das EEPROM aber über die Funktion eeprom_write_block() 
direkt im Programm mit gleichen Werten und lese dann die EEPROM Datei 
per ISP aus. Danach lösche ich den µC und spiele die ausgelesene Datei 
auf und das ganze funktioniert.

Kann es damit zusammenhängen, dass bei der direkt vom Compiler erzeugten 
.eep Datei die Werte bei der ersten Adresse im EEPROM anfangen?
Wenn ich die vom Compiler erzeugte Datei lade ist der erste Wert in 
Bascom 3A.
Lade ich mir die ausgelesen durch eeprom_write_block() in Bascom, so 
steht in der ersten Adresse ein 00.
Ich habe nämlich im Tutorial gelesen, dass die erste Adresse nicht 
beschrieben werden sollte, aber scheinbar macht der Compiler das. Kann 
es sein, dass dort der Wurm sich versteckt? Und wenn ja, wie erzeuge ich 
dann direkt vom Compiler eine Datei, die nicht direkt bei der ersten 
Adresse beginnt?

Melanie schrieb:
> Hallo Peter,
>
> ja, das macht der Compiler auch.
> Dieses EEPROM File spiele auch per ISP auf den µC. Nur wenn ich das
> generierte EEPROM File auspiele, stehen dort nicht die Werte drin.

bzw. die Werte stehen bestimmt drin, bloß er liest nicht nicht korrekt 
aus bzw. die Stelle wird wohl nicht stimmen.

Dir ist klar, daß es die EESave Fuse bei einigen Controllern gibt, die 
das Löschen des EEProms beim Flashen steuert ? Es wäre doch immerhin 
möglich, daß der Compiler zuerst das EEProm beschreibt, dann das Flsah 
und dabei wieder das EEProm gelöscht wird.

Die Funktion besagt ja nur, wenn ich den Chip lösche, ob das EEPROM mit 
gelöscht wird oder nicht.
Da ich den Chip lösche, das Flash aufspiele und dann die EEPROM Datei, 
spielt das keine Rolle.
Es wäre nur relevant, wenn ich die EEPROM Datei nicht neu immer auspiele 
und ständig ein geändertes Programm in den Flash schiebe.

> Es wäre nur relevant, wenn ich die EEPROM Datei nicht neu immer auspiele
> und ständig ein geändertes Programm in den Flash schiebe.

Kommt darauf an, wie das Aufspielen des Codes und des EEproms im 
Einzelnen vor sich geht. Das Beschreiben des EEProms und das Flashen des 
Codes sind zwei unterschiedliche Prozesse, das passiert nicht auf 
einmal. Deswegen einfach mal die Fuse ändern und sehen was passiert ;-)

> Wenn man die Programmierschritte manuell ausführt, sollte die Fuse kein
> Problem sein. Nur beim automatischen Programmierablauf wird der
> Masserase automatisch durchgeführt.

Das wäre logisch. Nur ist's ein kleiner Klick und schon weis man, ob's 
daran hängt.

Im MAP File steht bezüglich des EEPROMS folgendes:

.eeprom         0x00810000        0x5
 *(.eeprom*)
 .eeprom        0x00810000        0x5 attiny13.o
                0x00810000                eeArray
                0x00810005                __eeprom_end = .

Hier noch die beiden EEPROMS im Vergleich.
Einmal das direkt vom Compiler erzeugte und einmal, wenn ich das EEPROM 
mit gleichen Werten mauell über eeprom_write_block() beschreibe.

MWS schrieb:
> Das wäre logisch. Nur ist's ein kleiner Klick und schon weis man, ob's
> daran hängt.

Das habe ich auch versucht, bringt leider keine Änderung.

Das attiny13.eep ist das vom Compiler erzeugte.
Das eeprom.HEX ist das von mir ausgelesene nach eeprom_write_block() mit 
gleichen Werten.

Also ich seh' die Sequenz "2,2,1,1,1" nirgends in diesen Dateien, 
genauso wenig wie auf den Bascom Programmer Screenshots.

Hallo,

so, ich habe das Program mal wirklich auf ein absolutes Minimum 
reduziert und wie folgt geschrieben:

1

#ifndef F_CPU

2

#define F_CPU           9600000UL                   // processor clock frequency 9,6Mhz

3

#endif

4

5

#include <avr/io.h>

6

#include <util/delay.h>

7

#include <avr/eeprom.h>

8

#include <avr/interrupt.h>

9

#include <inttypes.h>      // Makros für int Datentypen                      

10

11

// ------------------------------------------------------------------------------------------------

12

// DEFINES

13

// ------------------------------------------------------------------------------------------------

14

15

//Define für EEPROM

16

#ifndef EEMEM

17

// alle Textstellen EEMEM im Quellcode durch __attribute__ ... ersetzen

18

#define EEMEM __attribute__ ((section (".eeprom")))

19

#endif

20

21

void init(void);

22

// ------------------------------------------------------------------------------------------

23

// Variabelen im EEPROM

24

// ------------------------------------------------------------------------------------------

25

uint8_t eeArray[] EEMEM = { 0,0,1,1,1 }; // Vorgabe Code im EEPROM

26

27

28

29

// main prog

30

int main(void)

31

{

32

    // Ports und Interrupts initialisieren

33

  init();   

34

35

    while (1)

36

  {

37

38

  }

39

40

}

41

 /* 

42

 * Funktion init(): Initialisierung des µC 

43

 */ 

44

void init(void) 

45

{

46

  // --------------------------------------------------------------------------------------------

47

  // PORTB konfigurieren

48

  //

49

  // --------------------------------------------------------------------------------------------

50

  DDRB = 0; 

51

  DDRB |= (1 << PB1) | (1 << PB2) ;    

52

  PORTB |= (1<<PB2) | (1 << PB4);      

53

54

55

  // --------------------------------------------------------------------------------------------

56

  // Timer 0 (8-Bit) 

57

  // --------------------------------------------------------------------------------------------

58

  TCCR0A |= (1<<WGM01);   // CTC Mode OC0A

59

  TCCR0B |= (1<<CS01);  // Prescaler 8

60

  TIMSK0 |= (1<<OCIE0A);  // Enable Compare Match A des Timers

61

  OCR0A = 149;      // Compare Register

62

   TCNT0 = 0;         // Counter auf 0 initialisieren

63

64

65

   sei();          // setzt globales Interrupt Enable Bit

66

  return;

67

}

Das Programm enthält lediglich die Initialisierng meiner benötigten 
Register, sowie die Vorbelegung des EEPROMS Array eeArray mit 5 Werten 
{0,0,1,1,1}.
Die erzeugte EEPROM .eep Datei enthält diese Werte jedoch nicht.
Anbei das Program in in einer .c Datei, die entstandene .eep Datei und 
das Makefile.

Ich hoffe jemand kann helfen.

Karl heinz Buchegger schrieb:
> Aber:
> Wenn wir uns mal deinen Screenshot ansehen, dann stellen wir fest, dass
> das Programmiertool mit dem EEP File nichts anzufangen wusste. Das hat
> das ganze als stink normales ASCII Textfile eingelesen.
> Benutz doch bitte eine vernünftige Programmiersoftware, die auch weiß,
> dass ein EEP File einfach nur ein INTEL-Hex File mit einer anderen
> Dateiendung ist.

Dann wird das wohl der Fehler sein. Das Programm ist dann wohl in 
Ordnung, nur die Programmiersoftware ist für diesen Zweck Müll. Dann 
werde ich wohl auf PonyProg umsteigen...

Danke.

> Das Programm ist dann wohl in Ordnung, nur die Programmiersoftware ist für
> diesen Zweck Müll

Naja, Bascom weis schon was es mit dem von ihm selbst erzeugten EEP File 
anzufangen hat, denn es wird dort als Binärddatei erzeugt und im 
Programmer auch so (richtig) geschrieben. Diese Info ist u.A. unter 
$EEPROMHEX zu finden, hättest halt mal auch Hilfe zu Bascom lesen 
sollen, bevor Du es einsetzt.

Versteh' allerdings auch nicht wieso Du Bascom verwendest, wenn Du C 
programmieren willst. Für C würde ich das AVR Studio zum Programmieren 
nehmen, das reicht locker und man braucht kein Pony-Prog, außer 
vielleicht für exotische Programmer-HW.