Hi,
I have an existing project which contains my code and code of a library and I would add again a little part from this same library (Atmel) 3 new files ( file.c, fs_varaiable.c and fat.c) at this project but after adding the fat.c file I have receive too many errors and warning. For a segment (function) there are too many differents warning but which one is the first and so?
Can you advice me to best implement a part of a library?
The output file is:
Sequences of warnings (LX) and errors (Error LX)
L16 24 x L15 1 x ERROR L107 30 x L1 6 x Error L105 1x Error L120 1x Error L118 1 x Error L105 7x Error L120 10x Error L105 4x Error L120 2x Error L118 12x Error L120 1x Error L118 2x Error L120 1x Error L118 1x Error L120 1x Error L118 24x Error L105 1x Error L120 1x Error L118 84x Error L105 2x Error L120 2x Error L105 1x Error L120 2x Error L105 1x Error L118 20x Error L120 1x Error L118 14x Error L105 1x Error L118 22x Error L120 1x L1 2x Error L105 1x L2 2x Error L120 1x L1 12x Error L105 7x Error L120 1x L2 46x Error L120 1x L2 93x Error L120 1x L2 30x Error L120 3x L2 18x Error L118 2x Error L105 1x Error L118 4x Error L105 1x Error L120 1x Error L105 1x Error L120 1x Error L105 1x Error L120 1x
////////////////////////////////
Build target 'Target 1' compiling main.c... compiling I2C.c... compiling ADC.c... compiling AUD.c... compiling DAC.c... compiling MICRO2.c... compiling DONG2.c... assembling STARTUP.A51... compiling variable.c... compiling ide_drv.c... compiling C_Flash.c... compiling CF_oper.c... compiling cf_drv_.c... compiling ata.c... compiling file.c... compiling fs_variable.c... compiling fat.c... linking... *** WARNING L16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS SEGMENT: ?PR?CAG?ADC *** WARNING L16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS SEGMENT: ?PR?MICRO?MICRO2 *** WARNING L16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS SEGMENT: ?CO?VARIABLE *** WARNING L16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS SEGMENT: ?PR?_FILE_SEEK_PREV?FILE *** WARNING L16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS SEGMENT: ?PR?_FILE_SEEK_NEXT?FILE *** WARNING L16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS SEGMENT: ?PR?_FILE_ENTRY_DIR?FILE *** WARNING L16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS .... ... ... ..
Can you help me please?
Thank you
"Uncalled segment" means that your files contain code that is not used in your project. This code takes up space, and what is often worse, serves as another root for the call tree for parameter and local variable overlay. You should avoid linking unneeded code into your project. Also, see the REMOVEUNUSED linker directive.
"Address space overflow" means that your code does not fit into the available memory. You've got more than 64KB of code, and so something has to go. You can try higher levels of optimization, emphasizing space. But you might have to roll up your sleeves and rewrite some code to do the same job in less space. Alternatively, you need to use more memory (and since you've reached the 64KB limit, that means bank switching, which may mean hardware changes for the banking logic in addition to a larger RAM).
Now I have too many warnings L118 but again ERROR L107 address space overflow in space code, this error has occur when I remove the #if 0 #endif from a big function.
How can I do to resolve this problem, it's very hard to find a solution to this ?
"ERROR L107 address space overflow in space code, this error has occur when I remove the #if 0 #endif from a big function."
So, you add a large amount of code (a "big function"), and then your code space overflows - why would that be a surprise to you?
Once you've had an error like that, it is likely to cause errors in everything else the Linker subsequently does!
Therefore, you need to fix the first error, then rebuild and see how many are left...
Not very hard, reduce the size of your code or increase the size of your code memory (if you are below 64k)
A one gallon bucket can not hold two gallons of water.
Are you using a small derivative and have specified the max code size to match, or are you overflowing 64k?
Erik
"A one gallon bucket can not hold two gallons of water."
And every single extra cup you try to put in will each cause further overflow!
Thanks,
It's my code Rom which is overflowed
I use in options target in target tab :
Memory model : Large variables in XDATA code Rom size: Large 64 K program Operating system : None
I think it is otpimal memory sizing, can I do anything else to grow up my rom size
What happened to Ali Bas?
"It's my code Rom which is overflowed"
Not quite.
The Linker doesn't know anything about your hardware - all it knows about is 8051 address spaces. It is telling you that the 8051 CODE address space has overflowed. (that may happen to be mapped to your ROM, but the Linker doesn't know that)
"I use in options target in target tab :
Memory model : Large variables in XDATA code Rom size: Large 64 K program Operating system : None"
So you've told the Linker that you have 64K of CODE space available. The Linker is telling you that your code will use more than that available space.
"I think it is otpimal memory sizing"
Why do you say that? Does it actually reflect the amount of memory available on your target?
"can I do anything else to grow up my rom size"
The 8051 architecture is inherently limited to 64K of CODE space - because the address bus has 16 bits.
So your only options to increase CODE space are: 1. Use Banking (or "paging"); 2. Use an extended 8051 derivative with >16 address bits.
The other approach is to reduce the size of your code to fit into the available space.
See http://www.keil.com/forum/docs/thread1082.asp for some tips
What optimisation level are you using?
Using XDATA for variables can use a lot of code space - because of all the loading & reloading of the 16-bit DPTR. Moving your most-used variables to DATA (preferably) or IDATA could significantly reduce code size - I have seen a reduction of several K bytes by doing this!
You can identify your most-used variables by using the uVision Source Browser: http://www.keil.com/support/man/docs/uv3/uv3_ut_sourcebrowser.htm Click on the title of the 'Uses' column to sort by the number of times a symbol is referenced...
Thanks Neil, and everyone here
Sorry for my English. So I try what you say and I think this is very good because my code size is getting more light.
But I see in View -> Source Browse that there is data, macro , typedef, function Classes. Me I change xdata space from data classes so it's correct but can I do something for other classes ?
And when a data class is a code space can I change it to data ?
for example : MyArray1 data array code 5 MyArray1 data array code 2 MyArray1 data array xdata 2
I just forget to ask an important question: When I change the xdata variables to data variables depending of types and uses of variables can it be some problem in my program?
For example I have a CompactFlash ide device in my PCB, the registers of this CF must be xdata type, and what about any others variables which must be xdata are there any or not?
Why must the registers of the CF be xdata type? Do you mean that you have mapped the CF to your XDATA space? If so,you surely couldn't change them from xdata to data.The access to data doesn't make the 8051 chip outputting any signal.
Ali Bas is back again!
"And when a data class is a code space can I change it to data ?"
Usually, if "data" is stored in CODE space, that's because it's constant. If you did move such variables into a "data" space, something would still have to load the constant values into them at runtime - this would require some code. Since the object of the exercise is to reduce your code size, this would be a Bad Thing!
But the LX51 Linker does allow you to place constants into XDATA space, assuming that your hardware can map some ROM into XDATA space
See: http://www.keil.com/support/man/docs/c51/c51_xcrom.htm http://www.keil.com/support/man/docs/c51/c51_le_const.htm http://www.keil.com/forum/docs/thread6231.asp
Obviously, if there are specific reasons why a variable needs to be in XDATA - then it must stay in XDATA!
eg, memory-mapped peripherals (your CF card, perhaps?) must remain in XDATA (unless you have some very special derivative that allows you to map them to an "internal" space).
Any variable that is too big to fit into DATA or IDATA will have to stay in XDATA.
However, you might be able to gain some advantage from "cacheing" data internally; ie: 1. read from XDATA into DATA; 2. process in DATA; 3. write results back to XDATA.
Only you can tell whether this might be worthwhile in some particular instances in your specific application.
You should probably look at the other options for code-reduction first (optimising your code).
If you have exceeded the CODE memory physically available (or addressable) on you target, then it will require significant hardware changes to increase it.
Moving to code banking may also require you to make extensive code changes.
Therefore now might be a good time to review whether the 8051 is really the right choice for this project. Would you not be better choosing another family (eg, ARM) without such a code space limitation...?
Switching architectures is non-trivial - but it may be worth it in the long run!
This time,
I would be Sems Gencay and till I'm in Keil Forum :) I used Ali Bas because I don't remember my first log in registered in Keil.
Thanks, I would consider to map code (constant) to XDATA but for switching the hardware it's to late because other functionnalities are all OK and the PCB are fonctionnel except for the moment the read of mp3 file because I have implement the Atmel library for my µC AT89C51SNDC1 which include an mp3 decoder.
I have already implement the Atmel library for read of the Compactflash of my PCB.
The idea is to read depending on conditions one of the mp3 files present in the CF.
Thanks But
So now I have small numbers of warnings but now I have my CODE which is more big is limited and I have heard that the code size must be 1K under the limit.
Program Size: data=160.0 xdata=1787 code=65155
For implmeneting more files in my projetc I have changed xdata's data on data's data. But how can I reduce the code memory size because this is generally for functions ?