BL51 warning

Thanq..
But the warning 16 reads removing this warning can remove "address space error" too.

Mean while i have checked the method given in site to solve this which is as follows
======
*** ERROR 107: ADDRESS SPACE OVERFLOW
SPACE: DATA
SEGMENT: _DATA_GROUP_
LENGTH: 0014H

Above error specifies that a 14h byte long segment named _DATA_GROUP_ can't fit in the remaining DATA space. Referring to the link map, the DATA space starts at 8h and has a single segment ?DT?ASDFASDF that occupies 65h bytes. Since the DATA space is 80h bytes max., we can calculate the space remaining as 80h - (8h+65h) = 80h - 6Eh = 12h. So, there are only 12h bytes left in the DATA space. Since the _DATA_GROUP_ is 14h bytes long, it can't fit in the remaining 12h bytes.
=====
I calculated my project space which comes to 72h which means i have 8h remaining, but then why it cannot allot 1h.
my data space is allotted like below..
DATA 0010H 000AH UNIT ?DT?RI2C_DCN
DATA 001AH 0006H UNIT ?DT?UIMN
DATA 0020H 0001H BIT_ADDR RI2C_BITADR
DATA 0021H 0002H BIT_ADDR ?BA?TEXTVARS
DATA 002FH 0021H UNIT _DATA_GROUP_
DATA 0050H 0006H UNIT ?DT?HWSN
DATA 0056H 0006H UNIT RI2C_PAR
DATA 005CH 0004H UNIT ?DT?OSRC
DATA 0060H 0004H UNIT ?DT?PA
DATA 0064H 0003H UNIT ?DT?OSKB_AN
DATA 0067H 0003H UNIT ?DT?UILK
DATA 006AH 0002H UNIT ?DT?HWOD
DATA 006CH 0002H UNIT ?DT?HWTN
DATA 006EH 0002H UNIT ?DT?SN
DATA 0070H 0002H UNIT ?DT?VD
DATA 0072H 0002H UNIT RI2C_INTTMP
DATA 0074H 0002H UNIT ?DT?_MOVXD0?CLIB
DATA 0076H 0001H UNIT ?DT?HWTV
DATA 0077H 0001H UNIT ?DT?MS
DATA 0078H 0001H UNIT OSTIVAR
DATA 0079H 0001H UNIT ?DT?SM
DATA 007AH 0001H UNIT ?DT?SS
DATA 007BH 0001H UNIT ?DT?TNFR
DATA 007CH 0001H UNIT ?DT?UIPC
DATA 007DH 0001H UNIT ?DT?UIBG
DATA 007EH 0001H UNIT ?DT?UIFM
DATA 007FH 0001H UNIT ?DT?UIRK

Is there any other way to checkout this problem?
Please let me have your reply..

Contrary to any error message, the problem is that these unused functions are NOT removed from the overlay process.

Well, to be MORE specific, the functions that are uncalled are noted with the Warning Messages.

Since the linker can't find anyone who calls these functions, it assumes, that they are called from someplace it doesn't know about. So, it does not include them in the overlay analysis. So, uncalled functions use up DATA memory that cannot be overlaid with any other function. Therefore, the memory they use (for local varialbes) is completely wasted.

(The prefered method of handling unused functions is to remove them. I do NOT have a clue as to why Kiel does it this way.)

The reason we don't remove them is because the developer MAY actually be calling the function and is relying on the linker NOT to include the function in overlay analysis. It would kinda suck if this is what you were trying to do and the linker kept removing your functions.

As for a solution to the warnings and ultimately to the data space overflow...

When creating a test harness for an application, I never leave my test code in place in the product that I ship. So, my first suggestion would be to use IFDEFs around the TEST code. For example:

#ifdef TEST_HARNESS
void test_func_1 (void)
{
.
.
.
#endif

void main (void)
{
#ifdef TEST_HARNESS
  test_func_1 ();
  test_func_2 ();
  test_func_3 ();
#else
  // real application code goes here
#endif

while (1);
}

void main (void)
{
test_func_1;  // This function is NOT called
test_func_2;  // This function is NOT called
test_func_3;  // This function is NOT called
.
.
.
}

Looking at these functions, I think these are in some 3rd party software in which he has no control. If so, his only option is to make some dummy references to them.

With regards to:
"The reason we don't remove them is because the developer MAY actually be calling the function and is relying on the linker NOT to include the function in overlay analysis."

This is an incorrect statement. The unused function ARE include the the overlay analysis. It is just that new root branches are created. Any subroutines they call will have their data structures ovelayed.

Since functions are relocatable, the linker HAS to fix all references to them. So the linker must know EVERY reference to a function. Does it not follow that if the linker sees no references to the function then the developer does not call it? Am I missing something here?

This is an incorrect statement. The unused function ARE include the the overlay analysis. It is just that new root branches are created. Any subroutines they call will have their data structures ovelayed.

Ahh. Yes you are right. I just meant that they are not included in the overlay analysis of the main program. They are their own brahcnes.

Since functions are relocatable, the linker HAS to fix all references to them. So the linker must know EVERY reference to a function. Does it not follow that if the linker sees no references to the function then the developer does not call it? Am I missing something here?

Yep. Let's say that I have a function that sets configuration variables in my program. And that it's going to be called by a secondary program (like a boot loader) and that I use the linker controls to fix the location of the function at 0xC000. Then, my loader can call the function (by making an LCALL to 0C000h). And, there will be no reference to it in the program. And yes, there are programs that do wacky stuff like this. And yes, I hate it, too.

When I started creating tools for engineers, one of the hardest things for me to overcome was wanting the customer to do things the right way. It just doesn't happen.

Jon

ohhhhh...

I think we have reached a dead end and i should re-orient whole project by checking references.

The point we have to find out would be whether The address space overflow error can be generated from any other possible problems.

I am trying to locate and fix up the same.
Please keep me posted on all developments.

I agree with you that all subroutines with fixed locations must be left in. However that still leaves the bulk of the unused functions, the relocatable ones.

How about a "remove unused, relocatable overlay branches" option. Where an unused branch is one not marked with main, isr, or task. Where relocatable branch is one that only contain relocatable functions. This would be a complete solution for most people.

This sure would be a plus to people like me who write reusable "classes" or "drivers". It is nice to write complete classes, which means that most programs don't call every function. Since the "set of functions that are called" varies from program to program, guarding every single function with IFDEFs is very ugly.

That works, but it is even uglier. Maybe the solution is a "Module name directive" that can be used in between functions?

I think thats the only thing remaining.

Adding a module name in betweeen functions looks interesting .

is there any knowledge base for this article.

ANOTHER POINT IS THERE ARE SOME FUNCTIONS DECLARED WITH EXTERN FUNCTION WHICH DOESN'T HAVE DEFINITION IN WHOLE PROJECT. WHEN I TRIED TO ADD DEFINITION THE C51 COMPILER GAVE FUNCTION REDEFINITION ERROR. I DO NOT UNDERSTAND WHY COMPILER IS GIVING SUCH AN ERROR.

Please keep me posted with your advices.

Are the extern and function declared identically? Do they have the same enviroment ( ROM(SMALL), etc )?

or are the definitions hidden in a Library somewhere, with no source?

I seem to remember raising this as an issue with the Keil error/warning messages before:
They talk about "Duplicate" definitions, but then list only one definition in the diagnostic - whereas, obviously, there must be two to make a duplicate!

Thank you all..
I have removed all error messages and only the 4 warning 16's are remaining.

What i have done is just changed the memory selector from DATA to IDATA which removed address space overflow in DATA segment as well as other 4 errors. The implications of this change in the project has to be checked.

But now these nagging warnings are still there.

Do you have any valuable suggestions...