• Resolved

RTOS/LAUNCHXL-CC1310: Task_sleep(1500) never returns?

Part Number: LAUNCHXL-CC1310

Tool/software: TI-RTOS


Today I'm having a problem where my task deadlocks in Task_sleep. I need to wait 15ms for an external chip to complete a measurement, but when I wait using Task_sleep(1500) my task never runs again.

If I check in the ROV, it says it's blocked on Task_sleep, and the callstack clearly shows that it's entered Task_sleep and scheduled another task which runs for a little then pends on a semaphore - however TI-RTOS never resumes my task even though the timeout has long since passed!

Currently,  TI-RTOS has been waiting 15 minutes for a 15ms timeout to expire..

How can I find out why this is happening?

  • In reply to Michael Moon:

    Can you let us know how this experiment goes? If this doesn't work, can you send across a test project so that we can reproduce? You can make a private friend request if you don't want to share your project on this forum.

    One more question ... do you know which compiler version you are using? We have not seen problems with the timer code for several years. The original implementation was complex but it has been well tested and reliable in the field for a long time.


  • In reply to Karl Wechsler:

    I had one node run for the whole weekend which is a first!

    I'll keep an eye on things and report back if I find any more deadlocks that appear to be inside Task_sleep() or Semaphore_pend(... timeout) or related functions, but for now I'm gonna call this tentatively solved since it deadlocked very reliably before.
  • In reply to Michael Moon:

    Thanks for reporting back. This issue is being worked tracked in our bug data base as SYSBIOS-383.

  • In reply to Karl Wechsler:

    Hmm all my DNS servers say no such host for that URI, is that an internal bug tracker?
  • In reply to Michael Moon:

    I just had two nodes run overnight, with the third apparently experiencing a lockup in the XDS probe itself and thus losing UART connectivity. Still very promising for calling this issue solved :)
  • In reply to Michael Moon:

    As a follow-up to close out this thread…

    After a root cause analysis, a precise timing scenario was found where a compare margin value of “4” could be insufficient. But a compare margin value of “6” will avoid the problem.

    The fix for this issue will be tracked with bug ID: SYSBIOS-383 and will be resolved in the upcoming 3.20 TI-RTOS release.

    As a workaround for the time being, you should modify the COMPARE_MARGIN definition in /packages/ti/sysbios/family/arm/cc26xx/Timer.c as below:

    #define COMPARE_MARGIN 6

    And then rebuild your application.
  • In reply to Alan DeMars:

    Well technically the fix also requires a rebuild of TI-RTOS itself and disabling BIOS-in-ROM as well, not just rebuild of the application, but that's certainly the heart of it.
  • In reply to Michael Moon:

    The fix works with BIOS in ROM since the affected API is not in the ROM.

    No need to rebuild TI-RTOS. When the config phase of the application build process is performed, the change to Timer.c will be incorporated in the generated custom sysbios library that the application links with.