RAM zu klein?

[John (Gast)]

Ich versuch in Microvision das Programm in den "executable RAM" zu 
flashen. Hab auf jeden Fall genügend Speicher, doch bekomme beim 
Kompilieren die Meldung:
"Numeric Value is out of Range". Woran hakts?

[Jim M. (turboj)]

> Woran hakts?

Es fehlen alle sinnvollen Informationen. Meine Glaskugel ist in 
Reparatur.

[John (Gast)]

Der externe RAM hat den Speicherbereich:
0x81000000 - 0x81200000

Unter "LA Locate" hab ich angegeben:
User classes: ERAM(0x81000000-0x81200000)

Mein Programm ist folgender:
#include <LPC22XX.H>


int main(void) __ram {
   int var = 1;

   var++;


   return 0;
}

--> Das ist ein winziges Programm. Das sollte doch in den externen RAM 
locker reinpassen?

[Purzel (Gast)]

Und der controller ist ein Mega8 ?

[John (Gast)]

Es ist ein LPC2294 (ARM7). Ich verwende aber einen Phytec LPC2294 
Evaluationsboard.

[John (Gast)]

Hat denn von den hunderten von Leuten in diesem Forum überhaupt keine ne 
Ahnung??

[Oliver J. (skriptkiddy)]

John schrieb:
> "Numeric Value is out of Range". Woran hakts?

Bitte den ganzen Build-Output posten.

Gruß Oliver

[John (Gast)]

Build target 'Projekt2_XFLASH'
assembling Startup_phyCORE-LPC2294.s...
compiling test.c...
linking...
*** ERROR L138: CODE GENERATION: PROBLEM WHEN PROCESSING INSTRUCTIONS
     CAUSE:  Numeric value is out of range
    SEGMENT: ?PR?main?Blinky
     ADDRESS: 081000004H
*** ERROR L138: CODE GENERATION: PROBLEM WHEN PROCESSING INSTRUCTIONS
     CAUSE:  Numeric value is out of range
    SEGMENT: ?PR?main?Blinky
     ADDRESS: 08100001AH
Program Size: data=1336 const=208 code=468
Target not created

[John (Gast)]

Oh man.. Das tut echt der Seele weh. Ich hab das Problem gelöst: Die 
Funktion war im "THUMB"-Modus. Nachdem ich Sie in "ARM"-Modus umgedänert 
habe gings. Womit hat das zu tun? Wieso kann man einer Funktion nicht 
"__ram" anhängen, wenn diese nicht im ARM-Modus ist?

lg

[John (Gast)]

Aber jetzt, wo das Programm dann in den RAM geladen wird, wird es auf 
dem Board nicht ausgeführt.

[John (Gast)]

Wieso funktioniert mein Code nicht, wenn ich hinter dem Funktionsnamen 
noch "__ram" mit angebe? Es wird richtig kompiliert und in den 
Mikrokontroller geflasht. Ohne "__ram" funktioniert es , mit "__ram" 
aber nicht. Wieso?

[Stefan F. (sfrings)]

Ich schätze mal, dass das Hauptprogramm zwagsläufig im Flash Speicher 
stehen muss, weil der Programmzähler nach einem Reset auf einer Adresse 
steht, die den Flash Speicher anspricht.

Warscheinlich kannst Du andere funktionen in den RAM verschieben, aber 
nicht das Hauptprogramm.

Mich würde mal interessieren, wie die ensprechen gekennzeichneten 
Programmteile überhaupt in das RAM übertragen werden, um später 
ausgeführt zu werden. Initial muss der Code ja wohl im Flash liegen, 
dann ins RAM kopiert werden und dann erst ausgeführt werden. Den dazu 
nötigen Code erzeugt der Compiler sich nicht "von selbst", oder doch?

[John (Gast)]

Ja du hast Recht. Das Problem tritt nur dann auf, wenn ich bei der 
Hautpfunktion main auch "__ram" mit angebe. Woran liegt denn das?

lg

[Peter D. (peda)]

John schrieb:
> Woran liegt denn das?

Sollte irgendwo in der Compiler-Doku stehen.

Manchmal sind Compilerbauer aber auch praktisch denkende Menschen. Sie 
implementieren nur das, was auch einen Sinn hat.
Und welchen praktischen Vorteil siehst darin, das Main in den RAM zu 
packen?

RAM ist in der Regel nicht üppig. Daher packt man nur schnelle 
Funktionen und Interrupts hinein.


Peter

[Bronco (Gast)]

John schrieb:
> Ja du hast Recht. Das Problem tritt nur dann auf, wenn ich bei der
> Hautpfunktion main auch "__ram" mit angebe. Woran liegt denn das?

Ich mutmaße mal folgendes:
1. Die Funktion main() ist ja nicht der allererste Code, der nach einem 
Reset ausgeführt wird. Davor läuft ja noch der (aus C-Sicht unsichtbare) 
Startup-Code (Variableninitalisierung usw). Erst am Ende davon springt 
dann die CPU zu main().
2. Der µC hat einen Resetvektor, indem die Adresse des Startup-Codes 
steht. Nach einem Reset (und PowerOn ist ja auch ein Reset) springt der 
µC in den Startup-Code und der Startup-Code springt dann an die Adresse, 
wo er main() vermutet.
3. Du mußt also Deine RAM-Adresse irgendwie in den Startup-Code 
bekommen, oder Du läßt main() im Flash und springt erst aus main() in 
Deinen RAM-Code.

[(prx) A. K. (prx)]

Was ist denn der Sinn des Ganzen? Entwicklung im RAM oder schnelle 
Funktionen? Für schnelle Funktionen gehören nur diese in RAM - wenn 
überhaupt, bei den LPC2000 bringt das nicht so arg viel.

Es ergibt aber keinen Sinn, das ganze Programm Funktion für Funktion mit 
__ram zu versehen um die Entwicklung im RAM statt im Flash 
durchzuführen. Los wirst du das Flash dann nämlich trotzdem nicht, weil 
der Kram trotzdem als Initialisierungsdaten dort landet und beim Start 
ins RAM kopiert wird. Es lässt sich normalerweise im Entwicklungssystem 
einstellen, dass der komplette Kram im RAM landet und das Flash 
überhaupt nicht verwendet wird, Reset/Interrupt-Tabelle inklusive.

[Peter D. (peda)]

Vermutlich ist der Startup-Code in Assembler geschrieben und verwendet 
einen kurzen Sprung zum Main, der den RAM nicht erreichen kann.
Oder er verwendet garkeinen Sprung und muß daher direkt vor dem Main 
stehen, d.h. läuft einfach in das Main hinein.

Sobald Du aber im C-Programm bist, kümmert sich der Compiler darum, den 
passenden Sprungbefehl zu verwenden. Da ist also jede Adresse in 
Reichweite.


Peter