lzgrablic wrote on Wednesday, August 21, 2019:
I’ve run into a problem with uxTaskGetStackHighWaterMark() as well as vTaskGetInfo() both giving an incorrect value for the stack high-water mark sometimes (usually a single-digit number), and then eventually reporting the correct value (a higher value than before). The incorrect value is consistent between the two functions.
I’ve even been able to re-create in GDB by calling uxTaskGetStackHighWaterMark() from there, getting the wrong value, examining the stack, and calling uxTaskGetStackHighWaterMark(), at which point it gave the correct value.
This is on v10.0.1
xz8987f wrote on Thursday, August 22, 2019:
Was the correct value stored in the task descriptor and the caller had received something different, or was the value in the task descriptor wrong too?
Keep in mind that the high water value only gets set at task context switch time, so if your task is consuming more time in-between, that would not be recognized.
lzgrablic wrote on Friday, August 23, 2019:
Where would it be in the task descriptor? According to the code, it just counts it on the stack directly.
Also, the value increased, which should be impossible, since it should give the least stack ever remaining, and the fill byte should never be re-written.
rtel wrote on Friday, August 23, 2019:
It is not in the descriptor, but you can get the address of the stack from the descriptor which will let you view the stack usage in the debugger - you can also just place a break point in the code then step through the function to see exactly how it is arriving at the number it does.
lzgrablic wrote on Thursday, September 05, 2019:
That’s the thing. As soon as I examine the stack or step through the function, it gives the correct value.
aggarg-aws wrote on Thursday, September 05, 2019:
Which hardware platfrom are you using? Is it possible for you to share the project which shows the problem?