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

Wi-Fi Provisioning Over BLE

Wi-Fi provisioning over BLE is another method of provisioning a Wi-Fi based system to a new Wi-Fi network. The main benefit of provisioning a system over BLE is that it can provide a more consistent and streamlined user experience when provisioning from a smartphone or tablet. On some mobile operating systems, AP provisioning requires a user to do the following:

  1. Open a settings application to disconnect the mobile device from the Wi-Fi network it is currently using.
  2. Connect to the AP created by the device being provisioned.
  3. Enter the credentials for the original Wi-Fi network.
  4. Switch back to the original Wi-Fi network to confirm that provisioning succeeded.

When provisioning over BLE, the process can be completed without the user ever having to change the Wi-Fi network to which the mobile device is connected. Therefore, the entire provisioning process can be carried out within a single mobile application. The process for provisioning the system over BLE is as follows:

  1. BLE advertising starts.
  2. A peer connects to a BLE device and authenticates with a passkey.
  3. The user writes the SSID, Security Key, and Device Name to corresponding BLE characteristics.
  4. The user writes 0x01 to the Provisioning Start characteristic, to signal that a new profile must be tested.
  5. CC3220S disconnects the BLE, reads the values written to the characteristics, starts the Wi-Fi network processor, and attempts to connect to the profile.
  6. CC3220S waits to obtain an IP address and then disconnects the Wi-Fi and stops the Wi-Fi network processor.
  7. The BLE advertising restarts.
  8. The mobile device reconnects to the system over BLE and reads the Provisioning Status characteristic (success or fail).
  9. If the process succeeds, the CC3220S adds the Wi-Fi network information as a stored profile, exits the provisioning state, and then connects to the Wi-Fi network.

Even though the overall process implemented by the system may take more steps, the user experienced is simplified, because the user only needs to take an action for Steps 2, 3, and 4.

The TIDC-01005 software application implements provisioning over BLE using a modified version of the BLE provisioning example from the SimpleLink SDK Bluetooth Plugin. In the TIDC-01005 software, a BLE thread is dedicated to handling communication with the CC2640R2F, while the system is being provisioned. Because there is no hardware coexistence mechanism for Wi-Fi and BLE in the system, the software application turns off the Wi-Fi network processor while the BLE interface is active and stops the BLE activity while the Wi-Fi interface is active. To keep the Wi-Fi and BLE activity separate, all of the Wi-Fi activity (such as testing received credentials) is handled inside the network interface task instead of the BLE provisioning task.

Figure 2-7 shows the state machine implemented by the task that is dedicated to provisioning over BLE.

GUID-B4AFFD07-F54F-4A64-8180-B9D55899A623-low.gifFigure 2-7 BLE Provisioning State Machine