• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 4674 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/CC2640R2F: Task functions never called

Matthew Hall
Intellectual 435 points
Part Number: CC2640R2F
Other Parts Discussed in Thread: CC2640

Tool/software: TI-RTOS

I took the simpleBLEPeripheral project from the CC2640R2 SDK and successfully built and ran the project on my device. After this, I imported some application source code from a previous project I had working (on a CC2640). Now, after calling BIOS_start() in my main function, none of the created tasks get run except for the ICall_taskEntry and the Idle task. All other tasks show as "Ready" but never execute (verified via console logging and breakpoints)

What are some reasons that BIOS_start() would not kick off my tasks? I've verified that the task_construct() calls all return without errors.

  • 0
    TI__Mastermind 30830 points
    This may be a task priority issue.
    For a task to run, it must be the highest priority task that is ready to run.
    If another task of higher priority is running all lower priority tasks will not run until the higher priority task blocks.
    What are the priorities of the tasks that are ready but not running?
    What is the configured Task.numPriorities in your .cfg file?
    Is there a chance you've set the priority of a task equal to or greater than Task.numPriorities?

    Alan
  • 0 in reply to Alan DeMars
    Intellectual 435 points

    Here is my current Task layout:

    Task.numPriorities is currently 6

    I'll try bumping the SimpleBLEPeripheral Task priority to 5, but am not confident that will help since the AdcFxn hasn't run and it's currently at the highest priority.

  • 0 in reply to Matthew Hall
    TI__Mastermind 30830 points
    Hmm. It appears that the "ICall_taskEntry" task was the first task to ever run (following BIOS_start()) and has never blocked and allowed any other task to run (not the Idle task either).

    As this is a SimpleBLE example and I know very little about the ICall mechanism, I'm going to move your question to the BLE forum.

    Alan
  • 0 in reply to Alan DeMars
    Intellectual 435 points
    As an experiment, I bumped the max task priorities to 7 and assigned both my simpleBLEperipheral task and adc task to priority level 6. This allows both tasks to run successfully but I've never had to do this in the past with other projects and am not totally satisfied with this. Are there any updates to this issue yet?
  • 0 in reply to Matthew Hall
    Intellectual 435 points

    I'm still waiting for a response from TI on this issue. Specifically, why would ICall_taskEntry not allow any tasks of a lower priority level to ever run?

  • 0 in reply to Matthew Hall
    TI__Mastermind 20480 points
    Matt,

    If you have tasks that you want to register with ICall, you may need to allocate more entities. What's the return value of ICall_registerApp()? Did you increase ICALL_MAX_NUM_ENTITIES and ICALL_MAX_NUM_TASKS in your project configuration?
  • 0 in reply to Tom Kopriva
    Intellectual 435 points
    ICall_registerApp() returns SUCCESS and I currently have ICALL_MAX_NUM_ENTITIES == 3 and ICALL_MAX_NUM_TASKS == 6

    I'm running GAPRole Task, SBP Task, and ADC Task (non ICall)
  • 0 in reply to Matthew Hall
    TI__Mastermind 20480 points
    Matt,

    is there any indication on what your processor is executing in ICall_entryTask? Chances are if you are stuck in a spin loop, that might have been an assert. The software guide has a debugging section that you can refer to if you did get an assert.

    You said that you had code working on the CC2640. Is this a ported project that you created via the porting instructions?

    Tom
  • 0 in reply to Tom Kopriva
    Intellectual 435 points
    Hey Tom,

    Thanks for the pointer. ICall_entryTask does seem to be stuck in a loop, although it's not a for(;;) loop if that's what you're referring to. I'll see if I can determine whether an ASSERT has been hit.

    Yes, this is a ported project created using the porting instructions. The quizzical piece for me is why the Tasks run when I set their priorities higher than the ICall_entryTask but not when they're lower.
  • 0 in reply to Matthew Hall
    Intellectual 435 points
    I don't see the Assert Handler being executed (the function is defined and registered and EXT_HAL_ASSERT is defined in the stack project).

    ICall_taskEntry is stuck in an endless loop of ICall_wait() which is called by some function whose symbols I don't have access to. Is there a way to gain access to a stack trace that shows which Stack Project calls are calling ICall_wait()?
  • 0 in reply to Matthew Hall
    Intellectual 435 points
    This issue (and several others I'm encountering) seem to be related to insufficient heap memory. It would be nice if TI-RTOS was more explicit about why these issues are occurring.