[En-Nut-Discussion] timer problem in NutOS

[PragmaLab]

Hello all,

we have this weird problem with timercallbacks in NutOS (currently using the
4.3.3 beta but the problem is also in 4.2.1).

A typical sequence causes our main-thread, in which we kick the watchdog, to
stop running. Debugging the code with an ICE50 into detail reveals the
following scenario:

- from the main thread a 100 msec NutTimer is created, provided with a
callbackfunction (NutTimerCreate)

- while the Idle-thread is executing, the expiration of the timer is noticed
(NutTimerProcessElapsed) and the callback-function is called
            if (tn->tn_callback)
            {
                (*tn->tn_callback) (tn, (void *) tn->tn_arg);	// call
callbackfunction
            }

- this callbackfunction does a call to NutPostEvent, and this causes a
threadswitch to the thread that was waiting for the event (menu)

- so Idle-thread is suspended

- and the menu thread starts running now

- menu thread stops the 100 msec NutTimer (indeed was already expired but
not stopped yet)

- some actions later, the Idle-thread becomes active again (no other tread
was ready to run)

- it resumes right after his last action, which was calling the
callback-function (NutTimerProcessElapsed)
            if ((tn->tn_ticks_left = tn->tn_ticks) == 0)
            {
                NutTimerStop(tn);		// kill timer
            }

- this means it will stop the timer of which the callback function was
called, but this timer was allready stopped by the application...

So NutOS will stop a timer that was allready stopped by the application. The
worst part is, that after stopping the timer means that it is available
again when a new timer is asked for. In our case, the main-thread does a
NutSleep(100) forever and indeed the timer that was stopped is assigned to
the main-thread some moments later. Then when the Idle-thread is resumed and
stops 'his' timer, in fact he is killing the timer of NutSleep(100) of the
mainthread. So the mainthread is never serviced again, so the watchdog is
not kicked, so.....

This behaviour is 100% reproducable and with the trace-function of the ICE50
you see it happen before your eyes, just by examaning the trace. 
How come other people do not suffer from this behaviour? Is it a bug
(design-error, because while killing a timer, you cannot tell it is allready
killed), or do we use timers in an unusual/wrong way? The application is
allowed to kill a timer that it had started, no matter if the timer was
expired or still running, right?

Thanks,

best regards,

Rob van Lieshout




--------------------[PragmaLab]--------
Loonse Molenstraat 23
5175 PS  Loon op Zand
info at pragmalab.nl
www.pragmalab.nl
telefoon: 0416-362548 of 06-15658737
---------------------------------------