What are causes of callstack to overflowing?

[ignisuti_]

I've modified my start-up code for a special bootloader design, but it's left me with the following problem.

My callstack fills 100 levels deep with the calling function. I checked the stack and I'm seeing the appropriate number of bytes get pushed onto it, not 100's.

This is an odd problem to me. What other kinds of things do I need to be looking for in order to find the fix?

[mjbcswitzerland]

Hi Joe

It looks like main() is calling itself.

void main(void)

{

  main();

}

Regards

Mark

[ignisuti_]

Yes, I see that in the callstack, but I see no reason (no recursion) for that in my code. Any ideas why my callstack would behave like this?

[mjbcswitzerland]

Joe

Set a break point in your main and single step the code (preferably in disassemble mode) and you should be able to see whether/where the calls are taking place.

If the debugger shows a call stack as it does it is either (really) taking place or the debugger is making mistakes.

Regards

Mark

[ignisuti_]

Mark,

Great minds think alike. I was just doing that. :smileyhappy:

Everything seems okay until I get to instruction "push {r7,lr}". Running dissassembly instruction causes the callstack to expand like this. Before and after this instruction is executed, the LR holds 0xE313 which is the correct value. The value in R7 (0x1fffc7f0) is actually pushed to the SP, not the LR. Note: My stack starts at 0x1fffC800. So, having the SP updated to this value seems reasonable to me. However, why does the assembly instruction indicate LR when SP is rightfully updated? And, why does the callstack expand if LR isn't actually updated?

Just speculating here, but is the fault actually the Compiler using the wrong instruction which has confused the debugger?

[mjbcswitzerland]

Joe

push {r7, lr} means push both r7 and lr to the stack. Therefore you should see that both register contents have been put onto the stack and the SP has been decremented by 8. lr will not change.

Regards

Mark

[ignisuti_]

Good catch. I did mis-interpret that instruction. In that case, everything checks out as far as I can tell.

______________________________________

I got it fixed now! Going through this exercise helped me think out a few things more clearly. I had re-used the __init_registers() function in the Application code which mucked things up. I had put it there earlier on amongst many other changes to trial an idea that is no longer necessary.

Thanks Mark for helping me think through this!

[ignisuti_]

Here's a small snippet of my stack contents for the scenario described above.

Note: I'm using the TWR-KW24D512 on CW10.6

Note: My stack intentionally starts at the beginning of RAM and runs from 0x1FFFC000 to 0x1FFFC800

I understand there are many deviations here outside of Freescale's guidelines, but this is the path we've chosen. Any guidance on this one particular issue would be a huge help.