NU_Sleep puts the current task (suppose task 1) into suspend state for specified ticks. After the completion of this period the task 1 gets ready again but it does not guarantee that task 1 will get executed right after the suspension period. Because there can be some high priority task or same priority task with longer time slice will be holding the cpu when the task 1 gets ready. So the task 1 will wait for the completion of the high priority task.
So this might be the reason in your case that NU_Retrieve_Clock returns increased. The correct implementation of this loop is to declare timeLeft as signed variable.
Thanks Oman. We agree that that is a fix, but the problem is that we are trying to figure out why this extra sleep tick occurs on only one of the three different platforms that we are running the identical software on. We do know that that processor runs about 50% slower than the other two, but we can't figure out how this can happen. Is there anyway that the NU system clock can increment, but the task sleeps an extra tick if it is the highest priority task running? We are monitoring the IRQs, and sometimes the system clock preempts another IRQ when this happens, can this prevent the task from running or decrementing its sleep counter?
Task is resumed from Timer Hisr after expiration of timer. You can check the Timer tick value at this point and investigate where the extra tick is consumes, either before resuming the task of after it. Here is the path to resume the task.
TMC_Timer_HISR -> TMC_Timer_Expiration -> TCC_Task_Timeout -> TCC_Resume_Task
TMD_System_Clock can be compared in TCC_Task_Timeout when it calls TCC_Resume_Task. If it is exactly same when task should resume then you can see where control goes after resuming the task.