• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 40 subscribers
  • Views 229 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-LAUNCHXL: Reconnection issue

SN
Intellectual 265 points
Part Number: CC3220SF-LAUNCHXL

Hi,

We are using a CC3220MODASF module for our application. We add a profile,set auto and fast connection policies and then start the NWP using sl_Start().

Every 3 seconds, we check if the device is connected and has acquired an IP in order to send data to a server. If the device is not connected or hasn't acquired an IP, we restart the NWP using sl_Stop() and sl_Start(). When the router is restarted a number of times, it sometimes does not give an IP to the device. In such a situation, the device hits configASSERT in freertos and hangs.

We have the following questions:

1. Is there any minimum time wait on calling sl_Start after sl_Stop. Is the 3 second time insufficient? Could this lead to the assert?

The device works fine if the network process is restarted every 3 seconds when there is no profile added. What difference does adding a profile make?

2. We have resorted to this solution because the auto and fast connection policies were not reliable. The device could reconnect to a router only if there was a successful connection previously. Is that the correct behaviour of auto connect policy. According to our understanding,if auto connection policy is set, then the device should connect to the added profile whenever it is available.

Please advise.

  • 0
    TI__Mastermind 30790 points

    Hi,

    I would recommend waiting longer than 3 seconds. I think something on the order of 10 seconds would be better. There is no minimum time within which you can guarantee a response.

    Even if you have aggressive low-power targets, you should be able to mitigate the potential impact in power consumption by sleeping for a sufficient amount of time in between failed connection attempts (assuming that in this case the access point is down or unresponsive).

    That being said, restarting the device when you don't see a WLAN connect or IP acquired event should not lead to an assert. Having a profile stored on the device shouldn't have a direct impact on the host application execution and cause the assert.

    The fast connection policy only applies to a previous (successful) connection.

    The auto connection policy applies to all stored profiles. When the auto connect policy is enabled, the device will perform a scan to look for nearby access points. When the scan completes, it will look for a match with any of the stored profiles and attempt to connect to the best one based on priority. A previous connection to an AP is not required for it to be chosen during the auto connect process. See section 4.3.3.1 in http://www.ti.com/lit/swru455. 

    Best Regards,

    Ben M

  • 0 in reply to Benjamin Moore
    Intellectual 265 points

    Hi Ben,

    Thanks for the reply.

    We still have the same issues with restarting the NWP frequently but the good news is that we got the auto connect working fine irrespective of a previous successful connection. So we need not restart the NWP whenever the access point is down.

    But sometimes when the router(AP) is rebooted, the router does not assign an IP and so the device acquires an LLA (link local address). Is there any way for the device to drop the LLA and acquire a DHCP assigned address (whenever router assigns one) without restarting the NWP?

    No net cfg settings are done explicitly so the DHCP mode is enabled by default.

    Thanks in advance.