rtel wrote on Thursday, January 14, 2016:
I should have asked at the beginning - what do you have configCHECK_FOR_STACK_OVERFLOW set to? Also, how big is the interrupt stack?
[configCHECK_FOR_STACK_OVERFLOW only checks the stack used by tasks, but the stack in use switches to the interrupt stack each time an interrupt is entered. The stack used by interrupts is the same stack as used by main() before the scheduler is started, so it is set up by your tools somewhere)]
From your last post I can infer the tick rate is 1KHz.
Interesting. So we are expecting xItemValue to be approximately 180K, and indeed it is, so appears to have been calculated correctly. Why then, is it in the overflow list? Hmm…thinking. Something is very odd - the code that determines which list to put the task into is very simple:
if( xTimeToWake < xTickCount )
{
/* Wake time has overflowed. Place this item in the overflow list. */
vListInsert( pxOverflowDelayedTaskList, &( pxCurrentTCB->xGenericListItem ) );
}
else
{
/* The wake time has not overflowed, so the current block list is used. */
vListInsert( pxDelayedTaskList, &( pxCurrentTCB->xGenericListItem ) );
…and we can already see that xTimeToWake was calculated correctly, as it is shown in the screen shot.
Normally at this point I would ask for a cut down project, with just enough code to demonstrate the issue, so I could run it here - but in this case I don’t think that is going to be possible as you are using the NTP code.
How about this - could you update your task so the task does not call any of the NTP code, but instead just increments a volatile variable every time it runs. So you keep the structure of the task the same, the bit that calls vTaskDelayUntil() and the bit that calculates the next wake time should remain unchanged, but the bit that calls the NTP code is commented out and replaced with a simple variable increment. Then run the code again. If the problem still exists then we would have something I could try running here.