Ready Task is not Entered

[MichaelDavid]

I use few tasks with the same priority. I have 2 almost identical tasks that transmits to the UART1 and UART3 ( Task per UART channel) the 2 tasks starts together and after a while one of the tasks stops transmiting. when stoping the run (in debug mode) the task state is Ready (in the MQX Task Summary) . while other tasks with the same priority work fine.

here is the task list:

TASK_TEMPLATE_STRUCT MQX_template_list[] = { /*  Task number, Entry point, Stack, Pri, String, Auto? */ {MAIN_TASK,       Main_task,                2000, 12,   "Main", MQX_AUTO_START_TASK }, {MANAGER_TASK, Mngr_ManagerTask,  2000, 11,  "Manager", 0 }, {AGENT_TASK,  Agnt_Task,    2000, 11, "Agent",  0 }, {SEND1_TASK,  Mngr_Send1Task,  2000, 10,  "Send1",  0 }, {SEND3_TASK,  Mngr_Send3Task,  2000, 10,  "Send3",  0 }, {CYCLIC_TASK1, Mngr_CyclicTask1,  2000, 11,  "Cyclic1",  0      }, {CYCLIC_TASK3, Mngr_CyclicTask3,  2000, 11,  "Cyclic3",  0 }, {NULL_TASK,         0,             0,      0,    0,      0,   }};

here is problematic task:

void Mngr_CyclicTask3(uint_32 initial_data){ uint_8 m_commBuf[UART_HANDLE],m_length,index; _time_delay(500); // send message to UART3 index = params.Uart3Handle; GET_HANDLE_PARAMS; while(1) {                //wait for the writing procedure   _lwsem_wait(&uart.Write3_SEM);                //send buffer  Mngr_Write3(m_commBuf,m_length);                // signal writing procedure  if (!_lwsem_poll(&uart.TX3_SEM))       _lwsem_post(&uart.TX3_SEM);                // wait for answer  _lwsem_wait_ticks(&uart.Read3_SEM,50);                // free resource  _lwsem_post(&uart.Write3_SEM);    _time_delay(100); }}

Please Advise,

Michael David.

[MichaelDavid]

It seems that the task stops working when it try's to work with another task in the same time. I'm working on K60 Kinetis with MQX 3.7 CW 10.1.

[MarkP_]

Hi Michael,

Does the stop problem still occur if you change all tasks to different/unique priorities?

I always use different priorities, because time slicing may generate problems with variable task execution.

~Mark

[MichaelDavid]

Hi Mark, I've tried to change the priorities but the problem stays.

Michael David.

[MarkP_]

How to other task handles the TX3_SEM?

There is possible double post below:

// signal writing procedure
if (!_lwsem_poll(&uart.TX3_SEM))
{
   << Sema not available now. If context switch occurs at this point and >>
   << other task posts a sema. The post below is doing the 2nd post, shouldn't >>
    _lwsem_post(&uart.TX3_SEM);
}
~Mark

[MichaelDavid]

Hi Mike

You are right. I've changed it in my code after sending the case to these lines:

if (!uart.TX3_SEM.VALUE)  _lwsem_post(&uart.TX3_SEM);

 but still It doesn't work ...

~Michael David.

[MichaelDavid]

Another strange phenomena is that sometimes a Task is blocked by a semaphore. But it doesn't appear as waiting in the list of Light Weight semaphores: 

As you can see in the attachments; there are only 4 semaphores that tasks are waiting for (taskerr2.jpg), but in the task list 5 tasks are blocked by semaphores. (taskerr1.jpg)

In this case the task Send1 doesn't appear in the semaphores list as a waiting task, thus, it is stucked and does not recover...

[MarkP_]

Hi,

the same problem exist also in this:

if (!uart.TX3_SEM.VALUE)
  _lwsem_post(&uart.TX3_SEM);

The semaphore is posted or not , depends on timing of the other task, i.e. has it posted or not.

Note that the other task may run and change sema state after sema test and before sema post.

Could the problem be a pure deadlock?

E.g. two tasks reserves two semaphores in reverse order:

Task1: reserve(1)

Task2: reserve(2)

Task1: trying to reserve(2), blocked

Task2: trying to reserve(1), blocked and deadlock.

Could you post the code of SendTask and others if they handles the same semaphores.

~Mark

[MichaelDavid]

Hi Mark ,

1. About the if before posting, the situation you describe shouldn't occur because all tasks have same priority.

2. If the problem is deadlock , I should see it in the MQX LightWeight sem Tab,/MQX Task Summery Tab, and not that the stuck Task is in ready state!

3. Another phenomena is that blocked task are blocked although the blocking semaphore is set.( so I can't find what's blocking the task). The opposite phenomena also happens (more rarely) , that Task waiting for semaphore is passing wait  also the semaphore is cleared (then the system go wild)  

here is send3 Task:

void Mngr_Send3Task(uint_32 initial_data){  _mqx_uint result;   for(;;)  {    result = _lwsem_wait(&uart.TX3_SEM);    _task_stop_preemption();    Uart_Write(UART3_BASE_PTR, m_send3.buf, m_send3.length);    _task_start_preemption();      // wait for answer    result = _lwsem_wait_ticks(&uart.RX3_SEM, 50);    if (result != MQX_OK)    {      // timeout error      params.HandleErrors[params.Uart3Handle] |= HandleComError;      m_msg3.busy = 0;      //enable next write      if (!uart.Read3_SEM.VALUE)       _lwsem_post(&uart.Read3_SEM);      continue;    }    // parse message    if(!Mngr_Parser3(m_msg3.buf,m_msg3.length,params.Uart3Handle))                  {      params.HandleErrors[params.Uart3Handle] |= HandleComError;    }    else      params.HandleErrors[params.Uart3Handle] &= ~HandleComError;    m_msg3.busy = 0;    //enable next write    if (!uart.Read3_SEM.VALUE)    {       _lwsem_post(&uart.Read3_SEM);    }  } }

 Thanks for the Help,

`Michael David.

[MarkP_]

Hi,
Couldn't follow easily all semaphore actions, probably they are OK.
Few hints:
1)If the system goes wild, there might be a bug.
 Some indexing problem or concurrent buffer usage?

2)Is the uart in blocking mode?
How this _task_stop_preemption() affects if the task is suspended?
Suspends task when output queue is full:
serl_int.c:
=>    if(flags & IO_SERIAL_NON_BLOCKING) {
          if (_CHARQ_SIZE(in_queue) == 0) {
              num -= i;
              _int_enable();
              break;
          } /* Endif */
      } else {
          while (_CHARQ_SIZE(in_queue) == 0) {
=>           _taskq_suspend(int_io_dev_ptr->IN_WAITING_TASKS);
          } /* Endwhile */  
      } /* Endif */

Have you increased the output buffer size, e.g.:
#define BSPCFG_SCI3_QUEUE_SIZE 256 /* sci3=ittyd */

3)What is the size of commBuf?
 uint_8 m_commBuf[UART_HANDLE],m_length,index;
It is allocated in Mngr_CyclicTask3 stack.

4)Can you see the task stacks (where the task execution is) when the halt has occurred?
At my project I only see the active task, others lies delay:
Thread [ID: 0x10003] (Suspended: Signal 'Process Suspended' received. Description: Process Suspended.)    
3 DummyFn1() C:..\Freescale MQX 3.7\mqx\source\psp\cortex\dispatch.s:100 0x00000450    
2 _time_delay_internal() C:..\Freescale MQX 3.7\mqx\source\kernel\ti_deli.c:103 0x0000dcd0    
1 _bsp_exit_handler() C:..\Freescale MQX 3.7\mqx\source\bsp\twrk60n512\init_bsp.c:251 0x00000000    

One way to debug task states is to add global variables into tasks
and inspect those values.
Example:
task_1_state=1;
   result = _lwsem_wait(&uart.TX3_SEM);
task_1_state=2;
    _task_stop_preemption();
task_1_state=3;
    Uart_Write(UART3_BASE_PTR, m_send3.buf, m_send3.length);
task_1_state=4;
    _task_start_preemption();
        
    // wait for answer
    result = _lwsem_wait_ticks(&uart.RX3_SEM, 50);
    if (result != MQX_OK)

~Mark

[MichaelDavid]

Hi,

1. I'm searching that also.

2. The UART is not in blocking mode. Other task can transmit from same channel.

3. Each task has it's own commBuf (20 byte size) local array.

4. The system is not halted, I can see in the scope that the cyclic task is not transmitting and then I stop the program to see the Tasks state. 

4b. We have done this kind of testing, and the result was that the task was blocked before an open semaphore.

5. We also saw a more rare situation where the system is going wild , as I noted before, in this case the task is passing

even if the wait for semaphore should be blocked. 

6. I have seen that a bug was found in the MQX scheduler may it be connected to my issue?

Thanks,

~Michael David.

[MarkP_]

Hi,
Your problem: "task is passing even if the wait for semaphore should be blocked."
This might be a result that sema has been posted twice, as I mentioned.

This should be made somehow in a different way:
  if (!uart.Read3_SEM.VALUE)
  {
    << If other task posts a sema at this time instant,  >>
    << the sema counter is two instead of one            >>
    _lwsem_post(&uart.Read3_SEM);
  }

How have you declared schemas in uart-structure?
  With LWSEM_STRUCT, not LWSEM_STRUCT_PTR

You could try to test the MQX schedule fix by replacing the content of
_set_pend_sv in PSP_cortex:dispatch.s
https://community.freescale.com/thread/96384
(and compiling psp)

Have you made changes to bsp or psp? Clean and (re)build them.
(Noticed that clean helps sometimes to mysteries)
~Mark

[MichaelDavid · Accepted solution]

The problem was when I defined my interrupt priorities to be 3 than might have interfered the MQX kernal. changing it to 10 solved the problem.