Hi guys,
I have a strange problem.
In one of my applications I actually use embOS V5.18.0.3.
The device is based on NXP LPC55S28.
The software use a very large amount of OS features like tasks, timers, mutexes, semaphores, event objects, queues.
A bunch of tasks have the same (lowest) priority and the others have increasing priority.
Only one task, which I'll call HP_TASK, has the highest priority.
Focusing on HP_TASK, it's very simple, it does something like this:
Display All
In this system, all the things go well for a while, but at a certain point, that I cannot reproduce sistematically, what's happening is that all the tasks works well but the HP_TASK.
It is blocked at
I've been debugging this situation for a while and one of the think I've done is create a new highest priority task that I'll call HHP_DUMMY_TASK.
HHP_DUMMY_TASK only runs an OS_TASK_Delay:
Well, what I noticed is that now, when the HP_TASK goes in the "strange blocked state", it will remain in that state untill the os schedule the HHP_DUMMY_TASK.
As soon as the HHP_DUMMY_TASK go in OS_TASK_Delay, the OS immediately switch to the HP_TASK, that was READY and with pendant signals, and all go well for an other while, untill the condition returns.
Playing with the HHP_DUMMY_TASK_DELAY and put on the scope a toggling pin, I can view the HP_TASK doesn't schedule for a variable time, but always less then HHP_DUMMY_TASK_DELAY.
In some way, the scheduling of the HHP_DUMMY_TASK recover the system from that situation.
In fact, if I set HHP_DUMMY_TASK_DELAY less then HP_TASK_WAIT_TIME_FOR_SIGNAL I never observe the "strange blocked state" described above.
At the moment I have no idea of what's happening...
Do you have suggestions on what I should observe to deeply understand how and when I do wrong things?
Any help will be very appreciated!
Silvio.
I have a strange problem.
In one of my applications I actually use embOS V5.18.0.3.
The device is based on NXP LPC55S28.
The software use a very large amount of OS features like tasks, timers, mutexes, semaphores, event objects, queues.
A bunch of tasks have the same (lowest) priority and the others have increasing priority.
Only one task, which I'll call HP_TASK, has the highest priority.
Focusing on HP_TASK, it's very simple, it does something like this:
C Source Code
- #define HP_TASK_WAIT_TIME_FOR_SIGNAL (20U)
- typedef enum {
- HP_TASK_SIGNAL_1 = 1<<0,
- HP_TASK_SIGNAL_2 = 1<<1,
- HP_TASK_SIGNAL_3 = 1<<2,
- HP_TASK_SIGNAL_4 = 1<<3
- } HP_TASK_SIGNAL_T;
- #define HP_TASK_SIGNALS_MASK ((HP_TASK_SIGNAL_1) | (HP_TASK_SIGNAL_2) | (HP_TASK_SIGNAL_3))
- volatile OS_TASKEVENT _hp_task_signals;
- static void _elabSignals(OS_TASKEVENT signals) {
- if (signals & HP_TASK_SIGNAL_1) {
- // do some
- }
- if (signals & HP_TASK_SIGNAL_2) {
- // do some
- }
- if (signals & HP_TASK_SIGNAL_3) {
- // do some
- }
- }
- static void _doSomething(void) {
- // do some
- }
- static void _HpTaskRoutine(void) {
- while (1) {
- _hp_task_signals = OS_TASKEVENT_GetSingleTimed(HP_TASK_SIGNALS_MASK, HP_TASK_WAIT_TIME_FOR_SIGNAL);
- if (_hp_task_signals) {
- _elabSignals(_hp_task_signals);
- }
- _doSomething();
- }
- }
In this system, all the things go well for a while, but at a certain point, that I cannot reproduce sistematically, what's happening is that all the tasks works well but the HP_TASK.
It is blocked at
_hp_task_signals = OS_TASKEVENT_GetSingleTimed(HP_TASK_SIGNALS_MASK, 20);, its status is READY, it have pending signals, but don't be scheduled never more.I've been debugging this situation for a while and one of the think I've done is create a new highest priority task that I'll call HHP_DUMMY_TASK.
HHP_DUMMY_TASK only runs an OS_TASK_Delay:
Well, what I noticed is that now, when the HP_TASK goes in the "strange blocked state", it will remain in that state untill the os schedule the HHP_DUMMY_TASK.
As soon as the HHP_DUMMY_TASK go in OS_TASK_Delay, the OS immediately switch to the HP_TASK, that was READY and with pendant signals, and all go well for an other while, untill the condition returns.
Playing with the HHP_DUMMY_TASK_DELAY and put on the scope a toggling pin, I can view the HP_TASK doesn't schedule for a variable time, but always less then HHP_DUMMY_TASK_DELAY.
In some way, the scheduling of the HHP_DUMMY_TASK recover the system from that situation.
In fact, if I set HHP_DUMMY_TASK_DELAY less then HP_TASK_WAIT_TIME_FOR_SIGNAL I never observe the "strange blocked state" described above.
At the moment I have no idea of what's happening...
Do you have suggestions on what I should observe to deeply understand how and when I do wrong things?
Any help will be very appreciated!
Silvio.
Senior HW & FW Developer at INIM Electronics s.r.l. | 
LTE Expert | 
embOS User | 
IoT Addicted | 
Matter Enthusiastic-----
The art of writing firmware: "having a scooter, having to do the same things with it that you could do with a motorbike, with the safety that a tank would guarantee and in the end trying to do it by removing a wheel to optimize costs".