Strange problem hard to debug

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Strange problem hard to debug

      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:

      C Source Code

      1. #define HP_TASK_WAIT_TIME_FOR_SIGNAL (20U)
      2. typedef enum {
      3. HP_TASK_SIGNAL_1 = 1<<0,
      4. HP_TASK_SIGNAL_2 = 1<<1,
      5. HP_TASK_SIGNAL_3 = 1<<2,
      6. HP_TASK_SIGNAL_4 = 1<<3
      7. } HP_TASK_SIGNAL_T;
      8. #define HP_TASK_SIGNALS_MASK ((HP_TASK_SIGNAL_1) | (HP_TASK_SIGNAL_2) | (HP_TASK_SIGNAL_3))
      9. volatile OS_TASKEVENT _hp_task_signals;
      11. static void _elabSignals(OS_TASKEVENT signals) {
      12. if (signals & HP_TASK_SIGNAL_1) {
      13. // do some
      14. }
      15. if (signals & HP_TASK_SIGNAL_2) {
      16. // do some
      17. }
      18. if (signals & HP_TASK_SIGNAL_3) {
      19. // do some
      20. }
      21. }
      23. static void _doSomething(void) {
      24. // do some
      25. }
      27. static void _HpTaskRoutine(void) {
      28. while (1) {
      29. _hp_task_signals = OS_TASKEVENT_GetSingleTimed(HP_TASK_SIGNALS_MASK, HP_TASK_WAIT_TIME_FOR_SIGNAL);
      30. if (_hp_task_signals) {
      31. _elabSignals(_hp_task_signals);
      32. }
      33. _doSomething();
      34. }
      35. }
      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 _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:

      C Source Code

      1. #define HHP_DUMMY_TASK_DELAY (2000U)
      2. static void HHP_DUMMY_TASK(void) {
      3. while(1) {
      4. OS_TASK_Delay(HHP_DUMMY_TASK_DELAY);
      5. }
      6. }

      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.
      :evil: Senior HW & FW Developer at INIM Electronics s.r.l. | 8) LTE Expert | :thumbsup: embOS User | 8o IoT Addicted | :love: 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".

      The post was edited 1 time, last by silvio.vallorani ().

    • Hi Silvio,

      We're not aware of any issues regarding Taskevents in embOS 5.18.0.3.
      OS_TASKEVENT_Set() should immediately switch to the signaled task if that has the highest priority in the application, is not suspended and no critical region was established.
      Since your embOS license should be still in support, please create a Support Ticket and I'm pretty sure we'll be able to solve that issue quickly.

      Best regards,
      Martin
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/
      Or you can contact us via e-mail.