eeprom_read_block Problem

[Frank L. (franklink)]

Hallo zusammen,
ich habe ein kleines Verständnisproblem::

Ich möchte einfach nur einen Bereich aus einem Array mit 
eeprom_read_block auslesen. Aber irgendwie schickt die Funktion mein 
Programm ins nirvana.

Strukturdefinition:

#define NUMBER_OF_RGB_LED  2
#define NUMBER_OF_RGB_TABLE 8

typedef struct _colorstruc 
{
  unsigned char H;
  unsigned char S;
  unsigned char V;
  unsigned char Speed;
  unsigned char red_pwm;
  unsigned char green_pwm;
  unsigned char blue_pwm;
  unsigned char Pin_R;
  unsigned char Pin_G;
  unsigned char Pin_B;
} colorstruc;

typedef struct _colorproc
{
  colorstruc colorstrucs[NUMBER_OF_RGB_LED];
} colorproc;

EEPROM Arraydefinition:

EEMEM colorproc colortable[8] =
{
    { 
      { 
        // White 
        { 0x00, 0x00, 0xFF, 200, 0, 0, 0, 1, 2, 3 },
        { 0x00, 0x00, 0xFF, 200, 0, 0, 0, 4, 5, 6 } 
      }
        }, 
    { 
      { 
        // Bright red
      { 0x00, 0xFF, 0xFF, 0xC8, 0, 0, 0, 0, 1, 2 },
        { 0x00, 0xFF, 0xFF, 0xC8, 0, 0, 0, 3, 4, 5 } 
      }
        }, 
    { 
      { 
        // Bright yellow
      { 0x2A, 0xFF, 0xFF, 0xC8, 0, 0, 0, 0, 1, 2 },
        { 0x2A, 0xFF, 0xFF, 0xC8, 0, 0, 0, 3, 4, 5 } 
      }
        }, 
    { 
      { 
        // Bright green
      { 0x55, 0xFF, 0xFF, 0xC8, 0, 0, 0, 0, 1, 2 },
        { 0x55, 0xFF, 0xFF, 0xC8, 0, 0, 0, 3, 4, 5 } 
      }
        }, 
    { 
      { 
        // Bright cyan
      { 0x80, 0xFF, 0xFF, 0xC8, 0, 0, 0, 0, 1, 2 },
        { 0x80, 0xFF, 0xFF, 0xC8, 0, 0, 0, 3, 4, 5 } 
      }
        }, 
    { 
      { 
        // Bright blue
      { 0xAA, 0xFF, 0xFF, 0xC8, 0, 0, 0, 0, 1, 2 },
        { 0xAA, 0xFF, 0xFF, 0xC8, 0, 0, 0, 3, 4, 5 } 
      }
        }, 
    { 
      { 
        // fast cycle
      { 0x00, 0xFF, 0xFF, 0x0A, 0, 0, 0, 0, 1, 2 },
        { 0x00, 0xFF, 0xFF, 0x0A, 0, 0, 0, 3, 4, 5 } 
      }
        }, 
    { 
      { 
        // fast cycle low sat
      { 0x00, 0x7F, 0xFF, 0x32, 0, 0, 0, 0, 1, 2 },
        { 0x00, 0x7F, 0xFF, 0x32, 0, 0, 0, 3, 4, 5 } 
      }
        }
};

Ziel-Array:

colorproc colors[1] =
{
  { 
    { 
      { 0x00, 0xFF, 0xFF, 0xC8, 0, 0, 0, 1, 2, 3 },
      { 0x00, 0xFF, 0xFF, 0xC8, 0, 0, 0, 4, 5, 6 } 
    }
  }
};

und so lese ich:

eeprom_read_block( (void*)&colors[0], (const void*)&colortable[0], sizeof( colorproc ) );

Wäre für den entscheidenden Tip dankbar.

Gruß
Frank

[Johann L. (gjlayde)]

Das ist es denn für ein µC?

Neuere Versionen der avr-libc ignorieren einen Siliconbug einiger 
AVR-Derivate. Es wird eine ungültige Instruktion erzeugt, die im Manual 
verboten wurde.

Ob das das Poroblem ist, siehst du bei einer Sichtung des Disassemblies 
nebst Errata deines µC.

[Frank L. (franklink)]

Hallo Johann,
nee, glaub ich nicht, ich verwende die gleiche Struktur in einer anderen 
Anwendung um Daten aus einem zwei dimensionalen EEMEM-Array zu lesen. 
Der Unterschied hier ist lediglich die Struktur in die ich die Daten 
einlesen möchte.

Ich vermute einfach nur ein falscher Aufruf... D.h. falsche 
Parametrisierung.

Gruß
Frank

[Stefan E. (sternst)]

Schau nochmal genau hin, ob es nicht noch einen weiteren Unterschied 
gibt, nämlich die Optimierungsstufe. Die fehlerhafte Instruktion wird 
nur erzeugt, wenn die Optimierung abgeschaltet ist.

[Frank L. (franklink)]

Vergessen:

Prozessor: ATMega8
Board: MyAvrUsb
Umgebung: AVR Studio 4.13.557

Gruß
Frank

[Werner B. (werner-b)]

1. Und das Wichtigste, die Compilerversion?

2. Workaround für das Compilerproblem = leere ISR für den EEProm 
Interrupt definieren.

3. EEMEM Daten werden vom Compiler "im Prizip" genauso behandelt wie 
Daten im Progmem. Es gelten also im wesentlichen auch die gleiche 
Beschränkungen.
Du kannt insbesondere den Abschnitt 
AVR-GCC-Tutorial: Array aus Zeichenketten im Flash-Speicher aus dem 
Tutorial auf dein Problem mit dem EEProm übertragen.
Ich fürchte so wird das nicht funktionieren. :-(

Werner

[Frank L. (franklink)]

Hallo Werner,
ich denke, das Problem liegt an sizeof( colorproc ). Ich hatte mir den 
Wert mal per UART ausgeben lassen und erhalte hier den Wert 0x20 an 
Stelle von 0x14.

In der Simulation läuft die Anwendung einwandfrei. Also liegt die 
Vermutung nahe, dass ich mir irgendwo Speicher überschreibe.

Ich werde heute Abend nochmals in Ruhe und mit dem notwendigen Abstand 
forschen.

Danke schon mal für die Ratschläge.

Gruß
Frank

[Werner B. (werner-b)]

> ...erhalte hier den Wert 0x20 an Stelle von 0x14.

Könnte das nicht nur ein Darstellungsproblem sein?  Denn 0x14 = 20Dez ?

[Frank L. (franklink)]

Hallo Werner,
eigentlich nicht, ich verwende eine Funktion für den Uart die mir einen 
Hex-Wert liefert. Da ich diese Funktion an anderer Stelle auch verwende 
und sie dort korrekte Werte liefert...

Aber wie so oft, der Teufel liegt im Detail, werde ich also heute Abend 
nochmals prüfen.

Ich werde heute Abend mal das ganze Teil posten. Mal sehen ob sich 
jemand erbarmt und mal rein schaut. Sitze schon zu lang an dem Problem 
und sehe wahrscheinlich mal wieder den Wald vor lauter Bäumen nicht 
mehr.

Gruß
Frank

P.S. eigentlich sollte das doch so richtig sein, oder?

[Stefan E. (sternst)]

Frank Link wrote:

> ich denke, das Problem liegt an sizeof( colorproc ). Ich hatte mir den
> Wert mal per UART ausgeben lassen und erhalte hier den Wert 0x20 an
> Stelle von 0x14.

Sehr unwahrscheinlich. Die bereits angesprochene mögliche Hex<->Dez 
Verwechselung ist hier deutlich wahrscheinlicher.

Und mal so nebenbei: Bist du meinem Hinweis bezüglich der 
Optimierungsstufe mal nachgegangen?

[Johann L. (gjlayde)]

Werner B. wrote:
> 1. Und das Wichtigste, die Compilerversion?

Falls es der EERE-Bug ist, ist die Version der avr-libc interessanter. 
Neuere Versionen machen da nen ziemlich umständlichen indirekten call 
und wenn nicht alles komplett wegoptimiert wird, crasht es.

Zudem würd ich meine Hand nicht ins Feuer dafür legen, daß das Problem 
je nach C-Kontext nicht auch bei höheren Optimierungsstufen zum Tragen 
kommt.

Ergo: Nur ein Disassembly liefert Sicherheit.

Der Bug ist für ATmega8 aktiv.


Probleme kann es auch geben, wenn ein Modul mit -fpack-struct übersetzt 
ist und eines ohne.

Und in den Initializern kann ich eine {}-Ebene nicht zuordnen, scheint 
eine zu viel zu sein?

[Frank L. (franklink)]

Hallo Stefan,
nein, dem Optimierungproblem bin ich noch nicht nachgegangen, da ich 
erst heute Abend wieder daran arbeite.

Ist kein Problem, dass ich im Bürö habe.

Die Anwendung ist eine kleine Spielerei von mir für ein Moodlight.

Wie geschrieben, ich stelle heute Abend mal den Sourcecode und alle 
anderen Infos ein.

Gruß
Frank

[Johann L. (gjlayde)]

Frank Link wrote:
> Hallo Stefan,
> nein, dem Optimierungproblem bin ich noch nicht nachgegangen, da ich
> erst heute Abend wieder daran arbeite.

hmmm, soweit ich sehe, benutzt die neueste Version der avr-libc (1.6.4) 
explitit ein IN, so daß der Silicon-Bug nicht getriggert werden dürfte.

Da weiß Jörg bestimmt mehr drüber zu sagen, für welchen lib-Versionen 
überhaupt problematischer Code erzeugt werden könnte.