[En-Nut-Discussion] timer problem

Alain M. alainm at pobox.com
Thu May 8 16:46:28 CEST 2008


Hi Harard and Ole,

This is the third time in a year that I see this problem here...

Could it be fixed in some future release?

Erik, thanks for publishing your workaround, this time :)

Alain

Erik L escreveu:
> PragmaLab wrote:
>> Hello Hansel,
>>
>>> so i see that after the "crash" the timerlist is destroyed and an 
>>> endloss loop inside of  "NutTimerInsert" is working. Only one timer 
>>> exists, instead of my intended three timers, which really 
>>> exists before 
>>> (LED-Output).
>>>
>>> timer1->next = timer1; timer1->prev=timer1;
>>> timer2->next = timer3; timer2->prev= NULL;
>>> timer3->next = timer2; timer3->prev= NULL;
>>>
>>> had anyone a problem with timers in nut-os???
>>
>> I'm not sure if the timer problem we worked around some half year ago is
>> related to yours. I just wanted to mention that we indeed had problems
>> with
>> the timerroutines. What happened was:
>>
>> 1) we resuested a one-shot timer in thread A
>> 2) used another timer in thread B (implicit by calling NutSleep(xxx))
>> 3) manually killed the first one-shot timer while thread A was suspened
>> 4) Noticed that when thread A woke up, it still assumed that the first
>> one-shot timer was there,
>>    killed it when it expired, but in fact was killing the wrong timer (of
>> thread B)
>> 5) so the second timer of thread B never expired anymore, so thread B
>> never
>> woke up, so the watchdog was not kicked, so.....
>>
>> We even purchased an ICE50 to trace down this problem. The problem was
>> 100%
>> reproducable and clearly we could see it happen in the tracebuffer (a
>> feature which is not available with a MKII -debugger). I've posted this
>> issue in this list but never got any reply.
>>
>> First we used NutOS 3.9.6 which did not suffer from this problem because
>> timercallbacks run in interrupt context. We noticed the bug when we
>> started
>> using 4.2.1 (to shorten interrupt latencies, callback functions no longer
>> run in interrupt-context).
>>
>> Our workaround was (and still is) to use our own timeradministration.
>>
>> Hope this helps?
>>
>> Best regards,
>>
>> Rob van Lieshout
>>
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>
>>
> 
> Hi.
> I experienced the exact same problem as you and did wrote my own
> administration.
> 
> And it looks like its working, but perhaps you solved it in a much smarter
> way?
> 
> this is how i did with some simple wraper functions.
> ---
> HANDLE NutTimerStartWithCheck(u_long ms, void (*callback) (HANDLE, void *),
> void *arg, u_char flags, HANDLE timerHandle)
> {
> 	u_char * a;
> 	
> 	a = arg;
> 	if(*a != TIMERSTARTED)
> 	{
> 		*a = TIMERSTARTED;
> 		return NutTimerStartTicks(NutTimerMillisToTicks(ms), callback, arg,
> flags);		
> 	}
> 	else return timerHandle; // Return old handle when trying to start already
> started timer.	
> }
> 
> void NutTimerStopWithCheck(HANDLE tn_handle)
> {
> 	u_char *arg;
> 	NUTTIMERINFO *tn;
> 	tn = tn_handle;
> 	arg = tn->tn_arg;
> 	if(*arg == TIMERSTARTED)
> 	{
> 		*arg = TIMERSTOPPED;
> 		NutTimerStop(tn_handle);
> 	}
> }
> 
> void timer_callback_pressure_adjust_fine_tune(HANDLE tn, void *a)
> {
> 	u_char * arg;
> 	arg = a;
> 	*arg = TIMERSTOPPED;
> ....
> 
> }
> 
> 
> HANDLE timer_pressure_adjust;
> u_char timer_pressure_adjust_status;
> 
> timer_pressure_adjust = NutTimerStartWithCheck(PCU_PRESSURE_ADJUST_TIMER,
> timer_callback_pressure_adjust_fine_tune,  &timer_pressure_adjust_status,
> TM_ONESHOT, timer_pressure_adjust);
> 
> NutTimerStopWithCheck(timer_pressure_adjust);
> 
> ------
> 
> 



More information about the En-Nut-Discussion mailing list