We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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
It is possible that you have corrupted the kernel's RAM. Also, if you using a really old MDK (3+ years) there was a timing bug in RTX (fixed).
Thanks for your fast replay. I'm working with MDK 4.23 and I didn't find in the keil site if this revision is older than 3 years. I already tried to update my MDK to one of the last revisions (4.53), but I found a lot of differences, in particular in USB library that I use; after this new installation my main project didn't run as expected so I decide to upgrade it when I'll have more time to test all periphericals.
Can you indicate me which registers or address in RAM that could be corrupted where the time informations related to tasks are stored?
You need to look in RTX's source code, but normally all task stacks are aggregated in a large, common buffer (I forgot its name; I don't use RTX anymore). As somebody that damaged the kernel's RAM image in the past, I'd start by putting tasks in comment. The crash should disappear at some point. You don't have an MPU on the chip so you can't trap the error actually happening. Maybe it is a buffer overrun or a bad pointer. Maybe using a static code analyzer can help, too.
All tasks have dedicated stack area, with a size that allow to have an occupation not more than 30-40%, I used the "RTX Task and System" as reference.
It sounds strange that timing information is inside the stack area that should be dedicated to my temporary variables.
The RTX source code is not available so I can't verify where it saves the delay information. In any case I'll try with some code semplified and understand who writes in a wrong position. About static code analyzer, is there some tool integrated in MDK or you are thinking to something of external?
Thanks for you time.
I am using PC-lint.
Dear stefano & tamir, I recently had a long debugging session for a similar symptom. to sketch the situation: a monitoring task is invoked periodically using itv_set() itv_wait() In case of a abnormal situation data was written to flash which take some time (~100ms), and has to be done without being interrupted. The abnormal situation has to be acknowledged by the user. Now during stress-testing we hit the acknowledgment at high frequency while the abnormal situation persisted. The behavior observed was the task got slowed down, from a expected 10ms interval up to 2s! All other tasks continued working normally. After 1-2s without stressing the system magically recovered and continued execution. My explanation is that the worst-case-execution-time 100ms violates the initial 'hard' deadline assumptions of 10ms task-invocation, RTX somehow 'gets confused', accumulates task invocations but tries to recover. I never had time to deeply invesigate this 'RTX-is-confused' question in the RTX source code.
Since periodic task invocation based on 10 ms was not mission critical we circumvented the problem using os_dly_wait() instead of itv_wait().....
Good luck debugging random-runtime-behavior! Thomas
Dear all, thanks for your intersting considerations. It seems that I solved my strange freezing so I want to share my experience to help other people. My error was to have inserted in a task called periodically with a os_itv_wait method, also the OS function "os_sem_wait" to manage a shared resource. In the previous revison my code had:
if(os_sem_wait(SEM_I2C_1, 100) != OS_R_TMO) { ...
this means that the system tried to wait 100 (system tick) for the I2C is free; this is a lot of time in a so fast task! (in a particular way if this task has an high priority)
my solution has been
if(os_sem_wait(SEM_I2C_1, -1) != OS_R_TMO) {
in this case I have a system very fast that try just once if it can use the i2c resource and if is not possible will try the next cicle whitout using all CPU time for this particular task.
Have a nice day!
Stefano
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