I am using 8051F120 having 127KB Program memory, theoretically. I have written 4 *.C files residing in each bank. The length of the code in Bank1 and Bank2 is less than 32KB (observing the list file). But, instead of this, the linker gives an address space overflow for both the banks. Kindly assist.
Dhaval Solanki
You talk about information 'as stated in the datasheets'. I don't follow that part. The linker does not know (or read) the datasheets so it has to rely on what is provided to it.
Though quite interesting, the result of the linkage is probably not the best information to provide.
What I think would be more useful is the detail relating to the information provided to the linker.
Depending upon your listing settings, this information can be given at the start of the map file.
What you need to look at are the specifications relating to the common and the banked areas.
To Reluctant Consultant. 1. What I think would be more useful is the detail relating to the information provided to the linker. Are you referring to the following information:
Tool Chain Integration (window in SiLabs) Tool Vendor: Keil Assembler Tab: Command Line Flags: XR GEN DB EP NOMOD51. Compiler Tab: Command Line Flags: DB OE BR OR OT(8,Size) Large. Linker Tab: Command Line Flags: RS(256) PL(68) PW(78) BANKAREA(8000H,0FFFFH).
2. What you need to look at are the specifications relating to the common and the banked areas. Kindly elaborate, what I need to look at. I mean to say, I didn't exactly understand this line.
The datasheet specifications:
Common Bank Area: 0000H to 8000H Bank1 Area: 8000H to FFFFH Bank2 Area: 8000H to FFFFH Bank3 Area: 8000H to F7FFH
1KB of Address reserved in Bank3 (F800H to FFFFH).
The tool chain information is better, but I think that the information in the map file would be the most certain way of looking at the settings.
For example, in an old project of mine, the map file produced by the linker has a block of text that starts:
BL51 BANKED LINKER/LOCATER V5.03, INVOKED BY: C:\KEIL\C51\BIN\BL51.EXE BANK1 {.....etc.......}
The link settings used at time of the linker invokation should show what details are being specified for the common and banking details.
We can see from your details:
BANKAREA(8000H,0FFFFH)
So, the simplistic view would be that your banked code should start at 0x8000, but you need to check other parameters that might cause it to be starting further up.
Keil Compiler Options: Under Listing: Marked Check boxes: 1. Generate .lst file 2. Include Conditional code Warnings: Level 2 Optimization Level: Level 10 [Rearrange Code (Linker Optimization)] Emphasis Favor Small Code Memory Model: Variable Location: Large: XDATA Code Size Limits: 64K Functions Keil Linker Options: Under Linking: Marked Check boxes: 1. Enable Variable Overlaying RAM Size: 256 Selected Processor: C8051F120
Set the option to produce a linker map file, enable everything, do a rebuild (if necessary) and look for the information at the start that begins with something like:
The following extract from M51:
BL51 BANKED LINKER/LOCATER V6.05, INVOKED BY: C:\KEIL\C51\BIN\BL51.EXE D:\dhaval's disso\DissoVer4.41C_i2c\common.obj, D:\dhaval's disso\DissoVer4.41C_i2c\L51_BANK.obj, BANK1 {D:\dhaval's disso\DissoVer4.41C_i2c\main.obj}, BANK3 {D:\dhaval's disso\DissoVer4.41C_i2c\screens.obj}, D:\dhaval's disso\DissoVer4.41C_i2c\STARTUP.obj, BANK2 {D:\dhaval's disso\DissoVer4.41C_i2c\menu.obj} TO D:\dhaval's disso\DissoVer4.41C_i2c\TDT08L RS (256) PL (68) PW (78) BANKAREA (8000H, 0FFFFH)
What type of Parameters are you referring to? Can you give an example?
No. That's why you need to look at the settings carefully. There's obviously something missing or incorrect, otherwise it would be producing the output you expect.
I think you need to examine details relating to the 'common area'. I suspect the common code might be being placed at the start of each bank.
You mention that the datasheet specifies:
But, there is no specification of the common area in the linker invocation.
For example, my old project (which seems to have similarities to your memory layout) has a linker invocation containing:
BANKAREA (0X8000, 0XFFEF) RAMSIZE (256) DISABLEWARNING (16) CODE (0X0000-0X7FFF) XDATA (0X0000-0XFFFF)
Note the 'code' which I did not see in your linker invocation.
Just a hint - C51 linker does not show composite CODE+CONSTANT size. So, your BANK1 module takes 32745 bytes of CODE + 1850 bytes of CONSTANT space which together gives more than 32768 bytes. Try to solve BANK1 and BANK2 sizes first...
- Dejan
My observations, conclusions and Solution to Address Space Overflow
* * * * * * * C O D E M E M O R Y * * * * * * * CODE 0000H 0003H ABSOLUTE CODE 0003H 0007H UNIT 000AH 0001H *** GAP *** . . . . . . . . . . . . . . . . CODE 97F5H 001FH UNIT CODE 9814H 001EH UNIT CODE 9832H 0012H UNIT CODE 9844H 0010H UNIT CODE 9854H 000BH UNIT CODE 985FH 000AH UNIT CODE 9869H 000AH UNIT CODE 9873H 0007H UNIT CODE 987AH 0007H UNIT end address = starting address of function + length Refer NOTE end address = 987A + 7 = 9981 * * * * * * * C O D E B A N K 1 * * * * * * * 0000H 9881H *** GAP *** Refer NOTE BANK1 9881H 1D5BH UNIT BANK1 B5DCH 1756H UNIT BANK1 CD32H 0D51H UNIT BANK1 DA83H 0623H UNIT BANK1 E0A6H 05DDH UNIT BANK1 E683H 0541H UNIT BANK1 EBC4H 044EH UNIT BANK1 F012H 03D7H UNIT BANK1 F3E9H 03BCH UNIT BANK1 F7A5H 033AH UNIT BANK1 FADFH 0322H UNIT BANK1 FE01H 01B4H UNIT BANK1 FFB5H 004BH UNIT * * * * * * * C O D E B A N K 2 * * * * * * * 0000H 9881H *** GAP *** Refer NOTE BANK2 9881H 03CCH UNIT BANK2 9C4DH 02A7H UNIT BANK2 9EF4H 02A7H UNIT BANK2 A19BH 0205H UNIT BANK2 A3A0H 0175H UNIT BANK2 A515H 00F6H UNIT BANK2 A60BH 00B2H UNIT BANK2 A6BDH 0079H UNIT BANK2 A736H 0053H UNIT * * * * * * * C O D E B A N K 3 * * * * * * * 0000H 9881H *** GAP *** Refer NOTE BANK3 9881H 06ECH UNIT BANK3 9F6DH 0220H UNIT
The following is my conclusion.
NOTE: The starting address of each bank = End address of common bank + 1
When I shifted some piece of the code from common bank into other banks, I found that the starting address of each bank in the M51 file (A part of which i have shown above), changed.
However, a very good solution is change the Code Optimization level to Level10. Go to:
Project -> Tool Chain Integration -> Compiler (Tab) -> Customize -> Optimization -> Level
Select "Level 10: Rearrange Code (Linker Optimization)". Save Project and click on "Rebuild" or press "Ctrl + Shift + F7" keys.
Now write your code in any bank without worrying about linking. The linker will take care of everything. It rearranges the code in each bank and hence will generate the hex file with minimum code size.
OOps! Made a mistake in addition in my previous post.
987A + 7 = 9881
Sorry.
Dear All, If in case you find my observations wrong, or have any other solution, kindly inform me.
Thank you for all the necessary help, guidance and valuable time you provided. Learnt a lot. Hope the observations and conclusions helps other newbies to solve the problems related to 'Code Banking' and 'Address Space Overflow'.
Regards, Dhaval Solanki
Glad to see you've got it going.
Regardless of what anyone else might say about banking, I think what Keil did to provide the mechanism is really pretty smart. Certainly for the application I used it on, the results were perfectly acceptable; in terms of development time, reliablility and end product costs. And, after the initial learning curve in getting it going, the fact that we were using banking was virtually forgotten about.
That said, for any new projects, I would recommend you keep an open mind and consider something different.
Dear, I already highlighted ... Cortex-M3 is used for all the new project development. ... Never the less, I would also, as my personal opinion, always work with latest controllers and technology. .
I am glad that Keil has provided the feature "Optimization: Level 10: Rearrange Code (Linker Optimization) ". I mean they should, to be the best IDE software developers. Respect.
But i still Fail to understand
The starting address of each bank = End address of common bank + 1
This should not happen, ideally.
On the contrary: that must happen. Your believing otherwise indicates you don't really understand how banking works.
The common bank is called a "common bank" because it contains the material that has to be commonly accessible to code in all banks. The only way that can work is if the entire address range of the common bank is reserved and kept available, regardless which other banks are mapped. In a scheme like SiLabs', with a 32KiB+32KiB hardwired bank mapping, the only way the common bank can become bigger than 32 KiB is if all bytes beyond the 32 KiB boundary are copied to all 3 "upper" banks, so they'll be accessible regardless which of the upper banks is currently active.
I think your real problem was that in your original configuration you placed too much stuff into the common bank yourself, causing this spill-over mechanism to be triggered.
Dear Hans-Bernhard Broeker, Thank you for clearing the air. But, in my opinion, there should be a document produced by the chip vendor stating this. A newbie may not understand this, the very first time he is using the IC, or may not have a clear picture unless he faces a problem like me.
Dhaval