We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I use two different µC (C505 and C164). I use the following compilers: C51: V7.06i / BL51: 5.03 C166: V4.11 / L166: 4.10 (Updates not possible. I couldn't use newer one.)
How can I get information about used RAM (IRAM, XRAM, ...)? = How much RAM do my program needed?
I know that I can use the map files. But that's complicated and not easy and not fast.
Do anybody know an other method? How could I evaluate the map file (to know how many RAM my source code needed)?
Thanks for help
No help possible?
Look at the map file. You'll see something like:
Program Size: data=229.5 xdata=4363 code=30288
There is shown the amount of space required for data and code.
Easy.
Yes that's true. But I can't believe that.
Example Program Size: data=220.3 xdata=2615 code=32750 RAM = 220 XRAM=2615 ROM=32750 I used a C505 CI µController with 256byte RAM / 1k XRAM / 32k ROM.
I can't believe, that the xdata=2615byztes (> 2kByte). And what is meaning with 220.3 - the .3 ?
I can't believe, that the xdata=2615byztes (> 2kByte).
If you've got the options enabled for full map files, you can see what exactly is using the xdata. Just check it and add it up.
And what is meaning with 220.3 - the .3 ?
That's for the bit-addressable data. So the .3 represents 3 bits of a byte being used.
Map File:
BL51 BANKED LINKER/LOCATER V5.03 04/20/2012 09:50:43 PAGE 1
BL51 BANKED LINKER/LOCATER V5.03, INVOKED BY: C:\KEIL\C51\BIN\BL51.EXE .\a\obj\main.obj, .\a\obj\startup.obj, .\a\obj\ee.obj, .\a\obj\esi.obj, .\a\obj\can.obj, .\a\ob >> j\rk.obj, .\a\obj\ri.obj, .\a\obj\tst.obj, .\a\obj\ctl.obj, .\a\obj\in.obj, .\a\obj\out.obj, .\a\obj\cfg.obj, .\a\obj >> \nv.obj, .\a\obj\crc.obj, .\a\obj\cc.obj, .\a\obj\tm.obj, .\a\obj\tst.obj TO .\a\obj\ue403 PRINT (.\a\lst\ue403.m51) >> RAMSIZE (256) DISABLEWARNING (7) CODE (0X0000-0X7FFF, ?PR?TST_OPC*, ?PR?TST_REG*) XDATA (0XFD00-0XFFFF, ?XD?NV (0X110 >> 0)) PDATA (0XFC00)
MEMORY MODEL: SMALL
... ...
Program Size: data=220.3 xdata=2615 code=32750 LINK/LOCATE RUN COMPLETE. 0 WARNING(S), 0 ERROR(S)
I hope this is enough. The entire map file is very long.
I hope this is enough.
You need to go further than that.
Something like:
XDATA 274DH 0080H INPAGE ?XD?I2CRX
XDATA (0XFD00-0XFFFF, ?XD?NV (0X1100))
I think you will have to break open the linker manual and find out what that directive actually does, and check whether that really matches your belief that you only have 1K of XRAM space available. Unless I misread the documentation, you've just told the linker to put 768 bytes of XDATA into range 0xFD00...0xFFFF, and some other stuff at 0x1100. For the second part you didn't specify any size.
Oh, and this:
PDATA (0XFC00)
actually occupies your remaining 256 bytes of XRAM. So you have specified a total of 1 KiB XRAM, plus some more. The linker only did what you told it to.
In the last comments i wrote:
I used a C505 CI µController with 256byte RAM / 1k XRAM / 32k ROM.
Yes I use 256byte RAM and 1kXRAM (Xdata, Idata, Pdata).
But I can't believe the following listing at the end of the compilation:
Program Size: data=220.3 xdata=2615 code=32750
xdata = 2615 is more than 2k XRAM
This is the point I can not believe.
Where can I find additional information about the user RAM ressource (how many RAM my program needed)?
typing error correction: Where can I find additional information about the used RAM ressources (how many RAM my program needed)?
I'll say it slowly one last time.
Look ... at ... the ... map ... file.
My discussion is about the 'xdata' value in the last line of the map file / compiler output.
Map file - XDATA definitions:
* * * * * * * X D A T A M E M O R Y * * * * * * * 0000H 1100H *** GAP *** XDATA 1100H 0016H UNIT ?XD?NV 1116H 000AH *** GAP *** XDATA 1120H 0014H ABSOLUTE 1134H 000CH *** GAP *** XDATA 1140H 0014H ABSOLUTE 1154H 000CH *** GAP *** XDATA 1160H 0006H ABSOLUTE 1166H 001AH *** GAP *** XDATA 1180H 0006H ABSOLUTE 1186H 001AH *** GAP *** XDATA 11A0H 0230H ABSOLUTE 13D0H 0010H *** GAP *** XDATA 13E0H 0118H ABSOLUTE 14F8H 0008H *** GAP *** XDATA 1500H 0078H ABSOLUTE 1578H 0008H *** GAP *** XDATA 1580H 008CH ABSOLUTE 160CH 0014H *** GAP *** XDATA 1620H 0008H ABSOLUTE 1628H 0018H *** GAP *** XDATA 1640H 00B4H ABSOLUTE 16F4H 000CH *** GAP *** XDATA 1700H 0064H ABSOLUTE 1764H 001CH *** GAP *** XDATA 1780H 0154H ABSOLUTE 18D4H 000CH *** GAP *** XDATA 18E0H 000CH ABSOLUTE 18ECH 0014H *** GAP *** XDATA 1900H 000CH ABSOLUTE 190CH DE04H *** GAP *** XDATA F710H 00F0H ABSOLUTE F800H 0400H *** GAP *** XDATA FC00H 0001H INPAGE ?PD?CAN XDATA FC01H 008CH INPAGE ?PD?RK XDATA FC8DH 000BH INPAGE ?PD?CTL XDATA FC98H 000CH INPAGE ?PD?IN XDATA FCA4H 000DH INPAGE ?PD?OUT XDATA FCB1H 001DH INPAGE _PDATA_GROUP_ FCCEH 0032H *** GAP *** XDATA FD00H 0142H UNIT ?XD?RI XDATA FE42H 0009H UNIT ?XD?CAN XDATA FE4BH 0004H UNIT ?XD?CFG XDATA FE4FH 0003H UNIT ?XD?RK XDATA FE52H 0002H UNIT ?XD?EE XDATA FE54H 0002H UNIT ?XD?IN XDATA FE56H 0001H UNIT ?XD?OUT N:0300H SYMBOL XDATALEN C:6916H SYMBOL XDATALOOP N:FD00H SYMBOL XDATASTART N:0091H SYMBOL XPAGE
And I am sure that the compiler supports 256Byte RAM / 1kByte XRAM / 32k ROM (C505CA-4EM)
So I
Look(ed) ... at ... the ... map ... file.
very slowly, but I can't find the information I searched.
Sorry, if I'm too slow.
That's better. The question now is what are all of the ABSOLUTEs about? Looks like you're positioning variables at fixed locations. Any particular reason for it?
It's making a lot of gaps, so the overall area of your XDATA is large:
190Ch-1100h = 080Ch bytes = 2060d bytes
How could this work? The controller only have 1kByte XRAM.
In my opinion the listed value for xdata (e.g. 2615) is NOT the realy program needed XRAM value.
But I searched the entire realy needed RAM/XRAM value for my compiled program.
This can work since the controller has an external memory bus. From looking at the User Manual of your device you will see that this is located from 0x0000 to 0xF6FF in the XDATA space.
Might be helpful for you: http://www.keil.com/dd/docs/datashts/infineon/c505c_um.pdf
All the XDATA segments that have been located absolute in that address space indicate that there is some memory mapped peripheral on the external bus, right? In that case the linker does not distinguish between veriables in real memory or on a peripheral and counts them into the used memory sum (actually it can't see the difference).
To get the real numbers and also check if all variables have been located into valid areas you will find a guide line to read the MAP here: http://www.keil.com/support/docs/2204.htm
You might also want to check the addresses against the memory map you see in the user manual.
You (or rather: your code) told the compiler and linker that you have more than the usual 1 K of memory available in XRAM address space. You even told the linker exactly where that is. And now you don't "believe" the linker when it reports that very same information back to you.
Hmm... that looks like your right hand doesn't know what the left hand is doing. There's not terribly much anyone but you can do about that.