Nach Initialisierung falsche Werte im Struct

[Artur (arwar)]

Halo Kollegen.
Komme mit Initialisierung einer Struktur nicht weiter.
Mikrokontroller - STM32-F103-Olimex,  IDE – Eclipse,  Compiler - GCC, 
G++

Der Compiler meckert nicht  aber die Werte der initialisierten Struktur 
sind  falsch.

Die Struktur beschreibt einen Zeichensatz (Font) für die Ausgabe am LCD 
Display.

//Display.h

#parma   //--- wird vom Compiler ignoriert ???

typedef struct {
const short *table;  // Tabelle mit den Font Daten
  short width;    // Breite des Zeichens (in Pixel)
  short height;    // Hoehe  des Zeichens (in Pixel)
}Font_t;

Anderen Daten und Code sind im „Display.c“ gesammelt um den Fehler zu 
lokalisieren.

Die Font Tabelle  (*table).

const short Arial_7x10_Table [] = {
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, // Ascii = [ ]
0x10,0x10,0x10,0x10,0x10,0x10,0x00,0x10,0x00,0x00, // Ascii = [!]
 . .  insgesamt 95 Zeilen, je 10 Hex Werte
};

Initialisierung

Font_t Arial_7x10 = {      //Variable Arial_7x10 erzeugen, Typ Font_t
  .table = Arial_7x10_Table,  // Adresse der ZeichenTabelle zuweisen
  .width = 7,        // Schriftbreite setzen
  .height = 10        // Schrifthöhe   . . .
};

Beim Debuggen - kein Wert stimmt: Variable   .width sollte = 7 sein, 
.height = 10.
---Bild „StructDaten.png“

Tabelle hat eine falsche Adresse.
 ---Bild „Tabelle.png“.

Man könnte es mit der Tabellenadresse vergeigen, aber 2 anderen Werte 
sind doch DIREKT zugewiesen.

Was mache ich falsch?????

[Oliver S. (oliverso)]

Artur schrieb:
> #parma   //--- wird vom Compiler ignoriert ???

Dem fehlt der Schinken.

Regel#1 hier im Forum und auch anderswo: immer den Original-Quellcode 
zeigen.
Regel#2 hier im Forum und auch anderswo: immer den ganzen Quellcode 
zeigen.

Stackoverflow, Array out of bounds, oder wie auch immer du die Daten 
überschreibst.

Oliver

[Niklas G. (erlkoenig)]

Entweder dein Startupcode oder Linkerscript ist defekt, oder die 
Variable Arial_7x10 wird von einem "wilden Pointer" überschrieben 
(Buffer Overflow o.ä.).

Wenn das Programm ganz am Anfang ist (Anfang der main()), sind die Daten 
dann richtig? -> Watchpoint drauf setzen und laufen lassen.

Sind die Daten da schon falsch? Breakpoint im Startupcode NACH das " bcc 
CopyDataInit" setzen und schauen ob es dann stimmt - wenn ja, Watchpoint 
setzen und laufen lassen. Wenn nein, ist was am Startupcode/Linkerscript 
kaputt.

[Alexander (alecxs)]

Welches Flag für Compiler Optimierung hast Du gesetzt? versuche es mal 
mit -Og

[J. S. (jojos)]

Die Fehlermeldungen vom Debugger sehen nicht gut aus, da werden doch nur 
Fahrkarten angezeigt?

[Artur (arwar)]

Niklas G. schrieb:
>
> Wenn das Programm ganz am Anfang ist (Anfang der main()), sind die Daten
> dann richtig? -> Watchpoint drauf setzen und laufen lassen.
>

> von Oliver S. (oliverso)
>Stackoverflow, Array out of bounds, oder wie auch immer du die Daten
>überschreibst.
>

Danke für den Tipp.
Hab einen kleine Struct erzeugt und diesen intialisiert an der gleichen 
Stelle mit dem alten Struct - auch der neuer Strukt wurde falsch 
initialisiert.

Am Anfang des Programms (Anfang der main()) hat alles sauber geklappt.
Muss mal sehen wie ich den Stack checken kann.

[Εrnst B. (ernst)]

Artur schrieb:
> Am Anfang des Programms (Anfang der main()) hat alles sauber geklappt.

Die Structs werden nicht durch "Magie" befüllt, das macht der µC schon 
schön selber in seinem Startup-Code. Wenn du deinen Breakpoint zu früh 
hast, kannst du dem µC zuschauen, wie er der Reihe nach seine globalen 
Variablen und Structs initialisiert. Am Anfang von "main" ist er damit 
fertig...

[Niklas G. (erlkoenig)]

Artur schrieb:
> Muss mal sehen wie ich den Stack checken kann.

Setze einfach einen Watchpoint auf das struct und lasse das Programm 
laufen. Das Programm wird dann genau an der Stelle unterbrechen wo der 
fehlerhafte Zugriff ist. Geht blitzschnell.

[Jens M. (schuchkleisser)]

Warum ist der Font für das Display "Short" (das sind Bytes), und warum 
sollte die Struct erst initialisiert werden müssen? Die ist doch wohl 
hoffentlich im Flash? Oder ist der Prozessor behindert und kann 
Displaydaten nur aus dem RAM lesen?

[Niklas G. (erlkoenig)]

Jens M. schrieb:
> Die ist doch wohl hoffentlich im Flash

Nein, weil kein "const" dran steht kommt es in den RAM und muss erst 
kopiert werden.

[Harald K. (kirnbichler)]

Jens M. schrieb:
> Warum ist der Font für das Display "Short" (das sind Bytes)

Wenn der Font auch breiter werden kann als 8 Pixel, könnte das einen 
Sinn haben - aber warum dann ein Datentyp mit Vorzeichen?

[Jens M. (schuchkleisser)]

Niklas G. schrieb:
> Nein, weil kein "const" dran steht kommt es in den RAM und muss erst
> kopiert werden.

Soweit mir bekannt wird auch const bei manchen Prozessoren im RAM (oder 
gar in Registern) gelagert, weil schneller/kürzer zugreifbar.
Zumindest bei AVRs muss man auch noch PROGMEM angeben, um es sicher ins 
Flash zu packen.

[Niklas G. (erlkoenig)]

Jens M. schrieb:
> Soweit mir bekannt wird auch const bei manchen Prozessoren im RAM (oder
> gar in Registern) gelagert

Ja, hängt vom Linkerscript ab. Aber beim STM32 wird normalerweise alles 
was "const" ist in den Flash gelegt.