I'm working with LPC2478 micro with RTX and I noticed a strange behaviour on delay associated to a task during execution.
Sometimes, in a unpredictable way, a task that should start every 1 second defined as follow:
__task void Background_1sTask (void) { os_itv_set (100);
while (1) { os_itv_wait (); //TASK A ITV {
stop working, so if a put a breakpoint inside this task the code never stop inside it. In this blocked condition if I'm in a debug mode, checking the "RTX Tasks and System" windows I noticed that the delay column related to this task shows a very big strange value, for example 28520 when should be a value lower than 100 because with a system timer set to 10msec, 100 is the maximum delay expected in a 1 second scheduled task.
My application is made up of 6 - 7 task that running in the same time so could be related to a wrong priority managin or could be a wrong acces to the RAM memory where this delay is stored that overwrite it. I don't have other ideas.
Thanks in advance for any suggestion.
BR
The user manual of RTX says clearly:
"You cannot mix the wait method os_itv_wait and os_dly_wait (or any other wait with a timeout) in the same task. RL-RTX maintains only one timer per task. It is used either for interval or delay waits."
http://www.keil.com/support/man/docs/rlarm/rlarm_os_itv_wait.htm
So I don't think it is a very good solution. You should probably construct your program differently.
Hi Tamir, thanks for the hint. Actually I read that line some time ago but remembered only not to mix os_itv_wait() with os_dly_wait()... But now reading it again the quote from the manual implies: "You can NOT use mutexes or mailboxes in Tasks with strict periodic invocation!"
Please correct me if I am mistaken.
Thomas