Table of Contents

Introduction

The CC3200 SimpleLink™ Power Management Measurement application provides users the ability to configure the device in various low power uses cases, for the purposes of current consumption measurements. The user can choose to work in the Interactive (simple) mode or to use the advanced mode where they can change the define values in the source code in order to control the behavior of the application. The application has recommended guidelines on how to optimize the power consumption in the different power profiles use cases.
The various system’s basic power modes are first explained. These are the building blocks of all power management profiles:

• Hibernate
• Low power deep sleep (LPDS)
• Active modes (Rx or Tx)

The various power profiles are the focus of this document:

• Always connected (aka. Idle connected)
• Intermittently connected
• Transceiver mode

that the focus is on periodic/repetitive events, because one time events, no matter how high they peak, do not need to be taken into account, since their influence is negligible for longer periods of activities.

Getting started

All Instructions in this document are under the assumptions that the user already has a working environment of CC3200 LaunchPad, and installed all the relevant software packages. Otherwise, please refer to CC3200 getting started user guide, before proceeding.

Pre-requisites

Hardware

• CC3200 LaunchPad Rev4.1 or above
• Oscilloscope with differential probe or current probe
• Digital multimeter (capable of measuring down to 1 uA)

Software

The power management application is released as a example within the CC3200 SDK. Import it into your environment (CCS/IAR), as any other project described in the CC3200 Getting Started Guide.

Basic System Power Modes

The following section describes the CC3200 active and low power static modes. The CC3200 device contains only the Networking sub-system and is self-contained in terms of power optimization. The following system modes are defined, and could be measured using TI’s EVM boards. The main three building blocks of most power related application profiles are:

• Hibernate
• Low Power Deep Sleep (LPDS)
• Active: RX & Tx

More details can be found at: SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub-System Power Management

Hibernate State

The hibernate mode represents the lowest power state of the device. This mode is entered when the MCU subsystem requests the power management unit to shut off the voltage source itself. In hibernate, all the voltage sources, like DCDC or LDOs, within the power management unit are shut off. Very few logic, which works directly on battery power, is ON and they work on 32 KHz clock. Wakeup sources to exit this sleep mode can be a toggle event on the device’s general purpose IO (GPIO) or based on timer expiry. In order to measure the static hibernate current consumption, the user needs to set the global use case variable to HIBERNATE_MEASURE.

The application enables the user to enter a constant Hibernate state for an easy measurement of the power consumption of this state.

To do so, configure g\_ActiveUseCase to HIBERNATE_MEASURE in the PM management benchmark code.

Measurement Tool

Follow the steps mentioned in the Static Current Measurements section, in order to record the hibernate current.

Expected Results The expected power consumption numbers are described in the datasheet.

LPDS state

To enter into this mode each subsystem processor requests the clock management unit for shutting off their subsystem. When both the subsystems request for this mode, Clock management unit will turn off the PLL, 40Mhz xtal, and the power management unit will shut off the power to each subsystem and scale down the voltage of always on domain to 0.9V. Active logic in this mode will work at 32 KHz xtal. There is an option of retaining the memory content for each subsystem or not. Wakeup sources to exit this sleep mode can be a toggle event on the device’s general purpose IO (GPIO) or based on timer expiry. In this mode, power saving happens because of turning off of power domain, turning off of PLL, turning off of 40 MHz xtal, memory not retained if opted, and voltage scale down. In order to measure the static Low Power Deep sleep (LPDS) current consumption, the user needs to set the global use case variable to SLEEP_MEASURE.

The application enables the user to enter a constant Sleep mode (no traffic) to enable an easy way to measure the power consumption of this state.

To do so, configure g_ActiveUseCase to “SLEEP_MEASURE” in the PM management benchmark code

Measurement Tool
Follow the steps mentioned in the Static Current Measurements section, in order to record the LPDS current.

Expected Results
The expected power consumption numbers are described in the datasheet.

Active (Rx & Tx) States

The device is fully active, voltage levels are at their operational value, and all clocks are ticking. At least one block (MCU / NWP / Wi-Fi) is running. The two main active modes are transmitting (TX) and receiving (RX). The Tx and Rx active currents vary based on the channel, packets type, etc…

Configuration Parameter
In order to individually measure the Tx and Rx current consumptions, please refer to the Appendix section of ‘Using radiotool for active modes’.

Follow the steps mentioned in the Profiles and Active current measurements section, in order to measure the average current consumption, for each of the active mode, and power profile use cases.

Expected Results
The expected power consumption numbers for each Rx and Tx states are described in the datasheet.

Power Profiles Use Cases

The Power Profiles use cases combine various power states to emulate the behavior of a real application in an end product. This section describes how to emulate, optimize, and measure such profiles. We will focus on these three main profiles:

• Idle Connected
• Intermittently Connected
• Transceiver Mode

End product’s applications have various power requirements, which drives the duration of the active states and inactive periods. The system’s latency, or the response time, is another common requirement, which focuses on how fast a device can wake up from inactive mode, and be fully functional. Thus, it is important to architect multiple low power inactive modes depending upon all the possible use cases of the end product. In other words, the low power mode used in the system is determined by the end product’s application properties.

The majority of the use cases for battery powered devices in the IoT context would necessitate the device to be in its lowest possible power state for most of its lifetime, only having to intermittently wake up and take some action. The choice of the suitable low power mode is primarily a trade-off between the response time and the power consumption. Two popular deployment use cases are considered here and the power consumption determined.

Idle Connected Profile – Use cases with responsiveness being of paramount importance would place the system in the LPDS. In this mode the device is always connected to the access point. The entire system is in LPDS with only the WLAN subsystem periodically waking up to service beacons. This system is remotely triggered to wakeup and takes action, usually by issuing commands over cloud based services.

Sensor profile - Non-time-critical use cases that have infrequent activity and need to take action either periodically or based on an external trigger (GPIO) would place the system in HIBernate. Most of the sub-systems are in its powered down state always and occasionally wakes up to perform all the necessary actions.

Follow the steps mentioned in the Profiles and Active current measurements section, in order to measure the average current consumption, for each of these profiles.

Use Case 1: Always Connected

The always connected use case deals with situations where the device must stay connected to AP in any time. Staying connected may cause a high power consumption due to periodic beacon functionality. In order to reduce the power penalty, the next improvement was implemented in the application:

• LSI (Long Sleep Intervals) – A configuration that enable to wake the device up only on every n-th beacon thus providing longer Sleep periods.

A good representation of a code for such case is:

sl_start(0,0,0);
sl_WlanPolicySet(...); // configure the time interval between wakeups
sl_socket();
sl_SetSocketOpt();     // configure UDP/TCP Secured or not
sl_bind();
while (1) {
    sl_Send();         // can be UDP/TCP and/or secure connection 
    sl_Recv();         // can be UDP/TCP and/or secure connection
    Delay();
}  

Configuring Options

There is one define value that configures the behavior of the device in this case:

• LSI_SLEEP_DURATION_IN_MSEC – define the sleep period between each wake-up for beacon reception.
  • Example: “#define LSI_SLEEP_DURATION_IN_MSEC 500” will set it to 500 milliseconds.

A detailed configuration example for always connected use case is shown in the Always connected configuration example figure; the relevant settings are emphasized.

Expected Results

The following figure describes the use case profile:

Use Case 2: Intermittently Connected

This mode is for devices that need to operate between long time intervals. In this mode, the device is in Hibernate state between working cycles, the lowest power consumption possible state. Almost all the device components are shut-down, hence when waking up a new connection needs to be established. The next tweaks were taken in order to reduce the power consumption cost of this periodic establish connection action.

1. Working with static IP (when possible) in order avoid DHCP.
2. Set the connection policy to work with fast connect, which mean the device will try first to connect to the previous connection.
3. Disable Scan, as in this case we probably stay in the same channel & network (AP).
4. Disable mDNS.

A good representation of a code for such case is:

sl_start(0,0,0); 
sl_NetCfgSet(…) ;      // set static IP address to the device
sl_WlanPolicySet(...); // disable scan
sl_WlanPolicySet(…);  set fast connect
sl_NetAppStop(..);     // disable mDNS
while (1) {
    sl_stop(10);       // Enter hibernate mode
    Delay();           // Long hibernate Time period
    sl_Start();        // device wake up and connect to network with previous setting  
    sl_socket();       // usually UDP 
    sl_SetSocketOpt(); // configure UDP/TCP Secured or not
    sl_bind();   
    sl_RecvFrom();  
    sl_SendTo();
    sl_Close();
}  

Configuration Option

The define value that configures the behavior of the device in this case:

• NOT_ACTIVE_DURATION_IN_MSEC – defines the hibernate time period between 2 active states.
  • Example: “#define NOT_ACTIVE_DURATION_IN_MSEC 800” will set 800 milliseconds hibernate time periods.

A detailed configuration example for intermittently connected use case is shown in Intermittently Connected configurations example figure; the relevant settings are emphasized.

Expected Results

UDP Packet

The following figure describes the use case profile:

TCP Packet

The following figure describes the use case profile: