[BUG] CoRoutine tick overflow

[bffr05]

If Tick overflows, coroutine stop working

corrected routine.c in repo https://github.com/bffr05/FreeRTOS-Kernel

Cheers

[kstribrnAmzn]

Why do you need the constant 2147483647?

[bffr05]

half a unsigned long 0x7FFFFFFF, I use limits in cpp , but this is the simplest way in C, maybe ((portTickType)-1)/2 would be more elegant for sure

[kstribrnAmzn]

Ah...that's what I was afraid of. FreeRTOS currently supports 16-bit and 32-bit native systems so I don't believe hardcoding the numerical value will work.

[kstribrnAmzn]

Also - can you provide details on what case fails. Looking at the code, it looks like overflow is gracefully handled.

For example, lets say that we're on a 32 bit system and that xCoRoutineTickCount == 4294967295 (aka unint32_MAX) and xTicksToDelay == 5. With the current code then xTimeToWake would be calculated to be 4. Now when we get to this line the condition would be true as xTimeToWake is indeed less than xCoRoutineTickCount which would place the coroutine on the delayed+overflow list.

This is the correct, expected behavior.

[kstribrnAmzn]

As for the later check that you also modified, the current code looks correct. The xCoRoutineTickCount will be less than the first coroutine item in the list when overflow hasn't occurred AND a task hasn't completed it's delay.

Imagine your xCoRoutineTickCount == 100 and at this tick count a coroutine delays for 150 ticks. then the coroutine will be added to the list with the wakeup time of 250. This is the tick count where the coroutine becomes unblocked. When xCoRoutineTickCount becomes 250 or greater then the statement is false and the coroutine will become unblocked.

In the case of an overflow, say xCoRoutineTickCount == 4294967295 then delaying for 150 ticks will result in a wakeup time of 149. This check of xCoRoutineTickCount being less than the first coroutine in the list will ONLY happen after the tick count has overflowed and the delay+overflow list has replaced the delay list.