Hey all, I am using uVision 3 and a Phytec 2294 board. I have an external memory device connected to the phytec expansion board. The external device is using /CS0, although from talking to phytec, I am not sure if that is quite right. I have set up the external memory space in the project options like so: Start: 0x80000000 Size: 0x4 When I define a variable like :
#define volatile var x __at 0x8000000
"In the Keil targget options, there is a spot to specify external memory, do I need to specify my ranges in there as well." That, I think, is what you did to shut up the "*** error 65: access violation" messages. Don't think of it as adding a specification for external memory, but rather for an external memory-mapped device or peripheral. Look at lpc22xx.h and you'll see that there are memory-mapped peripherals in the 0xFF------ and 0xE0------ ranges. Presumably, the IDE already has those ranges covered, but you need to tell it not to fuss about accesses to your new memory-mapped I/O area. That is an artifact of using this type of toolchain. If you were doing it all with simple command-line compile/link/load tools, you wouldn't have to mess with it. "I am unclear on how my code knows when I say go to 0x83000000, that it actually knows how to get to that address and read from it or write to it." The way we're writing it here using the MY_REG1 macro (name it what you want), the compiler can't help but generate code to do it. It's going to generate code to load a register with 0x83000000 and to then do indirect loads and stores "through" that register. Check the disassembly and you'll see.
That is an artifact of using this type of toolchain. If you were doing it all with simple command-line compile/link/load tools, you wouldn't have to mess with it. Now there you're IMHO being a bit overly negative. Fact is, with such simpler tools, you just wouldn't have a simulator to be told about the existence (or not) of memory at given addresses on the simulated hardware. Calling the need to configure each part of the toolchain, which implies that having more elements in it will mean more configuration items to fill in, an artifact doesn't do it justice.
None of my comments were intended to be negative per se. There is a very clear distinction between configuration that has to be done to keep a toolchain happy and configuration that has to be done to make the hardware work. Nothing discussed so far has cleared up whether some toolchain settings actually have an effect on the hardware. I am wasting my time trying to help with what appears to be a very simple software/hardware integration issue when there are nuances to a toolchain that I can't see which are fogging up my glasses. When I am debugging software/hardware integration issues (e.g., a chip select), I remove as many sources of extraneous unknown variables as I can. But that's just me.
Dan, Actually, through some research, putting a value in that dialog does more harm than good. If I specify a range in there, I get :
*** ERROR L107: ADDRESS SPACE OVERFLOW SPACE: DATA SEGMENT: STACK LENGTH: 00000490H *** WARNING L23: UNRESOLVED EXTERNAL SYMBOLS *** ERROR L128: REFERENCE MADE TO UNRESOLVED EXTERNAL SYMBOL: ?C?INIT ADDRESS: 0000010CH Program Size: data=1172 const=0 code=304 Target not created
Are you only running this in the simulator and not the real target hardware?
Dan, I have taken a more simplistic approach for the time being. I have created a new projeect, with my definition of:
#define MY_REG1 (*(volatile unsigned char *)0x83000000)
0x00000608 B500 PUSH {LR} 30: MY_REG1 = 1; 31:
To answer original question, this is just in simulator
Nothing after that? Can you show more disassembly context?
0x00000606 E7F1 B 0x000005EC 27: int main (void) { 28: unsigned int j; /* LED var */ 29: 0x00000608 B500 PUSH {LR} 30: MY_REG1 = 1; 31: 0x0000060A 2101 MOV R1,#0x01 0x0000060C 4813 LDR R0,[PC,#0x004C] 0x0000060E 7001 STRB R1,[R0,#0x00] 32: IODIR1 = 0xFF0000; /* P1.16..23 defined as Outputs */ 33: 0x00000610 4913 LDR R1,[PC,#0x004C] 0x00000612 4814 LDR R0,[PC,#0x0050] 0x00000614 6001 STR R1,[R0,#0x00] 34: init_timer();
Much better. Thank you.
0x00000606 E7F1 B 0x000005EC 27: int main (void) { 28: unsigned int j; /* LED var */ 29: 0x00000608 B500 PUSH {LR} ;Just saving some processor context there.
30: MY_REG1 = 1; 31: 0x0000060A 2101 MOV R1,#0x01 ;Loading R1 with the value to be written. 0x0000060C 4813 LDR R0,[PC,#0x004C] ;Loading R0 with the address to write to. 0x0000060E 7001 STRB R1,[R0,#0x00] ;Performing the byte write.
Dan, Another thing I just noticed is that if I stored this in the target options start of 0x83000000, and size of 0x4, the compiler gives me this:
*** ERROR L107: ADDRESS SPACE OVERFLOW SPACE: DATA SEGMENT: STACK LENGTH: 00000490H *** WARNING L23: UNRESOLVED EXTERNAL SYMBOLS *** ERROR L128: REFERENCE MADE TO UNRESOLVED EXTERNAL SYMBOL: ?C?INIT ADDRESS: 00000104H Program Size: data=1172 const=0 code=296 Target not created
"Any idea why it doesnt like the smaller size?" The only thing I can think of is that the mapper is designed to deal with larger chunks, for example >=256-bytes. My Linux kernel rounds everything up to 4KiB pages ;-)
Dan, Thanks again for your help today. I think this is enought to go on for now. If I need to specify a bigger chunk, its not too much of a big deal :) Im going to use it or im not, end of that. Again, thanks for the assistance. This beginning embedded guy really appreciates it :)
You bet. Have fun!