[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