• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 536 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.

CCS/LAUNCHXL-CC1310: Task_sleep either blocks forever or longer than specified

You Wen
Prodigy 70 points
Part Number: LAUNCHXL-CC1310

Tool/software: Code Composer Studio

I created 2 threads, one which polls a sensor and another which is a Simplelink RF thread to transmit this data. Whenever the rfThread calls Task_sleep when sensorThread is also calling it, Task_sleep just blocks either very long or longer than specified (in which it eventually returns but took much longer).

When I remove all instance of Task_sleep in the sensorThread, rfThread works just fine. I saw some online solutions about checking stack usage using ROV, I confirmed there is enough stack allocation. I initiated the threads using Pthread. Any suggestions on how to debug this?

  • 0
    Prodigy 70 points

    Seems like Task_sleep() is passed a very huge value to sleep on, and it seems to happen at random times. What I am actually calling is just this:

    Task_sleep(1 * 1000 * 1000 / Clock_tickPeriod);

  • 0 in reply to You Wen
    Prodigy 70 points

    Switching to a semaphore with timeout yields the same issue, waiting on a large number of clock ticks.

  • 0 in reply to You Wen
    TI__Guru 56590 points

    Hello You,

    Your SensorThread Task stack ha overflowed. Then all bets are of and your program may crash in any catastrophic way.  Increase task stack size and try again.

    taskParams.stackSize = 2048; // or more. You need to profile and stress test what max will be.

  • 0 in reply to Eirik V
    Prodigy 70 points

    Hi Eirik,

    Thanks for your suggestion.

    Is referring to the stackPeak column (see first post) not enough? I set stackSize to be well above stackPeak, and therefore I assumed the problem is not caused by stack overflow. I will still try out your suggestion and try to profile it. 

    As a workaround, I used clock_nanosleep instead and so far it worked fine. If it is due to stack overflow, does it means Task_sleep is a much heavier call than clock_nanosleep?