I have an application where I have enabled TX_ENABLE_STACK_CHECKING. The application gets stuck in a do loop in the tx_thread_stack_analyze.c between lines 114 and 135. (H7.3.1.0) It is clear in the debugger that the loop will never complete. The loop is checking for the stack fill pattern 0xefefefef using a binary search after checking the pointer are not NULL. Here is the code:
/* We need to binary search the remaining stack for missing 0xEFEFEFEF 32-bit data pattern.
This is a best effort algorithm to find the highest stack usage. */
do
{
/* Calculate the size again. */
size = (ULONG) (TX_ULONG_POINTER_DIF(stack_highest, stack_lowest))/((ULONG) 2);
stack_ptr = TX_ULONG_POINTER_ADD(stack_lowest, size);
/* Determine if the pattern is still there. */
if (*stack_ptr != TX_STACK_FILL)
{
/* Update the stack highest, since we need to look in the upper half now. */
stack_highest = stack_ptr;
}
else
{
/* Update the stack lowest, since we need to look in the lower half now. */
stack_lowest = stack_ptr;
}
} while(size > ((ULONG) 1));
At the start of the application, everything works fine. After all the threads have been instantiated, and the application goes into idle mode waiting for commands from either the web server or the debug port a command is sent over the debug port to report on the status of some variables. This kicks off the debug thread which causes a stack check to occur. When the stack check process starts (code listed above) the end stack pointer is less than the start. This means, that the code above will never converge and endlessly loop.
the ThreadX List window shows the Debug thread stack as starting at 0z240285fc and the end at 0x240289f7 but when I break point the stack check, so I can see what the entry values are, the stack_lowest is 0x240285fc as expected but the stack_highest is 0x2402859c. Should that not be the end as indicated in the is Thread List?
Is this a bug?
