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

Test Results

The average current consumed by the CC3220, while the system was in the idle connected mode (connected to the AP and only receiving AP beacons or broadcast and multicast traffic) with an LSI of 400 milliseconds, was measured to be 377 µA on average, over multiple DTIM receptions. The power consumed while in the idle connected mode contributes the most to the overall average power consumption, because the system is expected to spend the majority of its active time in the idle connected state. Figure 3-15 shows a graph of the measured current.

GUID-7B247332-AEFE-4582-A5B5-EF42D3DE76A3-low.pngFigure 3-15 CC3220S Current Consumption Versus Time While in Idle Connected Mode With 400-ms LSI

When a message is sent to the TIDC-01005 from the cloud, the CC3220S receives an indication that the AP has buffered a packet for it through the DTIM. In response to the traffic indication, the CC3220S wakes up from low-power mode and polls the AP for the message. The impact on the system power consumption is different depending on which message is received. The first type of message considered is a lock or unlock command. When a lock or unlock command is received, the network processor wakes up, receives the message, and sends the command to the host MCU. The host MCU then parses the command and drives the motor in the appropriate direction for two seconds. The average current consumption of the CC3220S during a lock or unlock command was approximately 12.1 mA and Figure 3-16 shows the current consumption.

GUID-6FE0269C-6D4C-4742-B730-DBF5341DDED1-low.pngFigure 3-16 CC3220 Current Consumption During Lock and Unlock Cycle

In Figure 3-16, the first spike in current after the cursor represents when the network processor detects a message is ready for it and wakes up to poll the AP. After the message is received, the MCU is waken up by the network processor, and the message is sent to the MCU to be handled. The current consumption remains around the 11 to 12-mA level for the entire two seconds while the MCU is active and driving the motor. The smaller spikes in current that occur while the MCU is active and following the message reception represent AP beacon receptions. These beacon receptions occur because the CC3220S waits to resume LSI until a timeout occurs after a message reception. By not entering LSI immediately, the latency is reduced when multiple messages are sent to the system within a short interval without a large impact on power consumption.

The second type of message that can be received by the TIDC-01005 is a lock status request. When a lock status request is received, the network processor wakes up, receives the message, and sends the request to the host MCU. Then, the MCU parses the request and responds by sending a message indicating the lock state back to the cloud. The average current consumption of the CC3220S, in response to a lock status request, was found to be approximately 11.8 mA. Figure 3-17 shows a graph of the current consumption for the lock status case.

GUID-9F186BB5-E307-4CBE-B60A-058AEA576C92-low.pngFigure 3-17 CC3220 Current Consumption During Lock Status Request

Similar to the lock or unlock command case, the first spike in current after the cursor represents when the network processor detects a message is ready for it and wakes up to poll the AP. When the message is received, it is passed to the MCU to be parsed. Users can see from Figure 3-17 that the current increases significantly in the middle of the cycle when the lock state is transmitted to the cloud (MQTT broker). After the message is received by the MQTT broker and acknowledged, the system enters the idle connected state. Users can see from Figure 3-17 that the system again waits for a timeout to occur before resuming the configured LSI.

The average current consumed by the CC2640R2F SNP throughout the provisioning process (while advertising, paired, and exchanging AP credentials) was approximately 211.8 µA. While idle (before and after provisioning), the average current consumed by the CC2640R2F was measured to be approximately 40 µA. Figure 3-18 and Figure 3-19 show the current consumption from both measurements.

GUID-F2D93B0C-916F-4C48-8F29-B5CCA6471BBA-low.pngFigure 3-18 CC2640R2F Current Consumption During Provisioning
GUID-6FB1DDAD-FA64-4375-8943-DBBE8AEA2CD1-low.pngFigure 3-19 CC2640R2F Current Consumption While Idle

The power consumed by the DRV8837 during lock and unlock events was also measured. Specifically, the current consumed while supplying 5 V to the motor power supply of the DRV8337 and driving a load was measured. The load used was a deadbolt installed in a door. The average current consumption while locking and unlocking the deadbolt was approximately 77.6 mA and 73.1 mA, respectively, over the two-second interval that the motor was driven. Figure 3-20 and Figure 3-21 show the current consumption.

GUID-333BD2C6-59EC-4113-8211-21158EBA6950-low.pngFigure 3-20 DRV8837 Current During Lock Event
GUID-01FCF0CF-4419-49F1-AD02-72E1FAC7EA85-low.pngFigure 3-21 DRV8837 Current During Unlock Event

In between lock events, the DRV8837 is held in sleep mode by the CC3220S. The average sleep current of the motor while the DRV8837 was held in sleep was 0.099 µA and Figure 3-22 shows the current measurement.

GUID-61158D92-C00C-4654-9D1E-D598000369E0-low.pngFigure 3-22 DRV8837 Sleep Current
Note:

The previously listed results are based on EVMs, not an optimized hardware design. A system with an optimized hardware design may provide improved results.