• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 624 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/LAUNCHXL-CC1310: Tasks

Chetana Reddy
Prodigy 175 points
Part Number: LAUNCHXL-CC1310

Tool/software: TI-RTOS

I have four tasks in my code with priorities 1,3,4 and 5. The task with priority 1 has no semaphore while the other 3 tasks have semaphores. This means Task with priority 1 is running continuously until a button is pressed which posts the semaphore for Task with priority 5. I notice that when Task with priority 5 is running (there are a few commands for RF receive and transmit in this task), Task 1 suddenly starts running in between. Why is this happening?
Can a low priority task start running while a high priority task is running?

  • 0
    TI__Guru**** 317180 points
    Normally not. But what does the priority 5 task actually doing when the pri 1 task starts running? When running RF commands it's the CM0 on the chip that does most of the job and the CM3 is only needed when a packet is received and has to be processed or similar on the TX side.
  • 0 in reply to TER
    Prodigy 175 points

    Hello, priority 5 task remains blocked till semaphore is posted.
    Meanwhile, RF_cmdPropRx is running in priority 1 task.
    Now, semaphore for priority 5 task is posted.
    We enter priority 5 task, post RF_flushcmd to abort the Rx command and then RF_cmdPropTx is posted.


    What I have observed after multiple rounds of debugging is that after I post

    e = RF_runCmd(rfHandle, (RF_Op*)&RF_cmdTx, RF_PriorityNormal, NULL, 0);

    in priority 5 task and after transmission has been completed, the RF_cmdPropRx command that i previously aborted using RF_flushcmd starts running again automatically without me posting a command for it. Due to this, it is going back to Task 1 where the command has been originally posted.
    Is this supposed to happen? i.e. a command aborted using RF_flushCmd starts running again automatically after RF_runCmd for a different operation is posted.

    Is there a better way where I can terminate the Rx command completely and prevent it from starting by itself when RF_runCmd is posted? Using Rx end trigger is not a feasible option for me.

  • 0 in reply to Chetana Reddy
    Expert 2050 points
    Low priority tasks can run when a high priority task pends.

    The TI-RTOS libraries are littered with semaphore pends, so you should expect this to happen a lot unless you explicitly block your threads with your own semaphores.

    I don't know about your RF stuff, but personally I use end trigger on RX to change to TX mode rather than flushing and restarting the radio.