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.7 Over-the-Air Updates

An OTA update refers to a software update that is wirelessly transferred and installed on a system. Wi-Fi-enabled systems can receive software updates directly from cloud servers, which makes it easier for vendors to distribute software updates to a large number of devices deployed across different regions and in various locations.

It is important for all products that connect to peers through the Internet to support software updates, because they are necessary to ensure that components of the software that enable security features stay up-to-date over the lifetime of a product. For example, the files needed to support TLS authentication and connect with a peer through the Internet may need to be updated over time. In addition to supporting the security life-cycle of a product, software updates also let developers enable new features for end customers after the product is sold.

The SimpleLink Wi-Fi SDK includes an OTA library that can be used to quickly implement OTA updates in an application. The library includes support for both Dropbox and GitHub APIs, but the libray can also be modified to support alternate content delivery networks (CDN). The TIDC-01005 demonstrates an OTA update solution for a Wi-Fi electronic smart lock using the OTA library with the Dropbox API.

The OTA process in the wifi_doorlock application is implemented in a software task that executes its own state machine. When the OTA task starts, it prevents the user from triggering an OTA update until the system has successfully connected to a local network and acquired an IP address. When connected, the task enters an idle state where it remains until an OTA update is triggered by the user. The user can trigger an OTA update by using MQTT to publish a message to the CC3220 device on the LockOTA topic. When started, the OTA task enters the OTA Run State, where the task downloads the components of the software update and writes the update to the file system until the update is complete. After all the components are downloaded and have been stored on the external serial flash, the OTA task sends a reset request to the control task, to trigger the system to reboot and run with the updated software.

Figure 2-10 shows a diagram of the state machine implemented by the OTA task.

GUID-F2DAEA85-FDDF-40BD-8007-5BDC4B4D3A02-low.gifFigure 2-10 OTA Task State Machine