Richard,

I'm doing some debugging and I've put a while (1){};
after where the scheduler starts - my code should never reach it because I don't stop the scheduler - but I'm seeing it reach that point on some of my targets. Is the most likely problem a stack issue?

I've noticed as well in virtually all of your examples you keep task run counters - and then you check the counters periodically for errors. I suppose you recommend doing this with all tasks - correct? I know a task will stop if there are stack issues; - the processor I'm working with will croak usually if anything wrong happens with the stack - I was just wondering if you always recommend keeping track of the task run counters - I do it in my debugger - but I don't usually have a function that does a compare like in your examples.

Thanks,
John

Slightly hurried response ...

In theory you should only reach the while(1) if there is not enough RAM left in the heap for the idle task to be created. The idle task is created when the scheduler is started and the scheduler will not start if it cannot be created.

The counter of the number of tasks is only included as a check for correct operation when the "suicide" tasks are inlucded in the demo. These tasks created and kill themselves over and over so the counter encusres correct operation by ensuring the number of tasks in the system is not growing (indicating that they are not deleting properly).

Regards.

Richard,

My app. runs awhile before I see this. Could the IDLE task run out of stack on a yield? Would
it exit 'gracefully' or would you just see the stack be corrupt - I would think the latter.

Thanks,
John

It would not know and therefore behave unpredictably. Sounds like a crash of some sort.

Yes, it is a crash of some sort.
John