configCHECK_FOR_STACK_OVERFLOW only catches about half of my mistakes. It's easy to leapfrog right over the guard band. I have better luck using vTaskList to monitor the stack usage.Thank you @carlk3 for reply.
This is what I was suspecting as well as one of the causes, however, the suspect seems to be hiding very deep. Using mechanisms from SDK and FreeRTOS (PICO_USE_STACK_GUARDS for the main stack and canaries + stack overflow hooks for RTOS) doesn't seem to show any problems.
I like this article: Are We Shooting Ourselves in the Foot with Stack Overflow? Miro Samek●September 8, 2023. (Actually, I like a lot of Miro's stuff.)...Perhaps you could point out some good-to-read sources for this type of issue? (I think I've read all of the internet on this topic regarding cortex M0+, yet I know that's not true...).
Armv8-M architecture has some nice stack limit checking features: for processors based on the Armv8-M Mainline architecture (like Cortex-M23 or M33), each of the stack pointers has a corresponding stack limit register which allows software to define watermark levels for stack overflow detection, and when stack overflow occurs, a Usage fault or HardFault exception is triggered. Unfortunately, M0+ does not have this.Back in the day, I had an issue with an arithmetic overflow of a result register - it took a while to figure out that at the HardFault exception, the xPSR shows as well the overflow flag and this pointed me to the right place for further looking. However here this path leads to nowhere.
Not related to stack, but have you set configUSE_NEWLIB_REENTRANT? I once spent a couple of days diagnosing an intermittent problem that was caused by using floating point printfs while configUSE_NEWLIB_REENTRANT was not set (but I was using newlib's printf then). Might be worth a try.
Statistics: Posted by carlk3 — Sun Mar 24, 2024 7:57 pm