How to identify runtime stack overflow detection in CCES
When stack overflow is occurred at that time the stack overflow interrupt is triggered and also the "_adi_stack_overflowed" function is called by default.
Stack and Heap are Run-time storage sections.There is no mechanism within the tools for monitoring the Stack usage in real-time. The only feature with stack is to set the stack overflow check in project option via Generate code to catch a Stack Overflow or -rtcheck-stack.
The stack is implemented as a circular buffer using I7. When stack overflow detection is enabled, the corresponding circular buffer overflow interrupt (CB7I) is enabled. If the stack overflows, the interrupt is triggered and transfers control to a function called _adi_stack_overflowed. The IDE places a break point on this function automatically, by default. If you hit this break point, examine the PCSTK register to determine the interrupt handler return address. The instructions at or just prior to that address that modify I7 are most probably the cause of the stack overflow.
It is possible that instructions for higher priority interrupts (than CB7I) may delay hitting the break point. In this situation it will be necessary to look for a cause of stack overflow in those higher priority handlers or the code immediately before they are raised.
There are some debug features available in CCES to determine the profile of your application, as well as checking stack and heap tracing etc. We recommend looking at the section:
CrossCore® Embedded Studio <version> > SHARC® Development Tools Documentation > C/C++ Compiler and Library Manual for SHARC® Processors > Optimal Performance from C/C++ Source Code > Analyzing Your Application
We recommend to refer the section "Stack overflow detection" in the Compiler Manual for SHARC Processors linked below, that explains how the stack is managed.