STM32F105 Stack Overflow in Eclipse Debug mode

[podhrmic]

Dear all,

I am using ChibiOS to develop a Real-Time OS based autopilot for UAVs (https://github.com/paparazzi/paparazzi/ ... _paparazzi) and I ran into a subtle problem.

My applications has 9 threads, each thread has enough allocated stack size (at least 256kb). If I just flast the code and run it, it works great with no problem. However, when I launch the code in debug mode from Eclipse debugger, I seemingly randomly get "stack overflow error" at either chCreateStatic() or chThdSleepUntil() at the very beginning of the program. This error happens approximately every second time I try to start debug session.

However, if I step over the code the stack overflow doesn't happen.

I am calling chCreateStatic() for all threads from the main thread, so I tried to increase stack size for each thread (no effect) and for the main stack in the linker script (also no effect). Decreasing(!) the stack size on the other hand causes _unhandled_exception instead of stack overflow (as I would expect to happen every time with inssufficient stack size).

I read abou similar issue in viewtopic.php?f=16&t=1106 and viewtopic.php?f=2&t=714

Could you please point me to what might cause the problem? Might it be the debugger issue (since the program runs seemingly without problems if not in debug mode)?

I have all the debug checks in chconf.h enabled. I am using Eclipse Kepler Service Release 1 (build id 20130919-0819) with GDB debugger version 7.2.0 and ChibiOS v 2.6.2 and arm-none-eabi toolchain version 4.7.4 20130913

Thank you very much.
Michal

[Giovanni]

Hi,

In the linker script there are two stacks defined:

__main_stack_size__ is the stack for IRQs, not the main() function.
__process_stack_size__ is the stack used by the main() function. You need to change this one.

It can be misleading but those are the names used in the ARM documentation.

There is also another "hidden" stack that can overflow, it is the idle thread stack, its size is set normally to 16bytes but if you compile with no or reduced optimizations might be required to increase this value because the compiler starts wasting stack space.
You can change this by defining PORT_IDLE_THREAD_STACK_SIZE=64 (or any other value).

Note that enabling optimizations reduces the stack usage so it is advised to do final measurements using the final compiler options.

If PORT_IDLE_THREAD_STACK_SIZE fixes your problem I will increase the defaults, 16 was enough but compilers change over time.

Giovanni

[podhrmic]

Hi Giovanni,

I tried both suggestions, but neither of them makes any difference. Note that the program runs just fine without the debuggger (i.e. upload and power up).

However, the debugger now seems to always halt (with dbg_panic_msg = "stack overflow") upon first occurence of chThdCreateStatic() of HIGHPRIO thread. When I set all thred priority to NORMAL or LOW, then the debugger halts in the main() -> chThdSleepUntil()

I am mostly confuzed that the program runs fine without the debugger - if there were stack overflow, the system would halt because of the debug checks I have enabled in chconf.h, right?

M

[Giovanni]

That message can only happen because a stack overflow, the check is done during context switching so it is normal that it happens when you can something that can switch threads.

Giovanni

[Loial]

Sorry, this is an old thread, but this might be helpful to others.

I've been having a similar problem - it looks like the first thread errors out with stack overflow but looking at the context switch the main thread is the culprit.

On the first call to chSysSwitch SP=0x200003E8 and otp->p_stklimit=0x20000400. I'm guessing there's some issue that the main thread isn't being switched correctly into process mode probably due to my bootloader. I'll suggest doing a similar test (breakpoint on all four locations of chSysSwitch in chschd.c) and see.

I'll update as soon as I've tracked down the point where it's either failing to switch to process-mode or where it's being switch back.
-- edit --
Looks like
#if CORTEX_USE_FPU
....
#else
reg = CRT0_CONTROL_INIT;
#endif
asm volatile ("msr CONTROL, %0" : : "r" (reg));
asm volatile ("isb");

This is copying the value into the register but doesn't apply it correctly to CONTROL.
I've tried to enforce it on entering 'main' but again it doesn't apply it. I'm going to check if it's still thinks it's in a service routine or something.

-- edit again --

In my case it's because I was using a PendSV to call the reset handler and was using it wrong - the CPU was still in PendSV (and for some reason worked some of the time... weird)