TIDUE59A May   2018  – September 2020

 

  1.   Description
  2.   Resources
  3.   Features
  4.   Applications
  5. 1System Description
    1. 1.1 Key System Specifications
  6. 2System Overview
    1. 2.1 Block Diagram
    2. 2.2 Design Considerations
    3. 2.3 Highlighted Products
      1. 2.3.1 CC3220
      2. 2.3.2 CC2640R2F
      3. 2.3.3 DRV8837
    4. 2.4 System Design Theory
      1. 2.4.1 CC3220S to CC2640R2F Interface
      2. 2.4.2 CC3220S to DRV8837 Interface
      3. 2.4.3 Software Architecture
      4. 2.4.4 Network Connection Management
      5. 2.4.5 Provisioning
        1. 2.4.5.1 AP Provisioning and SmartConfig™
        2. 2.4.5.2 Wi-Fi Provisioning Over BLE
      6. 2.4.6 Sending and Receiving Messages Through Cloud
        1. 2.4.6.1 Message Queue Telemetry Transport Protocol
        2. 2.4.6.2 MQTT Client Implementation
      7. 2.4.7 Over-the-Air Updates
        1. 2.4.7.1 HyperText Transfer Protocol
      8. 2.4.8 Security Enablers
        1. 2.4.8.1 Secure Boot
        2. 2.4.8.2 Secure Sockets
          1. 2.4.8.2.1 Hardware Accelerators
          2. 2.4.8.2.2 Simple Network Time Protocol
        3. 2.4.8.3 File System Security
          1. 2.4.8.3.1 Failsafe Files and Bundle Protection
      9. 2.4.9 Low-Power Consumption
  7. 3Hardware, Software, Testing Requirements, and Test Results
    1. 3.1 Required Hardware and Software
      1. 3.1.1 Hardware
        1. 3.1.1.1 CC3220S LaunchPad™ Development Kit
        2. 3.1.1.2 CC2640R2F LaunchPad™ Development Kit
        3. 3.1.1.3 Sensor BoosterPack™ Connections (BMI160)
        4. 3.1.1.4 DRV8837EVM Modifications and Connections
        5. 3.1.1.5 Assembling EVMs
      2. 3.1.2 Software
        1. 3.1.2.1 Getting Started With Software
          1. 3.1.2.1.1 Build simple_np Application and Flash CC2640R2F
          2. 3.1.2.1.2 Use Premade UniFlash ImageCreator Project
          3. 3.1.2.1.3 Importing Project Source Files Into CCS
        2. 3.1.2.2 User Files
        3. 3.1.2.3 Run Wi-Fi® Doorlock Demo
          1. 3.1.2.3.1 Connect CC3220 to Network
          2. 3.1.2.3.2 Networking Functions
            1. 3.1.2.3.2.1 Get Current Date and Time (SNTP)
            2. 3.1.2.3.2.2 Send and Receive Messages (MQTT)
            3. 3.1.2.3.2.3 Perform Software Update Using Dropbox (OTA Update)
    2. 3.2 Testing and Results
      1. 3.2.1 Pass or Fail Tests
      2. 3.2.2 Power Measurements
      3. 3.2.3 Test Setup
        1. 3.2.3.1 CC3220S
        2. 3.2.3.2 CC2640R2F
        3. 3.2.3.3 DRV8837
      4. 3.2.4 Test Results
      5. 3.2.5 Battery Life Estimate
  8. 4Design Files
  9. 5Software Files
  10. 6Related Documentation
    1. 6.1 Trademarks
  11. 7Terminology
  12. 8About the Author
  13. 9Revision History

2.4.5.1 AP Provisioning and SmartConfig™

AP provisioning is the most common provisioning method. During AP provisioning, an unprovisioned Wi-Fi device temporarily operates as an AP. This method allows a device, such as a smartphone, tablet, or PC, to connect to the AP over Wi-Fi and transmit the information for the desired network connection directly to the device. The CC3220 receives the network credentials through a Restful API based on its internal HTTP server.

It is important to secure the connection between the device sending the network credentials and the CC3220 during AP provisioning. To protect the network credentials and ensure a user does not unknowingly transmit them to an unwanted device, the TIDC-01005 uses WPA2 authentication when a station connects to the CC3220 AP. The TIDC-01005 is also configured to direct incoming connections to a secured HTTP port and establish a TLS session over which the credentials are passed.

SmartConfig is a proprietary provisioning method from TI that uses a smartphone or tablet to broadcast network credentials to a TI Wi-Fi device. The unprovisioned device can scan for SmartConfig broadcasts while operating in station mode or AP mode.

The CC3220S integrates the code needed to run AP and SmartConfig provisioning in the network processor firmware. This saves the user from having to dedicate a large portion of the application memory for implementing provisioning. Instead, the application must only handle the following:

  • Sending a command to the network processor to start the provisioning process
  • Receiving asynchronous events during provisioning
  • Stopping provisioning when complete

To manage the provisioning process within an application, it is important to understand the internal provisioning flow used by the network processor. When provisioning is first started by the application, the CC3220 device enters the configuration state where it waits to receive the parameters of the network. After receiving the parameters, the device then attempts to connect to the network and provides feedback to the user upon success. A diagram of the provisioning process flow is in the CC3120, CC3220 SimpleLink Wi-Fi Internet-on-a chip Solution Device Provisioning application report.

In the wifi_doorlock example code, the AP provisioning and SmartConfig process is handled by a dedicated provisioning task. The task remains idle until the provisioning state machine is started by the network connection task. When the provisioning state machine is started, the provisioning task puts the network processor in the provisioning state and handles asynchronous events until the system successfully connects to the network. Whenever the application is restarted, the system always attempts to connect to a network based on a stored profile and skip the provisioning process if possible.

Figure 2-6 shows a diagram of the provisioning state machine implemented by the TIDC-01005 software.

GUID-C686AC02-331E-48C3-9E2C-B3B827518108-low.gifFigure 2-6 Provisioning Task State Machine