Integration der newlib in ein Cortex-M3 Projekt

OP #1705794
Hallo, ich möchte die newlib in ein Projekt mit einem Cortex-M3 
(LPC1768) integrieren. Als Toolchain habe ich dafür erstmal die von 
Codesourcery (inklusive newlib) gewählt, die ohne newlib Unterstützung 
auch funktioniert.

Im Linkerscript habe ich den Stack in den lokalen SRAM (32K) und den 
Heap in den AHB SRAM (32K) gelegt:
1
MEMORY {
2
  flash (rx)  : ORIGIN = 0x00000000, LENGTH = 512K
3
  ram1 (rwx)  : ORIGIN = 0x10000000, LENGTH = 32K
4
  ram2 (rwx)  : ORIGIN = 0x2007C000, LENGTH = 32K
5
}
6

7
_stack_end = ORIGIN(ram1) + LENGTH(ram1);
8

9
end = ORIGIN(ram2);
10
__heap_start = ORIGIN(ram2);
11
__heap_end = ORIGIN(ram2) + LENGTH(ram2);

Weiterhin habe ich die Funktion _sbrk() rudimentär implementiert:
1
extern int  __heap_start;
2

3
caddr_t _sbrk (int incr) {
4
  static unsigned char *heap = NULL;
5
  unsigned char *prev_heap;
6

7
  if (heap == NULL) heap = (unsigned char *)&__heap_start;
8
  prev_heap = heap;
9

10
  heap += incr;
11

12
  return (caddr_t)prev_heap;
13
}

Wenn ich das Ganze mit einem Demoprojekt übersetze und linke, kommen 
keine Fehler. Leider bleibt der Controller jedoch stehen, sobald ich 
eine Funktion (z.B. memset, malloc, etc.) aus der newlib aufrufe.

Habe ich noch etwas vergessen? Danke vorab.
Moderator Persönliche Seite
Testweise Heap nach .data/.bss im "normalen" RAM starten lassen. Wenn 
das funktioniert, kann man nachsehen, ob AHB-RAM irgendwie eingerichtet 
werden muss (mit LPC17xx bisher selbst noch nichts gemacht). Wird sbrk 
aufgerufen und liefert es vernünftige Rückgabewerte? Werden 
Fault-Excpetions ausgelöst?
OP
Den Heap in den lokalen SRAM zu verlegen bringt nichts. Ich glaube auch 
nicht, dass es am Speicher selbst liegt, denn sonst müssten doch 
Funktionen wie memset() im Stack funktionieren? Der AHB SRAM ist 
übrigens ganz normal nutzbar und bedarf keiner weiteren Initialisierung. 
Laut OpenOCD befindet sich der Controller im Fehlerfall im HardFault 
Handler ...?
OP
Keine weiteren Ideen? Kann es an der Art liegen, mit der ich das Projekt 
übersetze und linke?
1
arm-none-eabi-gcc -marm -mcpu=cortex-m3 -mthumb -msoft-float -ffreestanding 
2
  -Wall -std=gnu99 -Wno-parentheses -fomit-frame-pointer -fshort-wchar -O3 -g 
3
  -I /usr/local/toolchain/cs-arm-none-eabi-4.4.1/include -I .
4
  -c -o main.o main.c
5
  
6
arm-none-eabi-ld --no-wchar-size-warning -L ../ldscripts -L ../crt0
7
  -L /usr/local/toolchain/cs-arm-none-eabi-4.4.1/lib/gcc/arm-none-eabi/4.4.1
8
  -L /usr/local/toolchain/cs-arm-none-eabi-4.4.1/lib -T lpc1768-heap.x
9
  -o main.elf main.o -lgcc -lc
OP
Eigentlich müssten die beiden Parameter doch in Konflikt miteinander 
stehen? Einerseits kompilierst du mit Soft-Floating-Support und 
andererseits für eine Vector Floating Point Unit, die der Cortex-M3 
nicht hat. Aber wie auch immer, es ändert leider gar nichts.

Noch zur Information: wenn ich durch das Programm steppe, springt er 
direkt beim Aufruf von malloc() in den HardFault Handler.
Moderator Persönliche Seite
Nienicht direkt mit *-ld linken, sondern mit dem Compiler-Frontend 
(*-gcc bzw. *-g++ bei C++-Projekten). Der Frontend setzt schon die 
passenden Optionen beim indirekten Aufruf des Linkers und man braucht 
diese dann nicht mehr "manuell" vorzugeben.
Bisher habe ich die FP-Optionen noch bei keinem Projekt benötigt. 
Allerdings bis dato auch nur mit ARM7TDMI(-S) und Cortex-M3 gearbeitet, 
die keine FP-Hardware haben.
Moderator Persönliche Seite
Eduard Steinberg schrieb:
> Kannst du das begründen, warum man nicht mit dem Linker direkt linken
> sollte? Bisher hatte ich keine Probleme damit...

Genau: "bisher". Einfach ausprobieren: linkt man über das Frontend, 
braucht man nicht extra irgend etwas mit "thumb2" vorzugeben. GCC 
erkennt anhand von -mcpu=... schon was gebraucht wird gibt intern die 
passenden Optionen an den Linker. Viele Problemberichte in diesem (v.a. 
im englischsprachigen ARM-GCC-) und anderen Foren sind auf direkten 
ld-Aufruf zurückzuführen. Scheint ein nicht unübliches Problem bei 
Umstieg von Architekturen ohne multlibs auf welche mit mehreren 
vorkompilierten Libraries wie z.B. bei cross-toolchains für verschiedene 
ARM-cores/-modi (arm, thumb, interwork, thumb2...). O.k. "Begrüdung": 
warum etwas mglw. falsch oder vergeblich mit Zeitaufwand von Hand 
einstellen, wenn das ein Computer übernehmen kann.

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 16 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.