Hello Miro,
We are experiencing with the latest version of QPC (from github) and I think we may have found a bug. The problem happens when you "disarm twice an armed event before another tick happens".
It is easy to reproduce in blinky.c:
After lines 102-103, which arm the event, just add the following:
QTimeEvt_disarm(&me->timeEvt);
QTimeEvt_disarm(&me->timeEvt);
QTimeEvt_armX(&me->timeEvt,
BSP_TICKS_PER_SEC/2, BSP_TICKS_PER_SEC/2);
(so disarming twice and then rearming)
So the disarm function does not remove from the list, on the first call it just set the ctr to 0 and on the second call it sets the refCtr to WAS_DISARMED (by the way, this is never checked anywhere. The function QTimeEvt_wasDisarmed is never referenced anywhere).
So it happens that when arming the event, it is added to the list, but it is already there, thus creating a circular never-ending list that can be seen as the LED blinking really fast.
Similar behavior can be seen on the dpp example, by disarming twice an armed event and then rearming the philo timer.
I think the disarm function sould remove the event from the act list, whenever you disarm it (on the first or second time, maybe?)
Now you may think that disarming twice and armed event may be a stupid thing to do, however, we are using very complex HSM, and it happens on our setup.
What do you think?
Anonymous
Thank you for reporting. Double disarming of a time event was not tested in QP/C, but indeed the wrong flag has been cleared in the [else] branch within QTimer_disarm(). The correct code is as follows:
This problem is not present in QP/C++, because in QP/C++ no flag is cleared or set at the corresponding part of the code. However, in the
TE_WAS_DISARMEDshould be cleared in QP/C++, so the bug fix applies to QP/C++ as well.Finally, regarding the WAS_DISARMED flag, it is checked in the QTimeEvt_wasDisarmed() API. This API is potentially useful for clients to check whether a (one shot) time event was indeed disarmed manually, or perhaps it was disarmed automatically. In the latter case the client code must be prepared to receive the time event, because it is already in the event queue.
--MMS
Last edit: Quantum Leaps 2020-04-03
Fixed in QP/C/C++ 6.8.1.
--MMS