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/CC3220: Pause execution during device startup

Genius 3100 points

Part Number: CC3220

Tool/software: TI-RTOS

Team,

In my application, the boot sequence is first sl_Task is created, next the provisioning thread (similar to the provisioning example) and then other application threads like sntp, ota, mqtt etc.

I am facing intermittent issues where my application threads starts before sl_Task (device boot up) is complete. Giving few seconds sleep seems to solve the issue, however I don't find that as a good solution. Are there any ways by which I can pause the sequence by checking the device status ? If yes, can someone share the code snippet ?

My SDK version is 2.20.00.10

Regards,

Zac

  • Hi Zac,

    Can you describe a bit more the type of failure you are seeing intermittently and why you believe it is happening?

    The sl_Task thread should be created (and ready to run) before the other threads, but the other threads should not need to wait on it before doing anything. It sounds like you are already doing this, so I think more details on the issue will help us guide you on how to fix it.

    If you are having an issue where sl_Task is blocked by other threads and that is preventing the network processor start operation from returning properly, I recommend raising the priority of sl_Task or making sure all other threads are blocked from calling the SimpleLink host driver API until sl_Start returns. That can be achieved by manually tracking the device state (started/not started) in a common control block or using a semaphore to synchronize (and block) threads until the start operation is completed.

    Best,
    Ben M
  • Hi Ben,
    I find it difficult to recreate the issue on my LaunchPad. From what I remember, the issue was there was a call to the SimpleLink host driver AP (in one of my application thread) before sl_Task thread is done. My sl_Task thread is given the priority as 9 and other threads have values less than zero, so a thread blocking may not be the reason.I may need is to track my device status and if started, should continue creating other threads. Would you let me know the correct command to track the device started status ?

    Regards,
    Zac
  • Hi Zac,

    Ok, thanks for describing it a bit more. There are multiple possible solutions to this problem.

    For a simple demo, you can easily follow the approach of our out_of_box application. It spawns the sl_Task thread, then makes a blocking call to sl_Start() prior to spawning the remaining threads. Another option would be to block the remaining threads on a semaphore until the sl_Start() call succeeds in another thread.

    What I recommend for a more complete application is to have a global status variable keep track of the state. When sl_Start() returns successfully in that thread, you should set a bit in the variable to indicate that the network processor is started and other API calls can be made. Whenever you call sl_Stop(), you can clear the bit. Then you can check the bit before any sections of code in the rest of the application where SimpleLink calls are made. Technically there is a global variable called g_SlDeviceStatus that exists as part of the host driver to keep track of the device state, but you should create your own status variable that can be accessed by your application threads to check the state.

    In general, the implementation is up to you and how decide to maintain state across different parts of your application / how you want to perform error handling.

    Best,
    Ben M
  • Hi Ben,
    Invoking sl_Start(0, 0, 0) after creating sl_Task thread was throwing error sl_Start Failed. Can I call sl_Start() more than once. I believe it was called in another thread.

    Regards,
    Zac
  • Hi Zac,

    If you call sl_Start() after the device is already started, it will return an error. To avoid conflict, try keeping track of when the device is started with a status variable and don't call it again when set.

    Best,
    Ben M