Forum: Mikrocontroller und Digitale Elektronik LPC2103 Speicherproblem


von Christian (Gast)


Angehängte Dateien:

Lesenswert?

Guten Tag,

ich bin gerade dabei mit einem LPC2103 ein OLED Display anzusteuern.
Klappt auch wunderbar. Also es wird ein Bitmap usw gezeichnet.

Nun möchte ich mir ein Menü bauen wie bei einem Handy. Dafür benötige
ich mehre Bitmaps und somit auch Speicher.
Ich hab 32kb Flash Speicher.
Meine Bitmaps habe ich so umkonvertiert das ich nur noch den Hex Code
für die Farbinformationen habe. Für jedes Bitmap hab ich ein Array
angelegt indem die Farbinformationen (Hex-Code)liegt.

Wenn ich nun mein Code auf den Controller lade wird mir im Log
angezeigt:
Tue Jul 25 10:38:21 2006: 3638 bytes downloaded and verified (1.47
Kbytes/sec)
.
.
.
.
Tue Jul 25 10:38:28 2006: 10832 bytes downloaded into FLASH and
verified (1.66 Kbytes/sec)

also recht wenig. Müsste ja noch reichlich Speicher übrig sein.
(Es werden 3 Bitmaps geladen. Sollten aber 6 Bitmaps in den Speicher
passen)
Wenn ich nun ein 4.Bitmap verwenden will kommt folgender Fehler:

Error[e16]: Segment IRQ_STACK (size: 0x100 align: 0x2) is too long for
segment definition. At least 0xe0 more bytes
needed. The problem occurred while processing the segment placement
command
"-Z(DATA)IRQ_STACK+_IRQ_STACK_SIZE,HEAP+_HEAP_SIZE=RAMSTART-RAMEND",
where at the moment of
placement the available memory ranges were "CODE:40001fe0-40001fff"
   Reserved ranges relevant to this placement:
   40000000-40001adb    DATA_I
   40001adc-40001adc    DATA_Z
   40001add-40001fdf    CSTACK
   40001fe0-40001fff    IRQ_STACK

Wieso bekommt er nun ein Problem mit m Speicher? Ist doch noch genug
Platz da oder? Im Map File steht eigentlich auch das keine 32kb
Speicher benötigt werden.
Anbei mal noch map,lst und xcl File.

Achja die Bitmaps sind im Schnitt um die 30x30 pixel gross.

Danke für eure Hilfe schonmal.

Christian

von Dietmar (Gast)


Lesenswert?

>Error[e16]: Segment IRQ_STACK (size: 0x100 align: 0x2) is too long >for
segment definition. At least 0xe0 more bytes needed.

>40001fe0-40001fff    IRQ_STACK

Für IRQ_STACK ist eine Größe von genau 0x100 Bytes definiert. Das sind
die letzten 0x20 Bytes an der obersten Speichergrenze, von 0x40001fe0
.. 0x40001fff, und 0xe0 Bytes fehlen per Fehlermeldung, da bei
0x40001fff der Speicher eben zu Ende ist. Und der RAM-Speicher scheint
voll belegt zu sein.

Das sieht mir danach aus, als ob bei deiner Aktion auch RAM gebraucht
wird, nicht nur Flash Speicher. Der IRQ-Stack wird da nach oben
verschoben zu Adressen, die nicht mehr vorhanden sind. Verkleinere doch
Heap, User Stack (CSTACK) und den IRQ Stack (IRQ_STACK) mal ein wenig,
vielleicht hilft das schon.


Hier ist aber noch was faul: Das sieht danach aus, als ob ein sehr
großer Flash-Bereich zur Ausführung ins RAM kopiert wurde, da ähnliche
Namen und exakt gleich groß, o.ä., vermutlich ein
Konfigurationsproblem:

SEGMENT    STARTADR   ENDADR     SIZE  TYPE  ALIGN
=======    ========   ======     ====  ====  =====
>DATA_ID   00001294 - 00002D6F   1ADC   rel    2
>DATA_I    40000000 - 40001ADB   1ADC   rel    2


Gruß

Dietmar

von Robert Teufel (Gast)


Lesenswert?

Ganz naive Frage. Kann es sein, dass Du den Keil C-Compiler benuetzt,
der auf 16k limitiert ist?
Ich wuerde eine andere Fehlermeldung erwarten aber einfach mal so ein
Gedanke.

Robert

von Christian (Gast)


Lesenswert?

Öhm ich benutz das IAR Embedded Workbench. Also denk der Compiler is von
IAR? Kein Keil oda Gcc.
Das ganze ging gleich mit der Entwicklungsumgebung und da hatte ich
keine Lust mich noch mit WinArm durchzuwursteln ;)

Naja ich hab nun n anderes Problem. Mein Display geht erst gar nicht
an. Glaub das is nun kaputt :(
Mein schönes 128x128 Display...
meld mich wieder falls ich wieder zum Laufen bekomm.
Danke aber für eure Hilfe.

von Christian (Gast)


Lesenswert?

hi,

so Display geht wieder.
Nurn zurück zu dem Speicherproblem.
Also erstmal ich versteh das ganze nicht ;)

Wenn ich mir 2 verschiedene map files anschaue wo ich einmal meine
Arrays für die Bitmaps definiert habe und einmal keine Arrays hab so
ergibt sich folgendes:

Keine Arrays mit Farbinformationen für die Bitmaps:

 4 840 bytes in segment CODE
   220 bytes in segment DATA_AN
     4 bytes in segment DATA_I
     4 bytes in segment DATA_ID
     6 bytes in segment DATA_Z
    24 bytes in segment INITTAB
     8 bytes in segment INTVEC

 4 696 bytes of CODE  memory (+ 176 bytes shared)
     4 bytes of CONST memory
    10 bytes of DATA  memory (+ 220 bytes shared)

Mit Arrays

 4 936 bytes in segment CODE
   220 bytes in segment DATA_AN
 9 504 bytes in segment DATA_I
 9 504 bytes in segment DATA_ID
     5 bytes in segment DATA_Z
    24 bytes in segment INITTAB
     8 bytes in segment INTVEC

 4 792 bytes of CODE  memory (+ 176 bytes shared)
 9 504 bytes of CONST memory
 9 509 bytes of DATA  memory (+ 220 bytes shared)

also ca. 9.5kb an Daten für die Bitmaps

1. Frage:
Wieviel Bytes werden nun auf mein Controller geflashed?
Das steht im Log beim flashen:
Mon Jul 31 10:32:55 2006: 12042 bytes downloaded (26.85 Kbytes/sec)
Scheint mir aber zu wenig zu sein?
Kommt das alles ins Flash? Oder auch was ins RAM?

Dann das was Dietmar ansgesprochen hat:
"Hier ist aber noch was faul: Das sieht danach aus, als ob ein sehr
großer Flash-Bereich zur Ausführung ins RAM kopiert wurde, da ähnliche
Namen und exakt gleich groß, o.ä., vermutlich ein
Konfigurationsproblem:"

Dazu hab ich das gefunden im xcl file (siehe Anhang)
//   DATA_y     -- Data objects.
// Where _y can be one of:
//   _I         -- Initialized data (RAM).
//   _ID        -- The original content of _I (copied to _I by
cstartup) (ROM).
WIESO ROM??? Read only memory? Wieso schreibt er da was rein?
Ich geh mal nun davon aus das RAM=Flash ist und ROM=RAM?

Dann schreibt er mir beim Ausführen immer das Komplette Data vom Flash
ins RAM? Das wäre ne Erklärung, dass der Speicher nicht ausreicht.(8kb
Ram und 32kb Flash)
Der Flash speicher sollte ja noch ausreichen wenn mann alles
zusammenzählt was er ins map file schreibt.

Was ich auch nicht versteh ist:
 9 504 bytes of CONST memory
 9 509 bytes of DATA  memory (+ 220 bytes shared)
Warum wird CONST memory UND DATA memory grösser? Der verdoppelt somit
ja mein Speicher.

Fragen über Fragen...wäre toll wenn da mal jemand Licht ins Dunkle
bringen kann.

Gruss
Christian

von Christian (Gast)


Angehängte Dateien:

Lesenswert?

Ach und hier noch das List File. Sorry soll oben nicht map sondern lst
file heisen.

von Christian (Gast)


Lesenswert?

Mit Const geht das ganz einfach...eieie

von Dietmar (Gast)


Lesenswert?

@Christian:

Und, alles klar jetzt? Hattest du was mit CONST und DATA durcheinander
gebracht?

Ansonsten, war mir letztens selbst folgendes passiert:

Bin von Keil CARM auf RealView umgestiegen, da Keil den CARM nicht mehr
weiter entwickelt und statt dessen RealView von ARM anbietet. Also
bestand die Notwendigkeit, ein Scatter Loading File (Linker Script) zu
erstellen, suchte überall nach Infos und experimentierte. Und eh ich
mich versah, wurde, ausgelöst durch das Scatter Loading File, abhängig
vom Adressenbereich eines Code-Modules, plötzlich ein Loader
installiert, der Code aus dem Flash ins RAM schaufelt und dort ausführt
(und damit natürlich eine Extraportion Speicher beansprucht). Gesehen
hat man das nur im map-File.

Die folgenden beiden Zeilen deines xcl-files bringen es doch exakt auf
den Punkt:

_I  -- Initialized data (RAM).
_ID -- The original content of _I (copied to _I by cstartup) (ROM).

>WIESO ROM??? Read only memory? Wieso schreibt er da was rein?
>Ich geh mal nun davon aus das RAM=Flash ist und ROM=RAM?

Da wird erst zur Laufzeit was aus dem ROM genommen und ins RAM
geschrieben. Und das RAM dafür wird zur Compilierzeit vorab schon mal
reserviert.

ROM = FLASH = Nicht flüchtiger Speicher für Code (CODE) und Konstanten
(CONST).
RAM = Flüchtiger Speicher für Variablen und während der Laufzeit
entstehende Daten (DATA), und, in neuester Zeit, anscheinend auch für
Code und Konstanten zur Laufzeit.

So ein Kopiervorgang vom ROM ins RAM bietet sich bei den
LPC-Controllern deshalb an, weil Von-Neumann-Architektur, d.h. ROM und
RAM im linearen Adressbereich des Speichers (im Gegensatz zum 8051).
Laut User Manual ist die Ausführung aus dem RAM hauptsächlich für
Debug-Zwecke einzelner kleiner Codeblöcke gedacht. Denn so groß ist das
RAM ja nicht. Der ARM-Compiler stammt anscheinend aus einer anderen
Welt, wo es um größere Kaliber geht (Betriebssysteme, viel
RAM-Speicher). Da ist Laden vom ROM ins RAM Standard.

>Dann schreibt er mir beim Ausführen immer das Komplette
>Data vom Flash ins RAM? Das wäre ne Erklärung, dass der
>Speicher nicht ausreicht.(8kb Ram und 32kb Flash)

Genau so isses. Ist aber jetzt geklärt, oder?

Gruß

Dietmar

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.