BL51 warning

Contrary to any error message, the problem is that these unused functions are NOT not remove from the overlay process. (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.)

These unused function are placed in overlay branches of their own. Thus their varaiables are not overlayed with the rest of your program. This wastes a lot of data space. Usually enough to break your program.

Here is a different techinque. Not only is it simpler, but it insures 100% overlaying of unused data space. Put only unused functions in the list, or that will also waste data space.

#include "RI2C.h"  //guessing the file name

char unusedFns( void )
{
  code char unusedFnsArray[] =
  {
    RI2C_SLAVEADDRESSRECEIVED,
    RI2C_SLAVESEND,
    RI2C_SLAVERECEIVE,
    _MOVXD0
  };

  return unusedFnsArray[0];
}

void mainProgram( void )
{
  //the code that used to be in main
}

void main()  //make no changes to this function
{
  unusedFns();
  mainProgram();
}

Contrary to any error message, the problem is that these unused functions are NOT not remove from the overlay process. (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.)

These unused function are placed in overlay branches of their own. Thus their varaiables are not overlayed with the rest of your program. This wastes a lot of data space. Usually enough to break your program.

Here is a different techinque. Not only is it simpler, but it insures 100% overlaying of unused data space. Put only unused functions in the list, or that will also waste data space.

#include "RI2C.h"  //guessing the file name

char unusedFns( void )
{
  code char unusedFnsArray[] =
  {
    RI2C_SLAVEADDRESSRECEIVED,
    RI2C_SLAVESEND,
    RI2C_SLAVERECEIVE,
    _MOVXD0
  };

  return unusedFnsArray[0];
}

void mainProgram( void )
{
  //the code that used to be in main
}

void main()  //make no changes to this function
{
  unusedFns();
  mainProgram();
}

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.

Since the "set of functions that are called" varies from program to program, guarding every single function with IFDEFs is very ugly.

Yep. If you create libraries, you should place one function in a source file. That way, the linker only includes those modules that are used. This is how the standard C library is built. The following knowledgebase article reiterates this:

http://www.keil.com/support/docs/2182.htm

Jon

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...