Occasionally I have been having a task stop and decline ever to run again.
It's a ticker task, intended to run every system tick, so the call is:
This runs fine usually for some hours, then the tasks stops being scheduled.
What seems to be happening, is that the timeout for the task (e.g., t->timeout) gets set to the current time, then 'immediately'(*) changed either to 0x7fffffff at startup, or to some number like 0x80001234 later.
(*) Immediately whilst I'm single-stepping through ctl_timeout_wait() at the very next instruction (C or asm), rather as though there's an interrupt, even though we're sandwiched between disable/enable.
It appears that when the problem occurs, the for() loop in ctl_increment_tick_from_isr() does not reschedule, I think because the:
((long)(t->timeout - ctl_current_time) < 0) indicates not yet expired.
My suspicion is that perhaps one of the lines I see like:
ctl_task_executing->timeout = ctl_current_time-1;// ensure a reschedule occurs
may be implicated, as the value of timeout matches what would happen in that code, though I have yet to prove it.
I'm puzzled that 0x80001234 is negative and 0x7fffffff is positive.
Can you help?
Please sign in to leave a comment.