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.
Hello,
I was wondering if any of you uses RTX with a tick rate faster than 10 milliseconds. Franc Urbanc, RTX's author, recommends this setting but I am not sure why - a context switch overhead of a LPC2478 running at 72[MHz] will be about 6 microseconds. However, when we try to set the tick rate to 1 millisecond or 100 microsecond, RTX seems to hang after about 10 minutes (when at 100 microseconds) in this code:
void os_put_prio (P_XCB p_CB, P_TCB p_task) { /* Put task identified with "p_task" into list ordered by priority. */ /* "p_CB" points to head of list; list has always an element at end with */ /* a priority less than "p_task->prio". */ . . . /* Search for an entry in the list */ while (p_CB2 != NULL && prio <= p_CB2->prio) { p_CB = (P_XCB)p_CB2; p_CB2 = p_CB2->p_lnk; }
sometimes, we see only one entry in the linked list whose left and right pointer point to the entry itself, resulting in a system deadlock. Yes, we probably can get away with a tick rate of 10 milliseconds, but I would appreciate your insight anyway.
Thanks. How long are you successfully running your system without reset?
It has been running for about 24 hours.
thanks for the information.
HI.
we r using the str9 @ 96MHz and teh rtx tick is 1ms
won of uor dev board has been running for 37 days continuos and keeps going.
Always yo're freind.
Zeusti.
Can you get this to happen using the simulator?
If so, I would strongly recommend packaging it up and sending it to Keil tech support. If this is an issue in Keil's RTOS, all of us would certainly appreciate having it resolved.
Are you using isr_xx function calls?
How many tasks do you have running?
FYI: I am running a LPC2468, 1ms timer tick, no isr_xx calls, 3 tasks without an issue. (But when I add in isr_xx calls, and / or run at 8+ tasks I start having problems)
-Eric
Eric,
Thanks for your reply. I will certainly try to generate this situation using the simulator (after I finish this post) using my separate test program, that ran with a tick rate of 50 micro for hours today without a problem (no isr_xxx function there, though, but it does have 10 tasks). On the product itself I am using isr_xxx calls, and about 10 tasks (but also only 5, on another controller type). Will report what my findings are.
OK, I managed to run my test program on the simulator at 72[MHz], and call 'isr_evt_set' from a periodic interrupt. Everything seems to working fine, damn it :-) I am going to remove all the calls to this API tomorrow and see what the real target does, as well as run this little rpgram on the real thing. Maybe it dies and we have finally a test case for Franc Urbanc...? But again: I can (and have done so!) write a preemptive scheduler myself to do the task switching. How come that we have som much trouble with these functions. How can we stabilize a product like this? No offense, but I am seriously considering other options. I cannot deliver a product that is not stable. I just can't.
I use a LM3S6965 based board with a tick of 1ms and all is running fine.
Viktor,
Are you using the isr_xxx functions in your product?
Hi,
I alerted Keil Tech Support to this thread. I recommend posting as many details as you can to help them out.
Also, I think heavy usage of the isr_xxx functions may be the key. These queue up events that get dealt with at the next system tick timer. Since you have such a long system tick, maybe your queue is overflowing?
yo'll probably ignore me agin but i give info anyway
14 tasks'. 5 irq's. and fiq. 3 irqs' call isr_xxx funcs.
I just managed to kill RTX with my test program! is there somewhere where I can post this program for others to review? I will of course send it right away to Keil!
this is a public forum, Zeusti. you cannot always expect personal treatment. I have read your comments with interest, however I managed to break RTX. Keil is informed.
Excellent! Good work.
As far as sharing it with the forum: You could upload a zip file of the project to a free service like http://www.getdropbox.com to share it. (If you use getdropbox, upload it to the public folder, and then select the option to create a link to it, copy and paste the link in here).
Eric, all interested people,
See here:
www.getdropbox.com/.../RTX failure
I think I got the sharing issue right. I have made extra experiments with microlib, RTX sources integrated, compiler optimizations etc. - it all boils down to a problem in RTX, _I think_. PLEASE feel free to correct me if there is a mistake in this program, hence it is my fault. I apologize for the not so good looking code. I usually take care of that...:-)
BTW,
using this table instead of the existing one
Using this table in my simple demonstration program will kill RTX within 10 seconds: static task_info_t s_task_info[NUMBER_OF_TASKS] = { {127, task1, 0}, // task1 {127, task2, 0}, // task2 {127, task3, 0}, // task3 {127, task4, 0}, // task3 {127, task5, 0}, // task3 {127, task6, 0}, // task3 {127, task7, 0}, // task3 {240, task8, 0}, // task3 {240, task9, 0}, // task3 {127, task10, 0}, // task3 } ;
Note that I have increased the priority of 2 tasks. This will kill RTX within 10 seconds!