I'm getting to: wiced_assert( "ThreadX stack overflow", 0 != 0 ); when I try to run my application in debug mode. Memory exploration indicates that there is not actually an overflow going on. It happens when I receive the 2nd character via a UART connection (I've explored the receive buffer, first char is in the ring buffer) and from the stack trace indicated in the debugger is happening in the driver UART ISR.
I'ts preventing me from actually debugging, and I've tried ridiculously large stack sizes to no help.
I've also seen this discussion, ThreadX stack overflow when DEBUG enabled but increasing my stack size did not solve the problem.
Debug screen showing the assert, memory view of the stack area, thread details including stack pointer/start/end, and call trace here:
Solved! Go to Solution.
During debug mode, threadX thread stack checking is enabled and this error is thrown when a stack overflow condition is detected. Typically UART debug prints or printf does consume memory. Also threadX was built with the flag TX_ENABLE_STACK_CHECKING enabled to detect stack overflow using tx_thread_stack_error_notify(). This also results in slightly increased overhead and code size. Have you tried reducing your code size in that thread?
I'm not actually printing at the time or from that thread. The thread is receiving UART data from another processor at the time of the error - no printf or similar is used in that thread. I'm just staring this project, code size is minimal so far.
I've copied the config_join_ping example, added a small thread to send a test command to another device (on the fast UART, NOT the UART used for the console / printf) and receive the response. This works fine and gets the correct response if built normally (I've checked by adding a console command to read the result). I am having a problem with the next step (after getting the reply) that I need to debug - but when I build for debug, I get the threadX stack overflow error before I get to the function I need to debug.
Again, all analysis shows we are nowhere near a stack overflow issues in this thread or the console thread.
Adding stack size to either or both threads doesn't change anything (stack pointer in the thread is always the same offset, 431 bytes, from the top of the thread stack).
Is there some other / assumed/default / ISR stack size configuration?
Thanks for the update. We will investigate if there is any other stack configuration and get back. Can you test your project with freertos and let us know if you still observe the stack overflow? At this point, we want to understand if this behaviour is RTOS dependent.
Yes the behavior is RTOS dependent. I do not have this issue built with FreeRTOS.
Have you written the code to receive UART data inside an ISR? It is possible that the stack overflow is being caused due to deep recursions. The recursions could be because of multiple interrupts, nested calls, etc. Try to ensure that the ISR execution time is as short as possible and avoid situations where deep recursion is possible.
If you have isolated the code with the stack overflow issue, write a separate example project containing only the isolated code, debug the same and then integrate with config_join_ping example.
The ISR is in the WICED UART driver - I did not write that. It only happens in debug builds.
I'm getting the same problem when trying to get BLE discovery working with the CYW43012.
I have tried increasing the application stack to 10k, but the stack overflow error occurs when in a DMA interrupt that has interrupted the "BTU" thread, and I can't find a way to increase the stack size for that thread (doesn't seem to be in any source code, so must be in a library).
The stack dump is:
wiced_threadx_stack_error_handler() at wwd_rtos.c:460 0x800d0e8
_tx_thread_stack_error_handler() at 0x80132cc
_tx_thread_system_resume() at 0x8013434
_tx_semaphore_put() at 0x8012e5c
_txe_semaphore_put() at 0x8011482
host_rtos_set_semaphore() at wwd_rtos.c:323 0x800ceea
platform_uart_tx_dma_irq() at platform_uart.c:732 0x800ed74
dma1_stream6_irq() at platform.c:754 0x800c42e
__tx_dma1_stream6_irq() at platform.c:752 0x800c416
So the stack doesn't look very deep (but it may not have been able to trace the full stack because of the interrupt).
And the interrupt is not one I have written, but is the supplied code for the STDIO UART.
I can't compile my application for FreeRTOS, so I don't know if that helps, because I get this error:
libraries/drivers/bluetooth/low_energy/low_energy.mk:56: libraries/drivers/bluetooth/low_energy/low_energy_src.mk: No such file or directory
make.exe: *** No rule to make target 'libraries/drivers/bluetooth/low_energy/low_energy_src.mk'. Stop.
Any ideas of what to try?
Re Please refer to the solution in thread Crash/reboot when calling wiced_dct_read_lock() I have not been able to debug after that solution either, but I have not confirmed its the same issue - I will attempt to do that ASAP and see if that solution solved that particular problem.