_DATA_GROUP_ Overflow error

It's because of the linker overlay process.

Because the function is not called via the usual exectution path, the linker assumes that it might be called via a function pointer or an ISR. Therefore it must be considered to be in a separate call tree and local variables are not overlayed with the ones they were previously overlayed with.

Sorry - My explanation probably sounds confusing, but it is detailed pretty well somewhere in the Keil documentation.

It's because of the linker overlay process.

Because the function is not called via the usual exectution path, the linker assumes that it might be called via a function pointer or an ISR. Therefore it must be considered to be in a separate call tree and local variables are not overlayed with the ones they were previously overlayed with.

Sorry - My explanation probably sounds confusing, but it is detailed pretty well somewhere in the Keil documentation.

The above shows why warnings should be treated as errors unless you are 100% sure that you know what the warning means and are 100% sure that you know if the warning represents a harmless condition.

If you had used the search box here, you could have found a number of threads discussing the memory consumption created by uncalled functions.

yup you are right. It makes sence...
actually the functions i am commenting have to called in the final application that goes into the hardware.

i want the application to run in Keil so that i can use some simulators which in turn help me time consuming process of loading the app to the hardware every time a make small change. But when i run in Keil some of functions blocks execution because they are expecting some responses from hardware, i just want to comment these functions so that it doesnt block anywhere..

any idea how to remove this linker error msg i get..

Most people use either conditional compilation or a special source file with suitably augmented stub functions.

Let the stub functions send output on a serial port or similar, and possibly extract input from data structures or a serial port. By faking I/O you can run large parts of your logic in the simulator or regression-test large parts of the code without building expensive hardware jigs that creates stimuli.

hmm yup that will be my last option :)

actually i am developing simulator in VC++ and using the AGSI interface facility provided by Keil uVision IDE to hook it up with my application...

any how this process is becoming complicated so may be i start using stubs iself...
thanks for the comments :)

The call tree analysis is described in http://www.keil.com/support/man/docs/bl51/bl51_ol_calltree.htm

If you manually remove a function from the call tree (by commenting out the call to it) the compiler still generates the code for the function and the linker still has to allocate memory to it. However, since it's not part of the call tree, the memory allocated to it cannot be overlaid. And, your application uses MORE memory.

Jon

"The call tree analysis is described in..."

And it works exactly the same way irrespective of what memory model you use.

"However, since it's not part of the call tree, the memory allocated to it cannot be overlaid. And, your application uses MORE memory."

And exactly the same will happen irrespective of what memory model you use.

Therefore, if the "un-overlaid" memory size also exceeds your XDATA size, you will still get an overflow if you switch to the Large model - the only difference is that it's XDATA overflowing, instead of DATA.