• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 272 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.

LAUNCHCC3220MODASF: Host processing callbacks during provisioning

Ralph Corderoy
Expert 1110 points
Part Number: LAUNCHCC3220MODASF
Other Parts Discussed in Thread: CC3220SF

Hi,

I'm trying to get to grips with AP provisioning on the CC3220SF and I'm aware that once provisioning is underway only sl_WlanProvioning() and sl_Stop() can be called otherwise SL_RET_CODE_PROVISIONING_IN_PROGRESS, -2014, is seen. But what hasn't occurred to me is that callbacks from the NWP into the Host back still occur until I saw an aside by a TI engineer on here. Is that the case? In particular, a HTTP(S) request to the NWP's HTTP processor will make it through to the Host to process just as if provisioning isn't in progress?

The app needs to pass the CC3220 more than just the user's AP SSID and PSK. It's doing those with a POST to /api/1/wlan/profile_add. The app would also like to supply details for accessing the cloud server used for confirmation and all further CC3220 chat, and learn a unique ID from the CC3220 so when the app contacts the cloud server it can identify which CC3220 it's confirming. If the HTTP server can handle arbitrary requests separate from those TI define for provisioning then that seems the solution.

Out of interest, is all the functionality available to the Host so sl_WlanProvisioning() needn't be used and instead the Host may drive the NWP through the provisioning process, e.g. sl_WlanProfileAdd(), allowing a tailored interface to obtain these extra details and provide the unique ID, etc? Or is there some magic sauce involved which only the NWP can do which I'm not seeing at the moment?

Lastly, there's seven slots available for storing profiles. Is there any common or recommended policy for what to do when they're all taken and the user tries to provision with a new AP? I can think of getting the list of visible SSIDs with sl_WlanGetNetworkList() and removing one that's not present, assuming there is one. A more certain approach would be to remove the one least-recently-used, but that would mean maintaining a LRU on the Host side. Rather than have the app encounter the all-slots-full problem, it would seem better to have the Host ensure one slot is empty before starting provisioning; auto-provisioning isn't being used, the user explicitly starts the process with a button press on the CC3220.

Cheers, Ralph.

  • 0
    TI__Mastermind 28285 points

    Hi Ralph,

    Doing my best to understand your question. Are you looking to recieve HTTP responses/commands during the provisioning process? I don't believe this is possible. If you need to send additional data during the provisioning process, you are able to do this by creating a custom provisioning process that puts us in AP mode, have the device connect and transfer the relevant data, then manually add the profile to the device.

    BR,

    Vince 

  • 0 in reply to Vincent Rodriguez
    Expert 1110 points

    Hi Vincent,

    I'm looking to provision with external confirmation by the CC3220 using the provisioned profile to connect to the WLAN and then a cloud server where it will hand over a token to prove it's the device about which the local app has recently been in contact with the cloud server. How is external confirmation by a cloud server meant to work if the app can only POST across WLAN access details for the profile and can't GET the device's UDID or similar? How does the cloud know that this device making contact is the one to associate with the user who is running the app and has already logged into the cloud server?

    In https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/769966 talks of the app retrieving the UDID over HTTP in a thread that's about provisioning which is why I wondered if the HTTP server, which is up and running for the GET and POSTs of the provisioning API, also served other requests by the normal callback mechanism into the Host processor's code. Otherwise, I'm puzzled how external confirmation is helpful as provided by sl_WlanProvisioning().

    Thanks for confirming the Host processor can drive a complete provisioning process itself. In which case no calls to sl_WlanProvisioning() would occur?

    Cheers, Ralph.

  • 0 in reply to Ralph Corderoy
    Expert 1110 points

    Hi again Vincent,

    SWRA513B, Feb-2017, revised Jan-2020, is one of several TI documents which suggest more than just AP credentials can be passed across from the app during provisioning. On page 3 it lists parameters arriving from the app: Network name (SSID), Password, Device name (optional), UUID (optional). That UUID presumably ties together the app, CC3220, and cloud so the app can ask the cloud 'Has CC3220 with this UUID I gave it turned up yet?'

    Cheers, Ralph.

  • 0 in reply to Ralph Corderoy
    TI__Mastermind 28285 points

    Hi Ralph,

    You are correct, you should be able to use a custom token to ask for the UDID as described by Ben. 

    For Cloud credentials, you could do this in a similiar fashion, or do it after provisioning is complete. After provisioning is complete, you could open a TCP socket and send your cloud credentials from the mobile app to the device this way.

    BR,

    Vince