• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 40 subscribers
  • Views 331 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.

Original question:

RTOS/CC3220MODA: MQTT connection would not succeed after many failed attempts.

RTOS/CC3220MODA: MQTT connection would not succeed after many failed attempts.

Zac
Genius 3100 points
Part Number: CC3220MODA

Tool/software: TI-RTOS

Hi Michael & Team,

This is relating an old question I had asked where the MQTT connection wouldn't success after many failed attempts (when there is an internet outage). Though it rarely happened during our development (once or twice and we could not replicate), it once happened in one production board where I had to reset the board to resume its operations. 

Since I couldn't find a reason or solution, the only option left would be to call sl_Stop(200) and sl_Start(NULL, NULL, NULL) when there is mqtt connection failure. I tried it on my debugging board (for few hours) and it seems fine, however I need to understand its drawbacks before I push it to production. Can someone please help me to understand the actual impact of invoking sl_Stop and sl_Start frequently? Does it reconnect to the WiFi in every cycle or will it get a new IP address on each cycle ? Does it impact any other threads like scheduling, gpio read/write, ota, ntp, file read/write ?

I am on 2.40.01.01 and using CC3220MODA boards.

Appreciate quick support.

Regards

Zac

  • 0
    TI__Mastermind 40965 points

    Hi Zac,

    Calling sl_Stop()/sl_Start() frequently will not have any ill effects by itself, as that just restarts the NWP through the built-in nHib mechanism and this is something that is designed to be routinely performed. Performing a restart like that in your app is actually the recommended course of action for several possible error cases that the NWP can run into. 

    When an sl_Stop()/Start() is performed, the NWP is completely turned off momentarily and then restarted. This means that it will need to reconnect to your AP, although it probably won't mean that you will get a different IP address as the AP should see that the DHCP lease for your device is still in place and reassign it the same IP address. Other than that, it will impact any thread with functionality that relies on a sl_* API. Thus, GPIO read+writes will not be affected, but your file read+writes that use sl_Fs* calls will be affected. The main impact to those threads is that you will need to ensure that any existing context and state-keeping in your application knows that the NWP got restarted. For example, if you have a file handle open and you perform an sl_Stop()/sl_Start(), then that file handle will become invalid and you will run into an error if you try to use that file handle without first reopening the file. If error handling in your application is robust enough to handle unexpected SL API failures, then using an sl_Stop()/sl_Start() shouldn't affect too much.

    If you think that your existing application will not handle a sl_Stop()/sl_Start() elegantly, then you can also simply restart your entire application by forcefully putting the MCU into hibernate in your app code. When the MCU wakes from hibernate, it loses all of its volatile state and is effectively restarted. See this thread for details:

    https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/628161?CC3220SF-LAUNCHXL-software-reset

    Let me know if you need any clarification on the effects of a sl_Stop/Start, or if you have any further questions on this topic.

    Regards,

    Michael