This is a problem of warning 16. i have tried the solution given in keil site " This warning occurs when functions which are not called are contained in a program (e.g. for test purposes). The function specified is excluded from the overlay process in this case. Often this warning is accompanied by ERROR 107: ADDRESS SPACE OVERFLOW If you fix the uncalled warning the Error 107 is often cleared as well. There are two ways to solve this problem. 1. Call the uncalled function from somewhere in your program. 2. Remove or #if out the function that is not called. You can do that using #if 0 in front of and #endif after the uncalled function. For example: #if 0 void uncalled_function (void) { } #endif" even after each one of above the problem persists. Would you please throw some light. The errors are pasted as below. *** WARNING 16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS SEGMENT: ?PR?RI2C_SLAVEADDRESSRECEIVED?RI2C_DCN *** WARNING 16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS SEGMENT: ?PR?RI2C_SLAVESEND?RI2C_DCN *** WARNING 16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS SEGMENT: ?PR?RI2C_SLAVERECEIVE?RI2C_DCN *** WARNING 16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS SEGMENT: ?PR?_MOVXD0?CLIB *** ERROR 107: ADDRESS SPACE OVERFLOW SPACE: DATA SEGMENT: ?DT?TEXTVARS LENGTH: 0001H *** ERROR 118: REFERENCE MADE TO ERRONEOUS EXTERNAL SYMBOL: TXTREQ MODULE: ..\APPLIC\LIB\T90PTR1.LIB (TXREVEAL) ADDRESS: A13CH
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.
View all questions in Keil forum