• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 42 subscribers
  • Views 753 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

determine if simplelink is running

Iain McDonald
Intellectual 625 points

With extensive testing we've determined that if sl_Stop is called while the nwp isn't running, it fails. We've also learned that sl_Start, if called while the nwp is already running, causes a memory leak (semaphores, etc call malloc). Is there an API call which will tell us if the simplelink is currently running, so we can protect calls to start/stop?

  • 0
    TI__Mastermind 26155 points
    Hi Iain,

    We don't have any API to check the if the simplelink is running or not.
    Can you please share the return value you are getting when calling the sl_Stop() while the NWP isn't running?
    You can call the sl_Stop() with 0 timeout value and do a sl_Start() to start the NWP. Calling sl_Stop() with 0 timeout shouldn't return any error.

    We will review the memory leak on subsequent call of sl_Start() and get back.

    Regards,
    Ankur
  • 0 in reply to Ankur Baranwal
    Intellectual 625 points

    So, apparently the forum is broken and I can't post a link to TI's own forum. If you check my profile, my last post before this one on rebooting addresses the sl_Stop issue.

    The sl_Start should be easy enough to replicate. We found it while trying to retry wifi connection (including sl_Start) with incorrect wifi credentials. The code in sl_Start looks like it's supposed to be able to handle being called when it's already running. After a dozen or so calls, depending on how much RAM was already in use, we end up in vApplicationMallocFailedHook().

  • 0 in reply to Iain McDonald
    TI__Mastermind 26155 points
    Hi Iain,

    The sl_Start() shouldn't be call subsequently without calling the sl_Stop(). This is a limitation of the host driver. We have already added this as warning for sl_Start() API in the host driver API document.
    http://software-dl.ti.com/ecs/cc31xx/APIs/public/cc32xx_simplelink/latest/html/index.html

    As I mentioned in earlier post sl_Stop(0) with 0 timeout shouldn't return error even if NWP is not initialized. Did you get a chance to test this?

    Regards,
    Ankur
  • 0 in reply to Ankur Baranwal
    TI__Mastermind 26155 points
    Hi Iain,

    I hope you query is answered. I am closing this thread, please open a new thread for follow up queries and add a link to this one to help in tracking.

    Regards,
    ANkur
  • 0 in reply to Ankur Baranwal
    Intellectual 625 points
    Why would you close the thread? It's a forum, not a support ticket, and I or others may have more to add later.
  • 0 in reply to Iain McDonald
    TI__Mastermind 26155 points
    Iain,

    We close the thread to help users to identify the solution for a topic discussed on the thread. Users are welcomed to add more solutions on the thread but its always encouraged to open a new thread for new topic.

    Regards,
    Ankur
  • 0 in reply to Ankur Baranwal
    Intellectual 320 points

    Your solution to call sl_Stop(0) first, does not solve the problem. If sl_Stop(0) gets called before sl_Start has been called, the system throws me into the FaultISR.

  • 0 in reply to JohnB
    Guru 73255 points
    Hi,

    Yes that is right. When you call sl_Stop() before was called sl_Start() it cause issue. Call sl_Stop() will try destroy synchronisation object which is not available.

    Solution is really simple. Just have global variable which you set after successful sl_Start(). And when is this variable not set you cannot call sl_Stop().

    Jan
  • 0 in reply to Jan D
    Intellectual 320 points
    This solution still is not complete. I currently have such a variable to guard my sl_Start & sl_Stop calls, but there are some error cases where the application processor may reset without resetting the NWP. In this case, the global variable gets reset and no longer guards the app from calling sl_Start, which causes an error because the NWP is still running.

    Fortunately these cases are rare, however this is still risky behavior.
  • 0 in reply to JohnB
    Guru 73255 points

    Hi,

    I think this is not a problem.

    1. I am almost sure, that is not problem call sl_Start() after startup of you code if NWP is still enabled.
    2. But if you think that this is still issue, use SimpleLink library without enabled macro DISABLE_DEBUGGER_RECONNECT (see e2e.ti.com/.../1806610 ).

    Edit: I check first point and it works without any issue. Now I am 100% that this is not problem.

    Jan