Re: OS freeze when using debug kernel with CPU Watcher
Posted: Wed Jun 18, 2014 10:04 pm
zzd10h: As I suggested to you previously, looking the error log above and comparing to the asm code generated, I think the error comes from the call to GetSysTime() in the my_launch() function run by the idler task. My assumption would be that the ITimer interface is still uninitialized at that time (and I'm not sure if it can be shared with the main task).
I suspected that the idler starts before receiving the signal from the main task, even if the code that synchronizes seems to be good.
Huum, looking again just now to the code, "me->tc_Launch = my_launch;" is executed before the wait for the timer initialization in the main task. So, if the idler task is descheduled just after "me->tc_Launch = my_launch;" and comes back before ITimer is initialized in the main task, my_launch() is called and ... boom!
This can happen even more probably that the priority of the idler task is decreased afterwards (and not at the task creation).
Instead of adding the Delay() call, you should inialize the timer interface before creating the idler task.
I suppose the error can be highlighted by changing the rythm (set a high debuglevel and activating munge option) and can have an effect only on some platforms (I failed to reproduce on the MicroAOne and the Sam440).
I suspected that the idler starts before receiving the signal from the main task, even if the code that synchronizes seems to be good.
Huum, looking again just now to the code, "me->tc_Launch = my_launch;" is executed before the wait for the timer initialization in the main task. So, if the idler task is descheduled just after "me->tc_Launch = my_launch;" and comes back before ITimer is initialized in the main task, my_launch() is called and ... boom!
This can happen even more probably that the priority of the idler task is decreased afterwards (and not at the task creation).
Instead of adding the Delay() call, you should inialize the timer interface before creating the idler task.
I suppose the error can be highlighted by changing the rythm (set a high debuglevel and activating munge option) and can have an effect only on some platforms (I failed to reproduce on the MicroAOne and the Sam440).
