Problem passing variable to function in ISR

Two things to consider.

One is that if you have code that gets called using different register banks or can be called asynchronously from different places, then you fool the compiler/linker. The compiler/linker converts auto variables into nameless global variables where each of these global variables may represent one or more auto variables. The flow control of the compiler/linker looks at what auto variables that may exist at the same time and matches them to different global variables. While auto variables that may not exist at the same time can reuse the same global variable.

The above is very complicated, and only done because the 8051 has such a lousy support for a real hardware stack.

If you mix register banks when calling a function, then the compiler/linker assumptions will break.
If both main loop and an ISR calls the same function, then the compiler/linker assumptions will break.

But there is another thing to consider too - the compiler/linker looks for common code. So quite often, a function may run the initial source lines, but then suddenly jump somewhere else. The compiler/linker have noticed that more than one function in the program have a code block that looks identical. Either it's the tail of two functions, in which case one of the functions can end with a jump into the middle of the other function. Or maybe it is some sequence in the middle of a function that is common with other code somewhere - so the code sequence can be broken out into a new, auto-generated, function. This can surprise a lot when trying to use breakpoints - the code is run. But the code isn't in this function, but instead identical code is run somewhere else.

Two things to consider.

One is that if you have code that gets called using different register banks or can be called asynchronously from different places, then you fool the compiler/linker. The compiler/linker converts auto variables into nameless global variables where each of these global variables may represent one or more auto variables. The flow control of the compiler/linker looks at what auto variables that may exist at the same time and matches them to different global variables. While auto variables that may not exist at the same time can reuse the same global variable.

The above is very complicated, and only done because the 8051 has such a lousy support for a real hardware stack.

If you mix register banks when calling a function, then the compiler/linker assumptions will break.
If both main loop and an ISR calls the same function, then the compiler/linker assumptions will break.

But there is another thing to consider too - the compiler/linker looks for common code. So quite often, a function may run the initial source lines, but then suddenly jump somewhere else. The compiler/linker have noticed that more than one function in the program have a code block that looks identical. Either it's the tail of two functions, in which case one of the functions can end with a jump into the middle of the other function. Or maybe it is some sequence in the middle of a function that is common with other code somewhere - so the code sequence can be broken out into a new, auto-generated, function. This can surprise a lot when trying to use breakpoints - the code is run. But the code isn't in this function, but instead identical code is run somewhere else.

That makes a lot of sense and definitely brings attention to how little I know about what's actually going on behind the scenes. I'm not sure I follow 100% of what you're saying but I'll read it over a bit and see if I can wrap my head around everything you wrote here.

Is there a place I can look to find out how to see what register banks each variable is being stored in to see if the auto assign is placing something in a different register bank and causing issues?

I guess my question is where do I start to learn a solution to this issue? Is there something I can do in code to work around this?

As far as "identical looking code" being compiled in an odd way (at least, I think that's what you're referring to), I don't believe I have much optimization set (it's currently set to 8 - Reuse Common Entry Code . . . maybe that's what you're referring to though).

As far as other settings go, I have the memory model set to Small, the Code Rom Size set to Large, and no operating system (I am currently using a M8051W chip from Mentor Graphics).

If you need any additional information, please let me know.

One last thing I should note, the NumOutSamples and Pressure1 variables are being stored as global variables and I have them in my VARS.C file as:

signed short idata Pressure1 = 0;
unsigned char NumOutSamples = 0;

and my VARS.H file as:

extern signed short idata Pressure1;
extern unsigned char NumOutSamples;

I apologize in advance if this causes any confusion or seems to conflict with my previous code posts, I was trying to create a simple piece of code that is quick and easy to read and evaluate.

Thanks again for the help!

I just realized that the lower the setting, the less optimization. I guess I misunderstood the optimization ratings because setting the number lower makes my code bigger. Which is concerning, already being at 7k . . . :p

I guess I have a lot more optimization in my code than I realized. That might explain a few things . . .

One last thing I should note, the NumOutSamples and Pressure1 variables are being stored as global variables and I have them in my VARS.C file as:

signed short idata Pressure1 = 0;
unsigned char NumOutSamples = 0;

Unfortunately, that means the code you showed so far has esentially no relation any more to the code you actually used. That makes it all but impossible to help you meaningfully.

You've not only messed up the type of your key variable, Pressure1, from short to unsigned char, but also changed its storage duration (from static to automatic) and linkage (from function-internal to global). In short, you kept nothing but the name intact.

If you have problems with some code, you really have to show that actual code, or at least a reduction of it that actually exhibits all the problems you have.