Chris:

Have you had some opportunity to try to look at the underlying code produced by your tool set to determine if the stack pointer or 2nd -> 4th register sets are the cause of your corruption?

It sounds like you feel reasonably comfortable with the assembler language level look of the 8051. The reason I asked about how you go about debugging was that one strong method to isolate and understand problems like this to look directly at what is writing to the corruption area of the memory. This close look is by nature going to be right at the MCU hardware/architecture level. That is of course going to be in the assembler view at the CPU register level.

Now whilst the problem you are encountering may or may not be one of the two scenarios that I had proposed it is still possible that the issue centers not on a fundamental C language mistake but instead on a error in how the C solution maps to the unique characteristics of the 8051 and its hardware architecture.

Debugging at the level of the MCU itself is also very good way to gain a thorough understanding of how the C compiler translates the high level code to the target machine environment. The 8051 environment is unique enough that the vendors of the better compilers have gone to great lengths to optimize the translation and mapping process. In the long run you'll be most successful with producing working programs from C if you have a firm grasp on how your particular compiler does these things.

Michael Karas