Integration der newlib in ein Cortex-M3 Projekt

[Eduard S. (rfk)]

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:

MEMORY {
  flash (rx)  : ORIGIN = 0x00000000, LENGTH = 512K
  ram1 (rwx)  : ORIGIN = 0x10000000, LENGTH = 32K
  ram2 (rwx)  : ORIGIN = 0x2007C000, LENGTH = 32K
}

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

end = ORIGIN(ram2);
__heap_start = ORIGIN(ram2);
__heap_end = ORIGIN(ram2) + LENGTH(ram2);

Weiterhin habe ich die Funktion _sbrk() rudimentär implementiert:

extern int  __heap_start;

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

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

  heap += incr;

  return (caddr_t)prev_heap;
}

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.

[Martin T. (mthomas) (Moderator)]

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?

[Eduard S. (rfk)]

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 ...?

[Eduard S. (rfk)]

Keine weiteren Ideen? Kann es an der Art liegen, mit der ich das Projekt 
übersetze und linke?

arm-none-eabi-gcc -marm -mcpu=cortex-m3 -mthumb -msoft-float -ffreestanding 
  -Wall -std=gnu99 -Wno-parentheses -fomit-frame-pointer -fshort-wchar -O3 -g 
  -I /usr/local/toolchain/cs-arm-none-eabi-4.4.1/include -I .
  -c -o main.o main.c
  
arm-none-eabi-ld --no-wchar-size-warning -L ../ldscripts -L ../crt0
  -L /usr/local/toolchain/cs-arm-none-eabi-4.4.1/lib/gcc/arm-none-eabi/4.4.1
  -L /usr/local/toolchain/cs-arm-none-eabi-4.4.1/lib -T lpc1768-heap.x
  -o main.elf main.o -lgcc -lc

[Christian S. (christian81)]

Ich hatte auch ein Problem mit memset, allerdings mit nem STM32 (hat 
aber immerhin auch nen cortex-m3) und GCC.
Der cortex kann, wenn ich mich recht entsinne, keine floating 
arithmetik. Mit
-msoft-float -mfpu=vfp
emulierst du diese dann.

Im GCC Manual (V4.4.3) findest du dazu etwas

[Eduard S. (rfk)]

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.

[Eduard S. (rfk)]

Hat sich erledigt! Ich muss natürlich gegen die thumb2-Varianten der 
Bibliotheken linken! *d'oh*

[Martin T. (mthomas) (Moderator)]

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.

[Eduard S. (rfk)]

Kannst du das begründen, warum man nicht mit dem Linker direkt linken 
sollte? Bisher hatte ich keine Probleme damit...

[Martin T. (mthomas) (Moderator)]

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.

[Eduard S. (rfk)]

Ok, danke für die Info.