Hi,
I am getting the "BL51: WARNING 15 (MULTIPLE CALL TO SEGMENT)" warning because a group of functions are called by an interrupt handler. The functions themselves are not reentrant.
Following the advice at http://www.keil.com/support/docs/805.htm, Method 2 is the most suitable solution to my problem. However this causes the increase of DATA and XDATA usage as the memory used by the functions are not overlaid.
My question is, is there a way to group the functions so that the memory usage is overlaid within this group? I tried declaring a new MEMORY CLASS and re-direct it using #pragma userclass ( XDATA = newClass). However this method only works for XDATA as #pragma userclass( DATA = xxx) is not a valid directive.
Any help would be greatly appreciated.
However this causes the increase of DATA and XDATA usage as the memory used by the functions are not overlaid for obvious reasons, variables used in an ISR can not be overlaid.
Erik
The variables are not used in the ISR, but the variables used in the functions called by the ISR. Sample of call tree.
Timer_ISR - func1 - func1a - func1b - func1c - func2 - func2a - func2b - func3 - func3a - func3b
Obviously the variables used in func1a, func1b, func1c, func2a, func2b, func3a, func3b can be overlaid?
But any function called by the ISR are - for this argument - part of the ISR. It is irrelevant that the source code happened to be broken part into multiple functions. What is relevant is when the code is called in relation to other code.
Yes, func1a could have variables overlayed with variables in func1b or func3a. But that is only applicable if they are part of a single call tree. If they are shared with the main program, then they are part of both the call tree for your ISR and the call tree for main().
And when you say that you want to exclude functions from overlay analysis, then you explicitly say that they should not use overlayed variables.
That is a reason why people often make duplicates of functions that are called by both the main() call tree and an ISR call tree.
the easy solution is not to use function calls in ISRthis makes sense BECAUSE: KISS (Keep ISRs Short and Swift)
an ISR that is complex enough to require function calls is likely to upset the apple cart by stealing too much time from main and other ISRs