I am developing an application that has 11 Clocks - mixed one shots and periodics. All run fine except for the last one that I've created.
When a certain set of circumstances occur, I need to create a one-second periodic timer with a one-second delay. Frequently, during run-time, when this clock is created, the call back function is never called.
When this happens, I pause execution, and verify that the Clock handle is valid. I then can look at ROV/Clock/Basic and see that the clock exists in the list and that the timeout and period are both 1000. That is good.
However, when I then examine 'tRemaining', it is set to an absurdly large number - eg. 4294482991 or some such huge number.
Additionally, if I continue execution and then pause again, this number has decremented. Just to be clear, this clock is not being created in an Hwi or Swi context.
My question, where is this number being set? It seems to be buried in the bowels of the kernel. I can't seem to find it to set any breakpoints.
Secondly, can anybody provide an explanation as to how this number can get corrupted? All my stacks seem healthy - including the system stack. Heap has plenty of margin as well.
Here is the code snippet of Clock creation:
//if clock does not exist, create one
//if delay is zero don't bother creating clock
if(!cronTMR_Hndl && delay)
{
//create a clock
Clock_Params_init(&cron_clk_Params);
Error_init(&cron_eb);
cron_clk_Params.period = 1000;
cron_clk_Params.startFlag = TRUE;
cronTMR_Hndl = Clock_create(jobs_cb, (unsigned int)1000, &cron_clk_Params, &cron_eb);
if( !cronTMR_Hndl )
WF_LOG(ZONE_CONSOLE, PRIOR_CRITICAL, " >>> Cannot create CRON Timer! <<< \r\n");
}
Clock handle, Params, and error block are all globally scoped.
Any thoughts would be very welcome.
Mark Rush
