strange trashed return address(?) problem

[namfuak]

Hi

I am working with MC9S08QE128 MCU and experience the following problem: my application sometimes seems to jump to wrong address when some function is called. I have reduced the funtion code to just "return 0;" statement, but the problem still persists (sometimes). It may be a plenty of explanations why this happens, but there is something I can't understand. The following is a bus trace captured with a debugger:

Frame |Address | Instruction | FIFO analyse remark |
--------------------------------------------------------------------------------------------------------
0 280D9 PSHX
1 280DA PSHH
2 280DB LDHX 8,SP
3 280DC
4 280DD
5 280DE CALL 0x028082
6 280DF
7 280E0
8 280E1
9 28082 CLRA
10 28083 RTC
11 28084
12 28085
13 28086
14 288B7 STX ,X Instruction outside application, DBG FIFO data 0
15 288B8 STX ,X Instruction outside application
16 288B9 STX ,X Instruction outside application
17 288BA STX ,X Instruction outside application
18 288BB STX ,X Instruction outside application
19 288BC STX ,X Instruction outside application

The function I am talking about is called at frame 5. The only instruction performed by function is CLRA which obviously can't alter the stack, but the following RTC causes jumps to wrong place. Can somebody explain how can it happen?

[namfuak · Accepted solution]

My ISRs was placed in banked segment, this is what caused the problem

[tonyp]

Try the CALL instruction with interrupts disabled to rule out the possibility of stack corruption by a third party (ISR).  Does it make a difference?  If it does, check your ISR code.

[namfuak]

Well, the caller function does some IO by writing data to buffer from where it is taken by SCI ISR, so I am almost sure that interrupts are somehow involved, but the big question is: if the callee function is interrupted by ISR, why it doesn't appear in bus trace?

[tonyp]

About the instruction trace not showing anything else, you may have a point.

But, it's also possible that the stack is already full right before the CALL (sometimes), and that the return address is pushed into non-RAM, so that when it is retrieved by the RTC, it's "garbage".

Can you check where the SP is pointing right before the CALL and right before the RTC (and the corresponding memory contents)?

The word "sometimes" in your problem description almost certainly indicates stack corruption, which can occur not only by overwritten stack memory but also by an SP register pointing outside the stack, or outside all RAM.

[namfuak]

There is a plenty of space in the stack and I already checked what you suggested, also the problem never happen when I am stepping with debugger, that's why I hoped bus trace will be useful. Thanks for your help, seems like I need to carefully review the ISR code. I just wanted to know that my understanding about how the bus trace works is correct.