LPC2378 - region RAM is full

[ARMdran (Gast)]

Hallo Forum,

ich erweitere gerade ein Programm auf einem LPC2378 und benutze den 
arm-elf-gcc (GCC) 4.3.2

Nun bekomme ich folgende Fehlermeldung:

c:/yagarto/bin/../lib/gcc/arm-elf/4.3.2/../../../../arm-elf/bin/ld.exe: region RAM is full (programm.elf section .stack)

Vor der letzten Änderung (Anlegen einer Variablen) klappte noch alles 
und ich bekam die Ausgabe:

Size after:
   text     data      bss      dec      hex  filename
 137996     5720    13660   157376    266c0  programm.elf

fat_mci_demo.elf  :
section             size         addr
.text             137996            0
.data               5720   1073741824
.initdata           5720       137996
.bss               13660   1073747544
.stack             13312   1073761208
.comment            2142            0
.debug_aranges      8208            0
.debug_pubnames    23543            0
.debug_info       201246            0
.debug_abbrev      45111            0
.debug_line        53422            0
.debug_frame       20024            0
.debug_str         36631            0
.debug_loc         98745            0
.ARM.attributes       16            0
.debug_ranges      12736            0
Total             678232

Meine Hoffnung ist, dass vielleicht irgendwelche ungenutzten Sections im 
Ram liegen, aber durch die startup.S und ROM.ld steige ich nicht so 
richtig durch. Ich hänge beide Dateien mal an.

Der Controller hat 32kB Ram.
Wenn ich da aber nicht völlig falsch liege, dann bin ich mit .data + 
.bss + .stack = 32692 ziemlich am Anschlag, oder?

Dann habe ich ein Problem...

Es gibt aber noch extra Ram für Ethernet, USB und RTC.
Ich weiß nicht genau, ob es genutzt wird und ob es überhaupt anderweitig 
genutzt werden kann.

Ich hoffe ihr könnt mir helfen!

[ARMdran (Gast)]

Mir kommt die .stack section sehr groß vor...

[ARMdran (Gast)]

Wie kann ich mir das MAP file sortiert nach Variablengröße ausgeben 
lassen?
Nach Adressen sortiert ist das sehr schwer zu überblicken.

Und kann mir jemand sagen, wo hier direkt am Anfang mal eben 1kB 
verschwinden?
.data           0x40000000     0x1658 load address 0x00021b7c
                0x40000000                _data = .
 *(.vectmapped)
                0x40000000                . = ALIGN (0x4)
 *(.fastrun)
                0x40000000                . = ALIGN (0x4)
                0x40000000                . = ALIGN (0x4)
 *(.data)
 .data          0x40000000      0x404 
c:/yagarto/bin/../lib/gcc/arm-elf/4.3.2/../../../../arm-elf/lib/thumb/in 
terwork\libc.a(lib_a-impure.o)
                0x40000000                _impure_ptr
 .data          0x40000404        0x4 
c:/yagarto/bin/../lib/gcc/arm-elf/4.3.2/../../../../arm-elf/lib/thumb/in 
terwork\libc.a(lib_a-ctype_.o)
                0x40000404                __ctype_ptr

Irgendwas könnte das mit der thumb Option zu tun haben...

Und im Linkerscript, was werden hier für Zahlen abgezogen?
/* Memory Definitions */
MEMORY
{
  ROM (rx) : ORIGIN = 0x00000000, LENGTH = (512k-4k)
  RAM (rw) : ORIGIN = 0x40000000, LENGTH = (32k-32)
}

[ARMdran (Gast)]

Also anscheinend kann das Ethernet RAM auch als "normales" RAM genutzt 
werden, wenn man es richtig konfiguriert.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka11495.html

Ich benutze aber die Ethernetschnittstelle.
Wird dann das Ethernet RAM automatisch dafür genutzt, oder wie wird das 
verwendet?

[holger (Gast)]

.data               5720   1073741824
.bss               13660   1073747544
.stack             13312   1073761208

= 32692

Hmm, irgendwo saust du da richtig heftig mit RAM rum.

>Mir kommt die .stack section sehr groß vor...

Mir auch;)

[ARMdran (Gast)]

Ich habe zum Beispiel im Map file gesehen, dass meine fast 2kB an 
Parametern die eigentlich im Battery buffered RAM liegen sollen, auch im 
SRAM liegen.
Muss das sein, oder kann man auch direkt aus dem battery buffered RAM 
wie mit SRAM arbeiten?

[ARMdran (Gast)]

ARMdran schrieb:
> Und kann mir jemand sagen, wo hier direkt am Anfang mal eben 1kB
> verschwinden?
> c:/yagarto/bin/../lib/gcc/arm-elf/4.3.2/../../../../arm-elf/lib/thumb/in
> terwork\libc.a(lib_a-impure.o)
>                 0x40000000                _impure_ptr
>  .data          0x40000404        0x4
> c:/yagarto/bin/../lib/gcc/arm-elf/4.3.2/../../../../arm-elf/lib/thumb/in
> terwork\libc.a(lib_a-ctype_.o)
>                 0x40000404                __ctype_ptr
>
> Irgendwas könnte das mit der thumb Option zu tun haben...

Ich habe auch noch mal ohne die Option "Thumb" kompiliert, dann ändert 
sich der Pfad im obigen Auszug. Aber es gibt immer noch diesen Sprung 
von 0x40000000 auf 0x40000404, was 1kB entspricht...

[scherieh (Gast)]

ARMdran schrieb:
> Ich habe zum Beispiel im Map file gesehen, dass meine fast 2kB an
> Parametern die eigentlich im Battery buffered RAM liegen sollen, auch im
> SRAM liegen.

"auch"? Oder NUR im SRAM?
Ich vermute das zweite.

> Muss das sein, oder kann man auch direkt aus dem battery buffered RAM
> wie mit SRAM arbeiten?

Vermutlich, ich kenne den LPC nicht.
Eigene Sections für das buffered RAM definieren
und die Variablen entsprechend zuweisen, ähnlich wie das Dein
Linkerscript für das normale RAM macht. Einfach die
RAM Sections duplizieren und Kopie entsprechend umbenennen.
RAM Adressen der Kopie anpassen.

Beachten, dass der Startup Code diese Sections auch geeignet
initialisieren muss.

Für die GNU Binutils gibt es ein schönes Manual, da wird das 
beschrieben.

[ARMdran (Gast)]

Da muss ich wohl irgendwie alleine durch...

Zumindest etwas weiter bin ich:
1. Der LPC2388 hat doppelt so viel SRAM und ist pinn- und 
funktionskompatiblen, löst damit also mein Problem mit der 
Holzhammermethode
2. Liefert mir der Befehl:

arm-elf-nm --size-sort --print-size $(TARGET_OUTPUT).elf

eine nach Größe sortierte Ausgabe der Symbols
3. Damit habe ich dann schnell gesehen, dass mir z.B. ein Font mal eben 
4kB SRAM geklaut hat, weil er nicht "const" war

Was mich noch interessiert:
1. Warum ist die .stack Section auf 13312 Byte fest genagelt?
2. Wie bekomme ich das Parameterarray in den Battery Buffered RAM?
3. Wie nutze ich den Ethernet SRAM als normales RAM bzw. geht das 
überhaupt, wenn ich Ethernet nutzen möchte?
4. Immer noch die Frage: Was werden hier für Zahlen abgezogen?

/* Memory Definitions */
MEMORY
{
  ROM (rx) : ORIGIN = 0x00000000, LENGTH = (512k-4k)
  RAM (rw) : ORIGIN = 0x40000000, LENGTH = (32k-32)
}

[ARMdran (Gast)]

ARMdran schrieb:
> 1. Warum ist die .stack Section auf 13312 Byte fest genagelt?

Ok, im ganz oben verlinkten File "startup_gnu.S" steht folgendes, was 
13312 Byte ergibt...

.equ UND_Stack_Size,     0x00000000
.equ SVC_Stack_Size,     0x00000200
.equ ABT_Stack_Size,     0x00000000
.equ FIQ_Stack_Size,     0x00000000
.equ IRQ_Stack_Size,     0x00000A00
.equ USR_Stack_Size,     0x00002800

.equ Stack_Size,        (UND_Stack_Size + SVC_Stack_Size + ABT_Stack_Size + FIQ_Stack_Size + IRQ_Stack_Size + USR_Stack_Size)

Ist das sinnvoll?

[ARMdran (Gast)]

So, die Lernkurve war steil und ich kann mir jetzt fast alle Fragen 
selbst beantworten:

Zu 2. habe ich herausgefunden, dass mein Array über einen Pointer im 
Battery RAM landet:

volatile u32 *Param32Buffer  =(volatile u32 *)(0xE0084000); //RTC-RAM

Direkt dort hin legen konnte ich es jetzt nicht so einfach, da das 
Battery RAM nur einen word-wise (32bit) Zugriff erlaubt.
Das wird bei mir über eine Funktion geregelt.

Ich habe aber mein Array in den USB ram verschoben, da das ungenutzt 
ist.

s16 P16[PARAM16_COUNTMAX] __attribute__ ((section (".usbram")));

Dafür habe ich eine neue Section im Linkerscript angelegt.

/* Memory Definitions */
MEMORY
{
  ROM (rx) : ORIGIN = 0x00000000, LENGTH = (512k-4k)    /* Flash: 512k - boot code 4kbyte*/
  RAM (rw) : ORIGIN = 0x40000000, LENGTH = (32k-32)     /* SRAM: 64k - IAP work 32byte */
  /* added 22.03.2013 */
  URAM (rw): ORIGIN = 0x7FD00000, LENGTH = (8k)          /* USB RAM: 8k */
  //ERAM (rw): ORIGIN = 0x7FE00000, LENGTH = (16k)      /* Ethernet RAM: 16k */
  //BRAM (rw): ORIGIN = 0xE0084000, LENGTH = (2k)      /* Battery RAM: 2k */
}

Die Kommentare aus einem anderen Linkerscript erklären auch die Zahlen, 
die abgezogen werden. Ob das hier wirklich benötigt wird, ist aber wohl 
eine andere Frage...
Und weiter unten innerhalb von SECTIONS { } kommt dann noch:

/* .usbram .etherram and .batteryram added 22.03.2013 */
  /* memory space of etherram and batteryram is directly used via pointer in program without section */
  .usbram (NOLOAD) :
  {
      __usbram_start = . ;
      __usbram_start__ = . ;
      *(.usbram)
      . = ALIGN(4);
  } > URAM
  /*
  .etherram (NOLOAD) :
  {
      __etherram_start = . ;
      __etherram_start__ = . ;
      *(.etherram)
      . = ALIGN(4);
  } > ERAM
  
  .batteryram (NOLOAD) :
  {
      __batteryram_start = . ;
      __batteryram_start__ = . ;
      *(.batteryram)
      . = ALIGN(4);
  } > BRAM
  */

Die Sections für Ethernet RAM und Battery RAM habe ich auskommentiert, 
da die Adressbereiche über Pointer angesprochen werden und ich da nichts 
riskieren wollte.

Bleiben noch die Fragen, ob der feste Stack wirklich so groß sein muss 
und ob ein aktiviertes Ethernet oder USB noch irgendwas im 
entsprechenden eigenen Rambereich macht?

[ARMdran (Gast)]

Damit habe ich jetzt durch die Analyse über 5kB SRAM frei gemacht und 
weiß, dass der Stack massig Platz hat.

Zum Vergleich:

vorher:

.data               5720   1073741824
.bss               13660   1073747544
.stack             13312   1073761208

= 32692

nachher:

.data               1624   1073741824
.bss               11836   1073743448
.stack             13312   1073755288
.usbram             1824   2144337920

.data + .bb + .stack = 26772

32692 - 26772 = 5920 Byte frei geschaufelt

Dazu sind mir noch einige sehr große Buffer aufgefallen, die ich mir 
noch mal genauer anschauen muss.

Hoffentlich funktioniert das mit dem USB RAM ohne Probleme.
Diese Pointer Zugriffe auf das Ethernet und RTC RAM sind mir auch etwas 
suspekt.

[ARMdran (Gast)]

ARMdran schrieb:
> .stack             13312   1073761208

Kann mir jemand sagen, ob so eine .stack Section überhaupt standarmäßig 
genutzt wird, oder ob da einfach RAM für den Stack freigehalten wird?