Infineon AIROC CYW43012 User manual

Application note
Please read the sections “Important notice” and “Warnings” at the end of this document
002-27910 Rev. *C
www.infineon.com
2023-05-29
AN227910
Low-power system design with AIROC™ Wi-Fi &
Bluetooth® combo chip and PSoC™ 6 MCU
About this document
Scope and purpose
AN227910 describes how to use AIROC™ Wi-Fi & Bluetooth® combo chip and PSoC™6 MCU to design a low-
power connectivity solution for Internet of Things (IoT) applications using AIROC™ CYW43012 Wi-Fi &
Bluetooth® combo chip.
The technical description in this application note applies to other AIROC™ Wi-Fi & Bluetooth® combo chip and
PSoC™6 MCU.
The 28-nm radio combined with a 40-nm PSoC™6 MCU enables an ultra-low-power platform for IoT
applications. This application note provides an overview of low-power modes and features in the AIROC™
CYW43012 Wi-Fi & Bluetooth® combo chip and describes various techniques such as host offload features to
optimize power consumption in the system, assist with low power assistant (LPA) tool.
Intended audience
This document is intended for anyone using AIROC™ Wi-Fi & Bluetooth® combo chip and PSoC™6 MCU to
design a low-power connectivity solution for IoT applications.

Application note
2
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
Table of contents
Table of contents
About this document....................................................................................................................... 1
Table of contents............................................................................................................................ 2
1Introduction .......................................................................................................................... 4
2Low-power overview.............................................................................................................. 5
2.1 AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip power modes .......................................................5
2.2 PSoC™ 6 MCU power modes ...................................................................................................................6
2.3 AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip power-related hardware signals.........................7
2.4 Power mode transition ...........................................................................................................................8
3WLAN power optimization techniques .....................................................................................10
3.1 IEEE 802.11 (Wi-Fi) power saving..........................................................................................................10
3.1.1 Beacon interval ................................................................................................................................10
3.1.2 Listen interval...................................................................................................................................10
3.1.3 DTIM period......................................................................................................................................10
3.1.4 Power saving methods.....................................................................................................................11
3.1.4.1 Power save poll ...........................................................................................................................12
3.1.4.2 802.11 power save without poll..................................................................................................12
3.1.4.3 Association timeout limit............................................................................................................13
3.1.5 802.11ac-friendly features ...............................................................................................................13
3.2 Wi-Fi power save implementation........................................................................................................13
3.2.1 Wi-Fi Host Driver (WHD) power save interface................................................................................13
3.2.2 Cyclic timers in network stack.........................................................................................................16
3.3 Host offloads to WLAN device...............................................................................................................17
3.3.1 ARP offload.......................................................................................................................................17
3.3.2 Packet filter offload..........................................................................................................................18
3.3.2.1 Network layer or EtherType filter...............................................................................................20
3.3.2.2 Transport layer/IP protocols ......................................................................................................20
3.3.2.3 Applications layer/TCP and UDP port numbers.........................................................................20
3.3.3 TCP keepalive offload ......................................................................................................................21
4Bluetooth® power optimization techniques..............................................................................23
4.1 Advertisement events ...........................................................................................................................23
4.2 Connection events ................................................................................................................................24
4.2.1 Connection interval..........................................................................................................................24
4.2.2 Use slave latency..............................................................................................................................24
4.2.3 Bluetooth® LE parameters in Bluetooth® Configurator..................................................................24
5PSoC™ 6 MCU power optimization techniques ..........................................................................26
5.1 Core voltage and operating frequency.................................................................................................26
5.2 Reducing the leakage in Deep Sleep ....................................................................................................26
5.3 RTOS tickless mode...............................................................................................................................28
5.4 Additional power optimization techniques .........................................................................................28
6Low power assistant (LPA) .....................................................................................................29
6.1 LPA configuration..................................................................................................................................29
6.2 Using LPA in ModusToolbox™ software................................................................................................32
7Power measurement using CY8CKIT-062S2-43012.....................................................................36
7.1 Hardware setup.....................................................................................................................................36
7.2 mtb-example-wifi-wlan-lowpower.......................................................................................................37

Application note
3
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
Table of contents
7.3 mtb-example-wlan-offloads.................................................................................................................43
7.4 mtb-example-btstack-freertos-cts-client.............................................................................................47
7.5 mtb-example-btstack-freertos-cts-server............................................................................................53
7.5.1 Power measurement........................................................................................................................53
8Summary .............................................................................................................................56
References....................................................................................................................................57
Revision history.............................................................................................................................58
Disclaimer.....................................................................................................................................59

Application note
4
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
Introduction
1Introduction
Infineon AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip is a 28-nm, ultra-low-power device that supports
single-stream, dual-band IEEE 802.11n-compliant and 802.11ac-friendly Wi-Fi MAC/baseband/radio and
Bluetooth® 5.0 BR/EDR/LE. The WLAN section supports an SDIO interface to the host MCU (PSoC™ 6 MCU), and
the Bluetooth® section supports a high-speed 4-wire UART interface to the host MCU.
PSoC™ 6 MCU bridges the gap between expensive, power-hungry application processors and low-performance
microcontrollers (MCUs). The ultra-low-power PSoC™ 6 MCU architecture offers the processing performance
needed by IoT devices, eliminating the tradeoffs between power and performance. The PSoC™ 62 series, built
on an ultra-low-power 40-nm platform, complements the AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip,
providing an ultra-low-power host interface to the Wi-Fi and Bluetooth® radio available in AIROC™ CYW43012
Wi-Fi & Bluetooth® combo chip.
This application note discusses various low-power design techniques along with low-power features offered by
the Infineon AIROC™ Wi-Fi & Bluetooth® combo chip + PSoC™ 6 MCU platform and how to use them in your
application. This application note requires a basic knowledge of the AIROC™ CYW43xxx Wi-Fi & Bluetooth®
combo chip and PSoC™ 6 MCU architecture, and the ability to develop applications using ModusToolbox™
software.
If you are new to AIROC™ Wi-Fi & Bluetooth® combo chip, PSoC™ 6 MCU, or ModusToolbox™ software, see the
Getting started with PSoC™ 6 MCU on ModusToolbox™ software.

Application note
5
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
Low-power overview
2Low-power overview
2.1 AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip power modes
AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip has been designed with the stringent power consumption
requirements of battery-powered IoT devices in mind. Table 1 lists the power modes supported in CYW43012.
Table 1 Power modes in AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip
Power mode
Description
Active
•All WLAN blocks in AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip are powered up
and fully functional with active carrier sensing and frame transmission and reception.
•All required regulators are enabled and put in the most efficient mode based on the
load current.
•Clock speeds are dynamically adjusted by the PMU sequencer.
Deep Sleep (DS0)
•The radio, analog domains, and most of the linear regulators are powered down. The
rest of AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip remains powered up in an
idle/retained state.
•All main clocks (PLL, crystal oscillator, or TCXO) are shut down to reduce active power
to the minimum level. The 32.768-kHz LPO clock is available only for the PMU
sequencer. This is necessary to allow the PMU sequencer to wake up the chip and
transition to active mode.
•Complete RAM needed for WLAN firmware is retained.
Power down (Off)
•AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip is effectively powered OFF by
shutting down all internal regulators. The chip is brought out of this mode by external
logic re-enabling the internal regulators.
AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip includes an advanced WLAN power management unit (PMU)
sequencer, which provides significant power savings by putting the AIROC™ CYW43012 Wi-Fi & Bluetooth®
combo chip device into various power management states appropriate to the current environment and
activities that are being performed.
The PMU enables and disables internal regulators, switches, and other blocks based on the computation of the
required resources and a table that describes the relationship between resources and the time needed to
enable and disable them. Configurable, free-running counters (running at 32.768 kHz LPO clock) in the PMU
sequencer are used to turn ON/turn OFF individual regulators and power switches. Clock speeds are
dynamically changed (or gated altogether) for the current mode. Slower clock speeds are used wherever
possible. See the AIROC™ Wi-Fi & Bluetooth® combo chip for details on the PMU.

Application note
6
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
Low-power overview
2.2 PSoC™ 6 MCU power modes
PSoC™ 6 MCU features seven power modes split into system modes that affect the whole device and standard
Arm® CPU modes that affect only one CPU. The system power modes are Low-Power (LP), Ultra-Low-Power
(ULP), Deep Sleep, and Hibernate. The Arm® CPU power modes are Active, Sleep, and Deep Sleep, and are
available in system LP and ULP power modes. See AN219528 for details on PSoC™ 6 MCU low-power modes and
power reduction techniques. Table 2 summarizes PSoC™ 6 MCU power modes and provides a simplified version
for representing power mode transitions in a PSoC™ 6 MCU and AIROC™ Wi-Fi & Bluetooth® combo chip design
(Figure 1).
Table 2 Power modes in PSoC™ 6 MCU
Power mode
Description
Simplified power
mode
System LP
•All resources are available with maximum power and speed.
•All CPU power modes supported.
Active mode
System ULP
•All blocks are available, but core voltage is lowered resulting in
reduced high-frequency clock frequencies.
•All CPU power modes supported.
CPU Active
•Normal CPU code execution
•Available in system LP and ULP power modes
CPU Sleep
•CPU halts code execution.
•Available in system LP and ULP power modes
Sleep mode
CPU Deep
Sleep
•CPU halts code execution.
•Requests system Deep Sleep entry
•Available in system LP and ULP power modes
Deep Sleep
System Deep
Sleep
•Occurs when all CPUs are in CPU-Deep Sleep
•CPUs, most peripherals, and high-frequency clocks are OFF.
•Low-frequency clock is ON.
•Low-power analog and some digital peripherals are available for
operation and as wakeup sources.
•SRAM is retained.
System
Hibernate
•CPUs and clocks are OFF.
•GPIO output states are frozen.
•Low-power comparator, RTC alarm, and dedicated WAKEUP pins
are available to wake up the system.
•Backup domain is available.
Hibernate

Application note
7
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
Low-power overview
2.3 AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip power-related
hardware signals
AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip has six hardware signals that provide the power control
interface to the host (PSoC™ 6 MCU).
Table 3 Hardware signals in AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip
Signal
Description
WL_REG_ON
This signal is used by the PMU (with BT_REG_ON) to power-up the WLAN section. It is OR-
gated with the BT_REG_ON input to control internal AIROC™ CYW43012 Wi-Fi &
Bluetooth® combo chip regulators. When this pin is HIGH, the regulators are enabled, and
the WLAN section is out of reset. When this pin is LOW, the WLAN section is in reset. If
BT_REG_ON and WL_REG_ON are both LOW, the regulators are disabled.
BT_REG_ON
This signal is used by the PMU (with WL_REG_ON) to decide whether to power down
internal AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip regulators. When this pin is
HIGH, the regulators are enabled, and the Bluetooth® section is out of reset. When this
pin is LOW, the Bluetooth® section is in reset. If BT_REG_ON and WL_REG_ON are LOW,
the regulators will be disabled.
BT_DEV_WAKE
Bluetooth® device wakeup: Signal from the host (PSoC™ 6 MCU) to AIROC™ CYW43012 Wi-
Fi & Bluetooth® combo chip indicating that the host requires attention like sending data
to the Bluetooth® controller.
•Asserted: The Bluetooth® device must wake up or remain awake.
•Deasserted: The Bluetooth® device may sleep when all other sleep criteria are met.
The polarity of this signal is software-configurable and can be asserted as HIGH or LOW.
Default is asserted HIGH.
BT_HOST_WAKE
Host wakeup signal from the AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip
Bluetooth® controller to the host indicating that the AIROC™ CYW43012 Wi-Fi &
Bluetooth® combo chip Bluetooth® controller has data for the host.
•Asserted: host device must wake up or remain awake.
•Deasserted: host device may sleep when all other sleep criteria are met.
The polarity of this signal is software-configurable and can be asserted as HIGH or LOW.
Default is asserted HIGH.
WL_HOST_WAKE
Host wakeup signal from the AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip WLAN
device to the host indicating that the AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip
WLAN device has data for the host to process. This signal is an active HIGH signal.
•HIGH: host device must wake up or remain awake.
•LOW: host device may sleep when sleep criteria are met.
WL_DEV_WAKE
WLAN device wakeup signal. This signal is not used in current designs and SDIO-based
wakeup is used to wakeup the WLAN device.

Application note
8
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
Low-power overview
2.4 Power mode transition
Active
Sleep/Deep
Sleep
Reset
Off
Hibernate
Active
Deep Sleep
(DS0)
Reset
Off
1a 1b
2
345
6
11a
7
8 9
11b
10
PSoCMCU CYW43012
SDIO (Wi-Fi)
UART (BT)
WL_REG_ON
BT_REG_ON
WL_HOST_WAKE
BT_DEV_WAKE
BT_HOST_WAKE
Power down events
Firmware action
Reset events
LEGEND:
Peripheral interrupts/
Hardware events
nPower mode transitions
Figure 1 Simplified power mode transitions in “PSoC™ 6 MCUa+ AIROC™ CYW43012 Wi-Fi &
Bluetooth® combo chip” design
Transition
Description
Trigger
1a
PSoC™ OFF to reset transition
Power supply applied to PSoC™ 6 MCU.
1b
AIROC™ CYW43012 Wi-Fi &
Bluetooth® combo chip OFF to
reset transition
Power supply applied to AIROC™ CYW43012 Wi-Fi & Bluetooth®
combo chip.
2
PSoC™ reset to Active
transition
Firmware (boot/startup) transitions from reset to Active mode.
3
PSoC™ Active to Sleep or Deep
Sleep transition
Firmware (OS idle task) transitions from active to Sleep or
Deep Sleep mode.
4
PSoC™ Sleep or Deep Sleep to
active transition
Wakeup (interrupt) from Sleep/Deep Sleep; typical sources in a
AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip design:
•WL_HOST_WAKE (Deep Sleep or Sleep)
•BT_HOST_WAKE (Deep Sleep or Sleep)
•SDIO and UART interrupt (Sleep)
•Low-power timer interrupts
5
PSoC™ active to Hibernate
transition
Firmware (enter hibernate) transitions from active to
Hibernate mode
6
PSoC™ transitions to reset
state
Any reset event including hibernate wakeup, external reset,
etc.

Application note
9
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
Low-power overview
Transition
Description
Trigger
7
AIROC™ CYW43012 Wi-Fi &
Bluetooth® combo chip reset
to active transition
External events transition AIROC™ CYW43012 Wi-Fi &
Bluetooth® combo chip out of reset; either BT_REG_ON or
WL_REG_ON pulled HIGH by PSoC™ 6 MCU.
8
AIROC™ CYW43012 Wi-Fi &
Bluetooth® combo chip active
to Deep Sleep transition
AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip enters DS0
mode; managed by on-chip PMU and requires enabling power
save in the device
9
AIROC™ CYW43012 Wi-Fi &
Bluetooth® combo chip Deep
Sleep to active transition
External events or PMU transitions AIROC™ CYW43012 Wi-Fi &
Bluetooth® combo chip to active mode; possible PSoC™ 6 MCU
actions:
•BT_DEV_WAKE
•SDIO interrupt
10
AIROC™ CYW43012 Wi-Fi &
Bluetooth® combo chip
transitions to reset state
External events transition AIROC™ CYW43012 Wi-Fi &
Bluetooth® combo chip to reset state; both WL_REG_ON and
BT_REG_ON are pulled LOW by PSoC™ 6 MCU.
11a
PSoC™ transitions to OFF
state
Power supply removed from PSoC™ 6 MCU (Power Down)
11b
AIROC™ CYW43012 Wi-Fi &
Bluetooth® combo chip
transitions to OFF state
Power supply removed from AIROC™ CYW43012 Wi-Fi &
Bluetooth® combo chip (Power Down)
Note: a PSoC™ 6 MCU power modes are represented in a simplified form for ease of depicting the
transitions. See Table 2 for details.

Application note
10
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
WLAN power optimization techniques
3WLAN power optimization techniques
3.1 IEEE 802.11 (Wi-Fi) power saving
Topics in this section are partly based on information contained in IEEE 802.11 specification document. The
802.11 standard includes several parameters that allow stations to save power, although power saving is
accomplished at the expense of throughput or latency to the station.
This section only provides an overview of power-saving methods and associated terms from the IEEE
specification. If you are already familiar with the topic and interested in the implementation, see Wi-Fi power
save implementation.
3.1.1 Beacon interval
Beacon frames are periodic frames broadcast by the Wi-Fi access points (APs) to communicate throughout the
serviced area the characteristics of the connection offered to the Wi-Fi stations (STAs). This information is used
by STAs trying to connect to the network as well as STAs already associated with the Basic Service Set (BSS).
The period at which beacon frames are transmitted is called “Target Beacon Transmission Time” (TBTT) or
simply “Beacon Interval”. even though the beacon interval is configurable for a given AP, it is typically set to
102.4 ms (100-time units, where the 1-time unit is 1024 µs per 802.11 specifications). The beacon interval
information is available as part of the beacon frame itself. See the 802.11 specification for details. In addition,
each beacon includes a Traffic Indication Map (TIM) that contains information regarding packets buffered for
STAs. It is the responsibility of the STAs to read the TIM and retrieve the packets destined for them.
3.1.2 Listen interval
To save power, STAs sleep by powering down most of the Wi-Fi subsystem. While the STAs are asleep, APs
buffer frames for them and indicate the availability through beacon TIMs. The sleeping STAs periodically wake
up to listen to traffic announcements (TIMs) and determine whether the AP has any buffered frames. When
STAs associate with an AP, part of the data in the Association Request frame is the listen interval. The listen
interval indicates to the AP the frequency at which a power save station will wake up to listen to beacon frames.
An AP may use the listen interval as a guide to determine the duration it should retain buffered frames for a
power save station. Larger listen intervals require more AP memory for frame buffering.
In reality, APs generally do not consider the listen interval requested by an STA. If an STA sets the listen interval
to a value, there is no guarantee that the AP will buffer all the packets received for the station while the station
is asleep. In addition, if the AP supports Delivery Traffic Indication Map (DTIM), that setting may override the
listen interval requested by STAs.
Most APs enforce an association timeout on stations, i.e., if the AP has not received a frame from a station
within the association timeout (usually 60 seconds) or the station has not returned an ACK to a keep-alive
frame, the station will be disassociated. The association timeout cannot be negotiated by the station.
3.1.3 DTIM period
The DTIM period is a parameter associated with an infrastructure network and is advertised in the AP Beacon
frame. The polled approach using standard TIMs is not suitable for multicast and broadcast frames, because it
takes too much capacity to transmit multicast and broadcast frames multiple times. Instead of the polled
approach, broadcast and multicast frames are delivered after every DTIM interval.

Application note
11
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
WLAN power optimization techniques
Increasing the DTIM allows stations to conserve power more effectively at the cost of buffer space in the AP and
delays in the reception of multicast and broadcast frames by all stations, including stations in active mode.
It should be noted that the listen interval is recommended to be equal to (or less than) the DTIM period for the
STA to receive all unicast, multicast, and broadcast packets. This ensures an optimal power and latency
tradeoff.
Usually, the DTIM period is set as the number of beacon intervals in the AP. The default DTIM period for most
APs is either DTIM=1 (DTIM every beacon), DTIM=3 (DTIM every third beacon), or DTIM=10. In the case of DTIM=3,
the station needs to only wake from low-power mode to receive every third beacon and any ensuing queued
broadcast or multicast traffic.
Figure 2 explains the beacon interval, listen interval, and DTIM period in an infrastructure network.
DTIM period = 3 beacon interval
Beacon with
TIM
DTIM
STA1
(Wakes up every DTIM)
AP
Listen Interval (STA1) =3 beacon interval
Listen Interval (STA2) =4 beacon interval
STA2
(Not interested in broadcast/
multicast traffic)
Beaconinterval
STAs listening
to beacon
Figure 2 802.11 infrastructure network operation
3.1.4 Power saving methods
Although the 802.11 transmitted power consumption is at least five times higher than the received power
consumption, even for medium transmit-duty-cycle applications, much of the energy in a battery-powered Wi-
Fi station is consumed by the receiver. Unless power save techniques are used, the 802.11 receiver may be
powered ON for significant periods of time while the station waits for network clients to respond to requests. It
does not take very long for a 130-mW receiver power consumption to discharge a battery.
Wi-Fi STAs use different mechanisms to save power. STAs with low duty cycle and long battery life
requirements, Wi-Fi sensors, for example, may use the standard 802.11 Power Save Poll (PS-Poll) mechanism.
STAs requiring higher throughput, wireless speakers, for example, may consider using a non-standard 802.11
power save mechanism. These methods are described in this section.
Note: STAs requiring a more fine-grained power save mechanism to differentiate power save for various
traffic priorities may consider using unscheduled automatic power save delivery (U-APSD) or Wi-Fi
multimedia (WMM) power save. AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip currently does
not support WMM power save.

Application note
12
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
WLAN power optimization techniques
3.1.4.1 Power save poll
Power save poll suits for STAs that primarily transmit data to the Wi-Fi network at low-duty cycles. The PS-poll
mechanism works as follows:
1. STA sends a frame to the AP with the Power Management bit set and then goes to sleep.
2. AP notes that the STA has gone to sleep, and buffers frames for the STA.
3. STA wakes up periodically to check the AP beacon frame for an indication of buffered frames. The wake
period depends on the configured listen interval and whether the STA is configured to receive group-
addressed frames from a beacon containing a DTIM.
4. If the AP indicates that it has buffered frames addressed to the STA, the STA sends a PS-Poll frame to the AP.
5. The AP sends a frame to the STA and sets the ‘More Data’bit if additional frames are buffered.
6. The STA might send another PS-Poll frame to retrieve additional buffered frames (if the More Data bit was
set) or return to sleep.
7. When the STA needs to transmit data, it can wake up and transmit data anytime without waiting for the
beacon interval as AP is active all the time.
DTIM = 3
PS-Poll from STA1 Data for STA1
TIM with data for
STA1
Beacon with
TIM
DTIM
Slave listening to Beacon @ DTIM interval
STA1
(With PS-Poll)
AP
Figure 3 Power save poll
3.1.4.2 802.11 power save without poll
A non-standard mechanism known broadly as 802.11 power save without poll (PS-non-poll) enables STAs to
use 802.11 power saving based on a ‘trigger’ frame as follows:
1. STA sends a frame to the AP with the ‘Power Management’bit set and then goes to sleep.
2. AP notes that the STA has gone to sleep and buffers frames for the STA.
3. STA wakes up periodically. The STA may (or may not) first check the AP beacon frame for an indication of
buffered frames before sending any frames to the AP.
4. The STA sends a Null Function data frame, or a data frame if available, to the AP with the Power
Management bit cleared.
5. The AP notes that the STA is awake and sends buffered frames.
6. STA receives the frames, waits for a timeout period to receive additional frames (if available), and then
returns to sleep as described in Step 1.

Application note
13
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
WLAN power optimization techniques
DTIM = 3
Null frame from STA1
with PM bit cleared
Data for STA1
TIM with data for
STA1
Beacon with
TIM
DTIM
Slave listening to Beacon @ DTIM interval
STA1
(With PSwithout
Poll)
AP
Figure 4 Power save without poll
3.1.4.3 Association timeout limit
If an STA does not expect to receive directed frames from the AP asynchronously, and it is not interested in
receiving broadcast or multicast traffic, then further power savings may be achieved.
Because APs generally have an association timeout limit with a default value of 60 seconds, an STA that uses
power save must wake up before the association timeout expires and send or receive a directly addressed
frame to inform the AP that the STA is still associated. Failure to comply results in the AP de-authenticating the
STA. Some APs allow the association timeout limit to be set to a value higher than 60 seconds, but the higher
limit is not signaled to the station and must be manually configured.
3.1.5 802.11ac-friendly features
AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip provides 802.11ac friendliness by supporting 256-QAM (for
20-MHz channels in the 5-GHz band) enabling data rates of up to 78 Mbps with 802.11ac APs. This enables
superior throughput and reduced power consumption in the device by sending/receiving data and then going
back to sleep faster. In addition, it supports 802.11ac's ‘explicit beamforming’feature to offer significantly
higher throughputs than 802.11n chipsets at any given range.
3.2 Wi-Fi power save implementation
3.2.1 Wi-Fi Host Driver (WHD) power save interface
The power save implementation is provided as part of the WHD library. In addition, platforms such as FreeRTOS
implement their power save mechanisms on top of the WHD to provide users with seamless low-power
integration.
Table 4 describes the low-level functions available as part of WHD providing various power save features. Refer
to the WHD API reference guide for details.
Table 4 WHD power save APIs
WHD API
Description
whd_wifi_enable_powersave()
Enables PS-poll mode in the device (see Power save poll)

Application note
14
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
WLAN power optimization techniques
WHD API
Description
whd_wifi_enable_powersave_with_t
hroughput()
Enables 802.11 PS-non-poll mode in the device (see 802.11
power save without poll). Use this mode when it is important to
maintain throughput.
whd_wifi_disable_powersave()
Disables power save mode in the device; by default, power save
is enabled in the WLAN device.
whd_wifi_set_listen_interval()
Sets the number of beacons to be skipped while the Wi-Fi chip is
sleeping. Only works when Wi-Fi power save is enabled and the
DTIM interval broadcasted by the AP is zero (i.e., no DTIM in the
network).
whd_wifi_get_listen_interval()
Gets the current value of all beacon listen interval variables
It should be noted that power save with throughput is enabled in the WLAN device by default. The
enable/disable power save APIs can be called to change or disable power save option in the WLAN. The WLAN
automatically manages the entry and exit of DS0 after the power save is enabled. The mtb-example-wifi-wlan-
lowpower code example demonstrates the use of WHD power save APIs.
An example implementation of a power save handler using WHD APIs in ModusToolbox™ is as follows:
Code Listing 1 Example: Power save handler using WHD APIs in ModusToolbox™
cy_rslt_t wlan_powersave_handler(struct netif *wifi, enum wlan_powersave_mode_t
mode)
{
cy_rslt_t result = CY_RSLT_SUCCESS;
whd_interface_t ifp;
whd_security_t security_param;
whd_bss_info_t ap_info;
if (wifi->flags & NETIF_FLAG_UP)
{
/* Get the instance of the WLAN interface.*/
ifp = (whd_interface_t)wifi->state;
/* Obtain network parameters configured in the AP.*/
result = whd_wifi_get_ap_info(ifp, &ap_info, &security_param);
if (CY_RSLT_SUCCESS == result)
{
APP_INFO(("Beacon period = %d, DTIM period = %d\n",
ap_info.beacon_period, ap_info.dtim_period));
}
else

Application note
15
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
WLAN power optimization techniques
Code Listing 1 Example: Power save handler using WHD APIs in ModusToolbox™
{
ERR_INFO(("Failed to get AP info.\n"));
}
/* Configure power-save mode of the WLAN device.*/
switch (mode)
{
case POWERSAVE_WITHOUT_THROUGHPUT:
result = whd_wifi_enable_powersave(ifp);
if (CY_RSLT_SUCCESS != result)
{
ERR_INFO(("Failed to enable PM1 mode\n"));
}
break;
case POWERSAVE_WITH_THROUGHPUT:
result = whd_wifi_enable_powersave_with_throughput(ifp,
RETURN_TO_SLEEP_MS);
if (CY_RSLT_SUCCESS != result)
{
ERR_INFO(("Failed to enable PM2 mode\n"));
}
break;
case POWERSAVE_DISABLED:
result = whd_wifi_disable_powersave(ifp);
if (CY_RSLT_SUCCESS != result)
{
ERR_INFO(("Failed to disable powersave\n"));
}
break;
default:
APP_INFO(("Unknown mode\n"));
break;
}
}

Application note
16
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
WLAN power optimization techniques
Code Listing 1 Example: Power save handler using WHD APIs in ModusToolbox™
else
{
ERR_INFO(("Wi-Fi interface is not powered on. Failed to configure power-
save mode\n"));
result = CY_RSLT_TYPE_ERROR;
}
return result;
}
3.2.2 Cyclic timers in network stack
Platforms that implement network stacks, such as lightweight TCP/IP stack (lwIP), run periodic timers for
various network-related activities. These timers are used as ticks for network activity such as address
resolution protocol (ARP) cache table expiry and dynamic host configuration protocol (DHCP) lease renewal
timeouts. The period of these timers can vary from 100 ms to 60 s. The host waking up periodically to service
these timers is required for proper functioning. However, if the application desires to suspend these timers
when it does not anticipate any network timeout activity and for a longer stay in low-power modes, there is an
option to suspend and resume the network stack.
This feature is provided as part of the low power assistant middleware helper files. The wait_net_suspend()
API is available in the lpa/helpers/net_activity/network_activity_handler.h file lets you suspend the network
stack for a predefined duration or until an activity is detected, if the network remains inactive within a given
time window. This API function lets you safely suspend the network and resume it whenever any network
activity gets detected. Figure 5 shows the wait_net_suspend() operation in different scenarios with network
suspend duration of 5000 ms, network inactivity monitor window of 150 ms, and network inactivity duration of
100 ms.
Scenario 1: wait_net_suspend() detects no network activity for more than 100 ms within the 150-ms
window and suspends the network. No network activity is detected for the network suspend duration of 5000
ms. Therefore, wait_net_suspend() resumes the network stack after 5000 ms.
Scenario 2: wait_net_suspend() detects network activity in the 150-ms window and inactivity is less than
100 ms. wait_net_suspend() does not suspend the network stack.
Scenario 3: wait_net_suspend() detects no network activity for more than 100 ms within the 150-ms
window and suspends the network. Network activity is detected before the expiry of 5000 ms duration.
Therefore, wait_net_suspend() resumes the network stack immediately.

Application note
17
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
WLAN power optimization techniques
150 ms
100 ms
wait_net_suspend (wifi,
5000, 150, 100) Network resumes
automatically
after 5000 ms
Network inactive > 100 ms;
Suspend network s tack
Window to monitor
network inactivity
5000 ms
150 ms
Network activitydetected Network
inactive < 100 ms
Do not suspend network stack
150 ms
100 ms
Network inactive > 100 ms;
Suspend network s tack
Network activity detected < 5000 m s
Resume network stack
No Network activity
Network active
Scenario#1
Scenario#2
Scenario#3
Figure 5 wait_net_suspend() operation
If you are using ModusToolbox™ software, see the mtb-example-wifi-wlan-lowpower code example for details
on using the network suspend feature safely.
See lpa middleware documentation for additional details on these timers.
3.3 Host offloads to WLAN device
AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip has an Arm® Cortex®-M3 core that performs all the WLAN
device activities and supports various offloads that execute certain functionalities on behalf of the host without
interrupting the host state.
Host offloads play a key role in determining host power consumption because offloads let the host go into
Deep Sleep for extended periods of time while the WLAN device handles tasks such as 802.11 roaming, ARP,
IPv6 neighbor resolution, key rotation, and TCP keepalives on behalf of the host. In addition, these offloads free
the host CPU for other, more powerful tasks such as audio or sensor data processing. This in turn improves the
overall system efficiency and power.
The following sections describe offloads supported by AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip. The
offloads can be enabled using the Infineon low power assistant middleware. Using the LPA middleware in
ModusToolbox™ is explained in Low power assistant (LPA).
3.3.1 ARP offload
ARP is a data link layer protocol for mapping an IP address to a physical MAC address of a device. Such mapping
is necessary for any WLAN device to keep updated on [IP:MAC] details of all nearby devices in its network. Using
the ARP protocol, a device can detect duplicate IP addresses in a network. This is also useful in notifying peer
devices of an IP address change.

Application note
18
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
WLAN power optimization techniques
Because ARP request and response packets are a common activity in any WLAN network, the host device
usually gets flooded by many requests; the host needs to remain active to respond to such requests, especially
in a crowded network. ARP requests packets from a peer and usually wakes the host if it is sleeping. The ARP
offloading feature in AIROC™ Wi-Fi & Bluetooth® combo chip handles responding to ARP requests from a peer so
that these requests will not disturb the host. The AIROC™ Wi-Fi & Bluetooth® combo chip device holds a cache
(of 8 entries); the host will be woken up only if there is a cache miss as shown in Figure 6.
In addition to auto-replying to peers, AIROC™ Wi-Fi & Bluetooth® combo chip can use the cache to reply to the
host (PSoC™ 6 MCU) as well when the host sends an ARP request to the network. This host auto-reply feature
works similarly to a Peer auto-reply, where a cache miss is forwarded to the network and a cache hit returns an
ARP response immediately to the host. This feature is complemented by the ability of the AIROC™ Wi-Fi &
Bluetooth® combo chip device to snoop ARP info from host-network communication, i.e., whenever a host
sends an ARP response packet over to the network, the [IP:MAC] information is cached into the AIROC™ Wi-Fi &
Bluetooth® combo chip ARP cache table.
Figure 6 ARP offload feature
3.3.2 Packet filter offload
Packet filters allow the host to limit the types of packets that get passed up to the host processor from the
WLAN device. This is useful to keep out unwanted packets from the network that might otherwise wake the
host out of a power-saving Deep Sleep mode or prevent it from entering Deep Sleep mode.
In general, whenever a WLAN packet is destined for the host, the WLAN device must awaken the host (if it is
asleep) so that the host can retrieve the packet for processing. Often, the host network stack processes the
packet only to discover that the packet should be thrown away because it is not needed such as when the
packet is destined for a port or service that is not being used. Packet filters allow these types of packets to be
filtered and discarded by the WLAN processor itself so that the host is not interrupted.
In short, packet filters are useful when:
•You want to keep the host processor in Deep Sleep for as long as possible (or enter Deep Sleep as soon as
possible) by filtering unwanted traffic.

Application note
19
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
WLAN power optimization techniques
•You want to keep the host processor involvement to a minimum by filtering and passing only the wanted
traffic to it.
Filters can be configured to be active either when the host processor is active or asleep (or both). Multiple filters
may be configured to operate simultaneously. One set can be functioning while awake and a separate set can
function while sleeping and can be used to wake the host. In addition, filters can be configured to either discard
or keep (send to host). When configured to discard, only the specified packets are discarded, while any others
not specifically filtered are passed to the host. Conversely, when configured to keep packets, only the specified
packets are passed to the host, and the rest are discarded.
A typical model would be to use only 'keep' filters, where the application is aware of all the types of packets it
needs to process. In other words, use 'keep' filters to specify the complete list of packet types the host is
interested in and discard the rest. This is preferred as it is much simpler to list the packets the host wants to
receive versus creating a complete list of packets it does not want. When using keep filters, care must be taken
to allow enough packets through for networking protocols to work properly.
For example, while awake, the processor must be able to join a network, get a DHCP address, run ARP, and
possibly share network keys. Not creating enough keep filters to allow these types of packets through will
prevent the host from even joining the network. A reasonable minimal set of keeping filters should include:
•ARP (allow ARP packets)
•IEEE 802.1X (allow security packets)
•DHCP (UDP port 68)
•DNS (UDP port 53)
There is no minimum set of filters required when enabling discard filters. However, it should be noted that all
the filter types in the offload must be either keep or discard and not a mix of both. This is because the
complementary nature of the keep and discard filters will result in unexpected behavior.
Three types of packet filters are supported in AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip based on a
standard network stack as seen in Figure 7, which shows the relationships between stack layers, protocols, and
packet filters.
Figure 7 Packet filters

Application note
20
002-27910 Rev. *C
2023-05-29
Low-power system design with AIROC™ Wi-Fi & Bluetooth® combo
chip and PSoC™ 6 MCU
WLAN power optimization techniques
Note: In the AIROC™ CYW43012 Wi-Fi & Bluetooth® combo chip, the number of discard packet filter
offload is limited to one, i.e., only one discard packet filter can be enabled in the design; enabling
more than one discard filter will let all packets to pass through (no filter).
3.3.2.1 Network layer or EtherType filter
The EtherType filter filters packets based on a 16-bit EtherType field present in Ethernet packets seen at the
network layer (see Internet Assigned Numbers Authority (IANA)). The most commonly used protocols (and most
useful filters) are:
•IP (EtherType = 0x800)
•ARP (EtherType = 0x806)
•IEEE 802.1X or EAP over LAN (EtherType = 0x888E)
Filtering on IP EtherType would match all IP packets coming from the network. This is a very coarse filter and
will include all ICMP, TCP, and UDP packets as shown in Figure 7. Filtering on ARP or IEEE 802.1X is finer; it will
only match respective packets. Filtering all IP packets will have an enormous impact due to the substantial
number of packets it will match and is generally not recommended for typical usage. Valid EtherType filters
consist of a 16-bit number greater or equal to 0x800.
3.3.2.2 Transport layer/IP protocols
The next layer up the stack is the Transport layer, which consists of various IP-based protocols such as TCP,
UDP, and ICMP. Discussions of the protocols themselves are outside the scope of the application note but are
widely available and a list of protocol numbers can be found in numerous sources such as IANA.
IP Protocol filters consist of a single 8-bit number. The filters do not perform any validation check on this 8-bit
number and simply filter the packets matching the number. This is because vendors can use proprietary
numbers and protocols at this layer. It should be noted that filtering on TCP/UDP protocols is still coarse and
will likely include most packets destined for the host processor (depending on the application). Application
layer filters that are based on port numbers are the next level of filter refinement providing finer control on the
majority of packets received in the network.
3.3.2.3 Applications layer/TCP and UDP port numbers
Application layer filters or simply port filters perform packet filtering based on the source or destination port of
a transport layer packet. These port numbers are well-known numbers used to identify various TCP- and UDP-
based protocols. (see IANA). These are 16-bit port numbers. For example, with a port filter, a user can filter on
only SSH packets (port 22) or only on FTP packets (port 20), or any other of the many applications
supported. Due to the large number and constantly changing port definitions, the filters do not validate the
port numbers against available applications.
Transport layer packets have both source and destination ports. Destination ports are the well-known port
numbers described in the IANA link and are generally the most useful. Source ports describe temporary,
ephemeral port numbers used by the host sending the packets and are generated on-the-fly and are not well
known. Because source ports are not known ahead of time, creating a source port filter is difficult. Filters can
be designed to filter a range of ports (between a start and end port) to match a wide range of source ports to
cover this case. Both TCP and UDP use port numbers; therefore, filters can be designed to select TCP or UDP. If
both TCP and UDP need to be filtered for a port, two filters can be created.