access violation Pointer bei LPC21XX Olimex

[Chris (Gast)]

Hallo, ich habe einen ARM LPC2148 (OLIMEX)

und versuche gerade eine verkettete Liste in C zu implementieren.

leider spuckt der mit immer die Fehlermeldung aus:

error 65: access violation at 0x00000050: no 'write' permission

Ich habe gegoogelt und bin darauf gestoßen, dass die Fehlerursache durch 
die Pointer der Liste entstehen. Da diese zur Laufzeit einen neuen 
Speicherbereich durch malloc zugewiesen bekommen. Sie waren mit NULL 
vorinitialisert. Leider fand ich dazu keine Lösung um den Fehler zu 
beheben.

Hat jemand eine Idee? Würde micht sehr sehr freuen, da ich hier schon 3 
Stunde an dem Fehler hänge!

gruss Chris

[Rufus Τ. F. (rufus)]

"Der" spuckt Dir die Fehlermeldung aus?

Quelltext? Glaskugel?

[Chris (Gast)]

Natürch der Compiler. Wenn ich den Code normal in Visual Studio C++ 
starte, kein problem halt nur wenn ich es mit µVersion von Keil starte. 
Ich habe gelesen, dass es mit dem Speicherbereich zu tun hat. Es wird 
sozusagen während der Laufzeit im Rom versucht neuen Speicher 
festzulegen(malloc), was nicht geht. Ich finde leider nirgends eine 
lösung dazu.

hier noch dir fkt:

void add_list(struct lists **top_list, char *id, char *type, char 
*para1, char *para2)
{
  struct lists *new_node, *tmp;

  new_node = (struct lists *)malloc(sizeof(struct lists));

  if(*top_list == NULL)    //erstes listenelement erzeugen
    *top_list=new_sens;

  else  //weiteres Element erzeugen
  {
    tmp=*top_list;

    while(tmp->next!=NULL)
      tmp=tmp->next;

    tmp->next=new_sens;
  }

  new_node->next=NULL;<<<<----Fehlermeldung

  strcpy(new_sens->id, id);
  strcpy(new_sens->type, type);
  strcpy(new_sens->para1, para1);
  strcpy(new_sens->para2, para2);

}

[Rufus Τ. F. (rufus)]

Der Compiler gibt diese Fehlermeldung aus? Wirklich?

Dann hat das aber GARNICHTS mit Deinem Programm zu tun, denn das läuft 
ja schließlicht nicht im Compiler, sondern auf Deiner Zielhardware.

Oder meinst Du vielleicht eher doch den Debugger?

Im übrigen solltest Du den Rückgabewert von malloc überprüfen - das gibt 
nämlich im Fehlerfalle NULL zurück. Damit ist new_node NULL und Dein 
Schreibzugriff auf new_node->next geht in die Hose.

Und dann ist die Fehlermeldung auch vollkommen in Ordnung.

[Chris (Gast)]

Wenn ich das Programm simuliere erscheint die Fehlermeldung. Wenn ich es 
auf dem ARM ausführe bleibt der hängen bzw. blockiert, was auch nicht 
verwunderlich, wenn schon die simulation scheitert.

-Ja hast recht, ich habe gerade nochmal auf NULL nach malloc abgefragt. 
Es wird nie ein Speicherbereich zugewiesen.

Hast du vielleicht eine Ahnung weshalb?

[Rufus Τ. F. (rufus)]

Weil möglicherweise die dynamische Speicherverwaltung nicht 
initialisiert ist? Was steht denn in der Dokumentation Deines Compilers 
bzw. dessen C-Standardlibrary zum Einsatz der dynamischen 
Speicherverwaltung? Könnte es sein, daß Du definieren musst, welcher 
Speicherblock als Heap genutzt werden soll und wie groß der werden soll?

[Chris (Gast)]

Ist es möglich, dass er die Variablen im ROM definert, 0x00000005 ist 
laut Datenblatt im ROM. Ich suche schon eine Weile, finde aber nur die 
Möglichkeit mit "__ram" Funktion im RAM zu definieren, jedoch nicht 
Variablen.

Gibt es die Möglichkeit Variablen explizit im RAM zu definieren?

[Rufus Τ. F. (rufus)]

Variablen liegen prinzipiell im RAM. Tun sie das bei Dir nicht, so 
vermute ich, daß der Compiler/Linker nicht weiß, wo Dein Controller RAM 
und wo er ROM hat.
Das musst Du dem Compiler/Linker bekanntgeben, entweder per 
Linkerskript, oder auf eine von Deinem Entwicklungssystem definierte Art 
und Weise.

[Chris (Gast)]

Ich bin dir so sehr dankbar!!! Es funktioniert! Ich habe nochmal nach 
"Speicherveraltung initialisieren carm" gesucht und bin fündig geworden.

Man muss nur wissen wonach man soll muss!

Nochmals danke, ich wär in "100Jahren" nicht darauf gekommen, dass man 
noch das malloc bzw. das dyn. Speichermanagment initialisieren muss.

[Rufus Τ. F. (rufus)]

Gern geschehen.