(1) Have you tried increasing the Stack Size in cydwr System window?
(2) Instead of zeros, can you fill the stack with unusual data at the startup. Please use an arbitrary number such as 0xFEEDBEEF that would stick out visually and the probability of application being written with it will be low. Later, please check the memory window to observe stack usage.
Can you add your latest findings here?
I tried the suggestions from GeonaP_26, which confirmed that stack size is not my issue and my problem is stack corruption, not stack overflow.
I believe the IDE shows "__cy_stack_limit" because it is trying to correlate a function name with data in the stack that should be a return address. Since the stack has been corrupted, the data in that location is invalid but happens to be an address within stack space. I assume the stack-unwinder, essentially, looks at the .map file and displays the section within which the address exists. In my particular case, the address is within the stack, and the stack memory address range starts at __cy_stack_limit, so that is what the stack-unwinder displays in the call stack.
As can be seen in this image, the "address" of __cy_stack_limit() is 0x20007C10. This address is within the stack, and is actually the address of the string that should be getting displayed by the GUI (as can be seen in the argument list of GUI__DispLine).
There seems to be an error in the function _DispLine. The parameter maxNumChars is too high, and the const char * s is referring to an invalid address. Can you kindly check how these parameters are evaluated before getting passed to _DispLine function?
Thanks, and regards,
Good observation. The invalid data appears to be the result of stack corruption because the values are correct in GUI_DispLine, and are simply passed, unchanged, to _DispLine. There is also no linear way in the code of GUI__DispLine for char* s or MaxNumChars to change.
There is also no way to go from _DispLine to GUI__GetPresentationForm, so I expect this is also an artifact of trying to unwind a corrupted stack.
It looks a lot like the stack pointer is off by 1 word. When returning from _DispLine, it should execute at 0x00002B4F (inside GUI__DispLine), but instead went to 0x00000004. There's a similar pattern lower in the stack, where it should return to 0x000039db, but instead the stack unwind saw 0x20007C10. This error occurs at random times, so I suspect something like interrupt interference, but I haven't been able to prove that.
Does anyone know of a way for the stack pointer to be incremented or decremented incorrectly? Perhaps some timing issue that could cause a push or pop to be repeated?
It seems like we need more inputs to understand this issue well enough to debug it. Can you kindly attach a minimal project which can reproduce this issue?
Solution was to change to the Keil compiler.
Thanks to everyone for your support.