• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 40 subscribers
  • Views 341 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.

CC3220SF: Race condition gathering SL_WLAN_GENERAL_PARAM_EXT_CONNECTION_INFO after SL_NETAPP_EVENT_IPV4_ACQUIRED event triggered

Ben Schoeler
Intellectual 770 points
Part Number: CC3220SF


Hi support,

Our device is attempting to figure out what LSI to request based on the AP settings provided by a call to

    // Will only return valid info when STA is connected to AP
    SlWlanExtConnectionInfo_t ExtConnectionInfo;
    _u16   config_opt = SL_WLAN_GENERAL_PARAM_EXT_CONNECTION_INFO;
    _u16   Len = sizeof(SlWlanExtConnectionInfo_t);
    uint16_t sl_ret_val =  sl_WlanGet(SL_WLAN_CFG_GENERAL_PARAM_ID, &config_opt, &Len, (_u8 * )&ExtConnectionInfo);
    assert (sl_ret_val == 0);

The sl_WlanGet function is returning 0 even though the data is not yet updated.  We have an AP that it set to have a DTIM of 2, yet it is returning a ExtConnectionInfo.DTIMPeriod of 1 sometimes.  It doesn't happen every time.  Maybe 20% of the time, it is returning a DTIMPeriod of 1 instead of 2.

We tried gating this call after SL_NETAPP_EVENT_IPV4_ACQUIRED, and after SL_WLAN_EVENT_CONNECT, but the same behavior results.  

When is it OK to make the call to grab this data?  Should we be adding in some delay after one of these events above?

Thanks!

  • 0
    TI__Mastermind 38980 points

    Hi Ben,

    The DTIM interval would be updated after you receive the first beacon from the AP. If you delay about a second after the SL_NETAPP_EVENT_IPV4_ACQUIRED event, the data should be valid by then.

    Best regards,

    Sarah

  • 0 in reply to Sarah P
    Intellectual 770 points

    Hi Sara,

    Thanks for confirming that.   Is this a bug?  Shouldn't the function call return some error or status indicating the the DTIM and Beacon Interval are not yet acquired from the AP?

    Ben

  • 0 in reply to Ben Schoeler
    TI__Mastermind 38980 points

    Hi Ben,

    The DTIMPeriod is returning the last-known or default parameter. This is a recently-added feature in SDK 3.10, and at the time there was not a requirement to verify for the latest AP and report back to the host. But that is a valid case. I'll open a request internally, and we can consider it for future releases.

    In the meantime, are you seeing the results you expect with the delay workaround?

    Best regards,

    Sarah

  • 0 in reply to Sarah P
    Intellectual 770 points

    Hi Sara, 

    Yes, an additional second appears to help us get a valid DTIM from the AP. 

    To further illustrate our use case, maybe some more information would be helpful.

    The power budget for our device requires that the CC32 LSI is at least .5 seconds.  Requesting an LSI of 500 ms, however, with an AP with a DTIM of 3 and Default Beacon intervals of 102.4 ms will result an an actual LSI of 307.2 ms.  In this case, we would actually want the LSI to be 614.4 ms.  By looking at the DTIM and Beacon Interval values, we can make the determination to request a longer LSI.

    We would simply expect that when the cc32 gets a new AP connectevent, the sl_Get* call would return the new AP's DTIM info, or a status that it has not yet populated that new info.

    Thanks,

    Ben