Skip navigation
Home > All Places > WICED Studio Wi-Fi/Combo > WICED Studio Wi-Fi/Combo Forums > Blog > 2017 > November



This blog discusses about the usage of PWM module of CYW943907AEVAL1F in WICED SDK 6.0. The CYW43907 provides up to six independent PWM channels. The PWM pins for CYW943907AEVAL1F EVK are as shown in the table below.


Enum ID




WICED Peripheral




The PWM pins can be re-assigned to different I/Os using the pin mux functionality in "platform_pwm_peripherals" at

<WICED SDK>/43xxx_Wi-Fi/platforms/CYW943907AEVAL1F/platform.c.


In order to re-assign a PWM, just change the first argument in the entry for that row to the desired pin name. For example, to re-assign WICED_PWM_1 to PIN_GPIO_0, just change PIN_GPIO_10 to PIN_GPIO_0.


const platform_pwm_t platform_pwm_peripherals[] =


   [WICED_PWM_1]  = {PIN_GPIO_10,  PIN_FUNCTION_PWM0, },   /* or PIN_GPIO_0, PIN_GPIO_8,  PIN_GPIO_12, PIN_GPIO_14, PIN_GPIO_16, PIN_PWM_0   */




PWM Features


The following features apply to the PWM channels:

  • Each channel is a square wave generator with a programmable duty cycle.
  • Each channel generates its duty cycle by dividing down the input clock.
  • Both the high and low duration of the duty cycle can be divided down independently by a 16-bit divider register.
  • Each channel can work independently or update simultaneously.
  • Pairs of PWM outputs can be inverted for devices that need a differential output.
  • Continuous or single pulses can be generated.
  • The input clock can either be a high-speed clock from a PLL channel or a lower speed clock at the crystal frequency.


Different APIs in WICED for PWM


PWM APIs used in WICED are given below.


wiced_result_t wiced_pwm_init ( wiced_pwm_t pwm, uint32_t frequency, float duty_cycle )


This API initializes a PWM pin. Prepares a Pulse-Width Modulation pin for use. Does not start the PWM output.


[in]pwm: The PWM interface which should be initialized
[in]frequency: Output signal frequency in Hertz
[in]duty_cycle: Duty cycle of signal as a floating-point percentage (0.0 to 100.0)


     WICED_SUCCESS : on success.
     WICED_ERROR : if an error occurred with any step


wiced_result_t wiced_pwm_start ( wiced_pwm_t pwm )


This API starts Pulse-Width Modulation signal output on a PWM pin


[in]pwm: The PWM interface which should be started


     WICED_SUCCESS : on success.
     WICED_ERROR : if an error occurred with any step


wiced_result_t wiced_pwm_stop ( wiced_pwm_t pwm )


This API stops output on a PWM pin.


[in]pwm: The PWM interface which should be stopped


     WICED_SUCCESS : on success.
     WICED_ERROR : if an error occurred with any step

APIs are explained in <WICED SDK>/43xxx_Wi-Fi/doc/API.html at Components > Platform functions > PWM and also at <WICED SDK>/43xxx_Wi-Fi/include/wiced_platform.h in WICED SDK6.0.


Testing the Application


  1. Download the PWM application attached with this blog post extract and add the downloaded folder "pwm" to "snip" folder in <WICED SDK>/43xxx_Wi-Fi/apps/.
  2. Create a make target for the application. Example: snip.pwm-CYW943907AEVAL1F download run.
  3. Connect CYW943907AEVAL1F EVK to PC and run the make target by double clicking on it.
  4. After the application is compiled and downloaded, it will start running. You can see the messages in serial terminal like "putty" or "Tera Term".



You can change the frequency of PWM by using the API wiced_pwm_init ( wiced_pwm_t pwm, uint32_t frequency, float duty_cycle ). The figure below shows the screen capture of PWM with 1MHz frequency.



Once the application starts running, whenever the button USER_1 is pressed, interrupt service routine (button1_isr()) is called. Application is written in such a way that the duty cycle get reduced by 5% every time USER_1 button is pressed hence the brightness of LED_1 reduces.

This Help article discusses how to effectively execute multiple applications on the CYW943907AEVAL1F evaluation platform. To achieve switching between applications, you put device into deep sleep when current application is running and load another application when device resumes. WICED Application Framework (WAF) supports loading and storing of multiple application binaries in the external sflash. You can set the platform to execute any of the stored binaries.


There are three binaries APP0, APP1 and APP2 where you can store three different applications. By default APP0 application executes whenever we download the program.

There are two requirements for the application to perform switching:

  • All applications must use the same Application DCT.
  • All applications must use the same AON (Always ON) RAM defines.


In WICED SDK 5.0 and above, apps\snip contains two applications satisfying above requirements: multi_image_0 and multi_image_1.

multi_image_0 application prints text on console showing that application 0 has started and multi_image_1 application prints text showing that application 1 has started.

To set the APP0 to point to second application, check for following lines in the make file

          APP1_FILE = snip.multi_image_1-$(PLATFORM)  

          APP1 = build/$(APP1_FILE)/binary/$(APP1_FILE).stripped.elf


To test the application, make following targets and build in the given order:


          snip.multi_image_0-CYW943907AEVAL1F download download_apps run


When downloading to the device, the sflash_write application sets the device in an "always on" state. In this state, the device will not go into deep sleep. In order to use this feature you must power cycle the device before you can test. For more details, go through README.txt in multi_image_0 folder.


After downloading the program, you will see following text on UART terminal.

Now power cycle the device.

To see the information about AON RAM variables, use command info.

To switch the application, use command switch.

After putting these commands, you will see second application loaded as follows.

This blog tries to provide a guide for using IOCTL commands. Essentially, WL commands are functions that send an IOCTL or sequence of IOCTLs and process the received data. An alternate way to achieve the same is directly using IOCTL/IOVAR commands. IOCTL  basically stands for "input-output control", which are used to define device-specific system call (in specific WLAN calls). A driver can define an IOCTL which allows APPS Core (ACPU) application to send commands to the WLAN driver; which can ultimately be used to update the configurations of the WLAN. Any user application API internally calls the IOCTL/IOVARs to communicate with the WLAN core. The host interface between WLAN subsystem (WCPU) and the host processor (ACPU) is through the memory to memory DMA engine which uses Cypress proprietary SDPCM protocol for this communication. The SDPCM protocol provides multiplexing of data packets, IOVAR/IOCTL, and asynchronous event signalling allowing a communication between host driver and WLAN firmware.


To use the IOCTL/IOVAR commands directly from the application, the user can use the WWD APIs listed in WICED SDK. For wifi related parameters (like getting the RSSI, setting the transmit antenna, checking the active antenna), the APIs' can be found in wwd_wifi.c. The list of  valid IOCTLs are  provided in


Similarly, the list of valid IOVARs are provided in


The definition of the above-mentioned IOVARs for the specific platform are provided in



The APIs used to send an IOCTL/IOVAR command or receive a status of  an IOCTL/IOVAR are given by wwd_wifi_set_ioctl/iovar_value and wwd_wifi_get_ioctl/iovar_value. For instance, to set the transmit antenna the format of this API should be


wwd_wifi_set_ioctl_value(WLC_SET_TXANT, 1, WWD_STA_INTERFACE)


The WLC_GET_VAR and WLC_SET_VAR IOCTLs provide a method of getting and setting internal wl driver state values.

  • WLC_GET_VAR takes a NULL-terminated ASCII string name
  • WLC_SET_VAR takes a NULL-terminated ASCII string name followed by an optional value


The name of the IOCTL (WLC_SET_TXANT) used in the example usage of APIs could be located in




A sample application is provided here to test the RSSI using IOCTLs, scan association time using IOVARs and the same is verified using standard WL commands (wl phy_rssi_ant, wl scan_assoc_time).


This Help Article explains the low power measurement using applications available in WICED Studio 6.0 for CYW943907AEVAL1F evaluation kit.


A low power app note is available in WICED 6.0  at 43xxx_Wi-Fi/doc/WICED-Powersave-App-Note.pdf for CYW94390x, STM32 and AT91SAM4S.


1. Board Rework: Following modification has to be made in CYW943907AEVAL1F to measure power consumption.

    1. Remove R41.
    2. Remove R55.
    3. Short respective terminals of R41 and R55 as shown in the Figure 2.b and jump wires for ammeter connection.

     Note: Short wires at R41 & R55 terminals to a common ammeter terminal to measure IVBAT+IVDDIO as shown in Figure 1 below.


Board Modifications.png

Figure 1. Board Modification


IMG_20171123_111604 edited.jpg

Figure 2.a. CYW943907AEVAL1F Before Rework


IMG_20171123_152938 edited2.jpg

Figure 2.b. CYW943907AEVAL1F After Rework


2. Testing


     i. Make the connections as shown in the figures 3.a and 3.b.

IMG_20171123_153043 edited.jpg

Figure 3.a. CYW943907AEVAL1F Bottom.


IMG_20171123_153515 edited.jpg

Figure 3.b. CYW943907AEVAL1F Top.


     ii. Create make target, download and run applications mentioned in section 3 below .



3. Example Power Save Applications for CYW943907AEVAL1F:


     i. Application Sleep (Deep Sleep)- 43xxx_Wi-Fi/apps/test/apps_sleep


In this example, the application:

        • Periodically goes to Deep Sleep in a co-operative way.
        • Wakes up through timer.
        • Saves variables in Always On RAM (AONRAM) and verifies them after warm boot.
        • Registers event handlers for entering and leaving Deep Sleep. Does not load firmware to WLAN side.

apps_sleep 1.png

Figure 4. apps_sleep.c- Power Consumption on CYW943907AEVAL1F board ~360uA in Deep Sleep (at Marker 2)


     ii. Ping Deep Sleep (Deep Sleep + Networking)- 43xxx_Wi-Fi>/apps/snip/ping_deepsleep


In this example, the application:

        • Connects to Access Point (AP) and pings AP periodically.
        • Periodically goes into Deep Sleep in a Co-operative way.
          • Checks for networking to be idle.
          • Suspends networking stack.
        • Resumes networking after coming out of Warm boot.


ping_deepsleep 0.png

Figure 5. Ping Deep Sleep- Average power consumption ~1.45mA (between markers 1 and 2)


     iii. Ping Power Save- 43xxx_Wi-Fi/apps/snip/ping_powersave/ping_powersave.c


In the ping_powersave demo:


        • The system connects to AP and periodically pings the AP.
        • In between pings, the system suspends network timers and enters low-power mode (Sleep) for WIFI_SLEEP_TIME( by default 1 second - defined in ping_powersave.c) seconds.
        • The system resumes network timers when coming out of sleep.


ping_powersave 0.png

Figure 6. Ping Power Save- Average current consumption ~61.15mA (between markers 1 and 2)



    iv. Powersave (Deep Sleep + Sleep Use Cases)- 43xxx_Wi-Fi/apps/test/powersave/powersave.c


        • Console-based application
        • Commands can be
          • Entered using UART console
          • Statically compiled
        • Following features are supported


Change POWERSAVE_STANDALONE_TEST_DEEPSLEEP_NO_ASSOC to 1 and keep all other tests 0 in powersave.c as shown below,


NO_ASSOC deep sleep 0.png

Figure 7. Power Save- Average current consumption ~1.14mA (between markers 1 and 2)


Change POWERSAVE_STANDALONE_TEST_DEEPSLEEP_ASSOC to 1 and keep all other tests 0 in powersave.c as shown below,


ASSOC 0.png

Figure 8. Power Save- Average current consumption ~1.54mA (between markers 1 and 2)


Change POWERSAVE_STANDALONE_TEST_WAIT_FOR_WLAN to 1 and keep all other tests 0 in powersave.c as shown below,



Figure 9. Power Save- Average current consumption ~40.43mA (between markers 1 and 2)


Change POWERSAVE_STANDALONE_TEST_ACTIVE_WAIT_FOR_WLAN to 1 and keep all other tests 0 in powersave.c as shown below,



Figure 10. Power Save- Average current consumption ~11.90mA (between markers 1 and 2)


Change POWERSAVE_STANDALONE_TEST_LOW_POWER_NETWORKING to 1 and keep all other tests 0 in powersave.c as shown below,



Figure 11. Power Save- Average current consumption ~111mA (between markers 1 and 2)


Change POWERSAVE_STANDALONE_TEST_WAKEUP_FROM_DEEP_SLEEP_PROFILE to 1 and keep all other tests 0 in powersave.c as shown below,



Figure 12. Power Save- Average current consumption ~901uA (between markers 1 and 2)

An Over-The-Air (OTA) update is wireless delivery of new software or data, configuration settings to device. In WICED, there are two snips to demonstrate OTA updates: apps/snip/ota_fr and apps/snip/ota2_example.

The update mechanism of OTA supports starting a SoftAP and perform a manual upload of a new application to replace the current application.

OTA2 has more functionalities compared to OTA.

Please refer to WICED-OTA2.pdf available in 43xxx_Wi-Fi\doc folder of WICED SDK Installation directory for more information about OTA2.


The major differences between OTA and OTA2 are tabulated below:




Update Bootloader



Update main application



Update check can be timed periodically



Update components checked with CRC


Yes, upon download and at extraction.

Update All parts of system


Yes, excluding bootloader

Keep User DCT Settings

(DCT untouched)


DCT saved to separate area. Application must explicitly update the DCT data


OTA: Please follow the link for testing ota_fr snip: WICED OTA Upgrade and Factory Reset (SDK 3.1.2 through WICED Studio 4.x)

OTA2: Please follow the link for testing ota2_example snip: OTA2 Update for SDK-3.7.0

Further implementation details of OTA2 are mentioned here:

OTA2 implementation requires nearly 8 MB memory. The memory requirements are shown in the table. In WICED, the memory map for CYW943907AEVAL1F is defined in: 43xxx_Wi-Fi\platforms\CYW943907AEVAL1F\

16KBootloader(Bootloader size can be <32K but for secure boot it should be <16K)
128KOTA2 Failsafe Application(snip/ota2_failsafe)

OTA2 Image- Factory Restore Area

(includes reset DCT+LUT*+filesystem+OTA2 Extractor**+Application size)

16KOTA2 DCT Save area (used to keep the DCT data after an upgrade so that DCT data can be recovered)
32KDCT copies(DCT1 and DCT2)
4KApplication Look up Table(LUT*)
512KFilesystem(includes WiFi Firmware)
256KOTA2 Extractor**(can start using SoftAP,DHCP server and Web Server)
256KMedium sized Application(WiFi)

OTA2 Image- Staging Area

(includes new DCT+LUT* filesystem+OTA2 Extractor**+Application size)


TOTAL + Application Size

*LUT: Look Up Table- in the WICED Multi-Application Framework, this is a directory where the system(App, DCT, Resources) is located in FLASH.

**OTA2 Extractor is an application which extracts the application images and loads in the current application area.


The highlighted area in the table shows the images that OTA2 works with. There are 3 images:

  1. Current application image: This is the current application running in your device.
  2. OTA2_image- Staging Area: This is the image to be updated and it is stored in the staging area in memory. There is support for background downloading of OTA2 Update image from file server or manually providing the image through web server.
  3. OTA2_image- Factory reset image: If the device enters an unknown state during update (due to power loss or connection loss or error in extraction of ota2_image), this image is extracted and is loaded in the current application area. On a power loss error, the ota2_extractor first tries to extract the last thing that was being extracted. So if the image in the staging area was being extracted and the power failed, the system will first try to use the staging area before resorting to the Factory Reset Area.

Different type of images that can be generated in WICED are:

  1. ota2_image: OTA2 Image suitable for upgrade server
  2. ota2_download: OTA2 Image suitable for upgrade server + download to SFLASH OTA2 Staging Area at end of build
  3. ota2_factory_image: OTA2 Factory Reset Image
  4. ota2_factory_download: OTA2 Factory Reset Image + download to FLASH OTA2 Factory Reset Area at end of build
  5. ota2_manuf_download: Creates and downloads manufacturing image


For creating an OTA2 update image, the application should be build as follows: <folder>.<app_name>-<platform_name> ota2_image

This creates a binary file OTA2_image_file.bin which is located at ../build/snip.<app_name>-<platform_name>/OTA2_image_file.bin(This is the file which is provided for update through Webserver or through client's designated update server).


The functioning of OTA2 requires three applications:

  • OTA2 Bootloader
  • OTA2 Failsafe
  • OTA2 Extract

These applications are already built and downloaded when the Ota2_example snip is executed. Few details about these applications are mentioned here:

OTA2 Bootloader: On boot, ota2_bootloader checks the OTA2 Staging Area downloaded Image status and the OTA2 Factory Reset Image status and the Factory Reset Button.

If download status says Extract on Reboot                                              ---->>>     start ota2_extract to start extraction from the Staging Area

else if button(USER_1) hold ~5 seconds                                                 ---->>>    start ota2_extract to start the SoftAP, DHCP server and web server for manual update

else if button hold ~10 seconds or force_factory_reset is set in the DCT --->>>     start ota2_extract to extract the Factory Reset Image

else                                                                                                            --->>>     start current application


If power loss occurs during extraction, the ota2 bootloader checks the boot_type from DCT and decides on the image to be extracted. It extracts the apps LUT and ota2_extractor from the staging area or the factory restore area to restore enough of the system to do a full extraction.


OTA2 Failsafe: waf/ota2_failsafe

This application is loaded from the bootloader when needed to provide extraction of the Application LUT and snip/ota2_extract to allow for full extraction on reboot. The OTA2 Failsafe Application can restore a system to the valid OTA2 image in the Staging Area or the OTA2 Factory Reset Image if the system fails to boot(device was reset during OTA2 extraction). It is required for all builds, and is automatically built and downloaded with the ota2_bootloader.


OTA2 Extract: snip/ota2_extract

This application does all the extraction functionality for a normal extraction. It can also run the SoftAP, DHCP, and Web Server when instructed to do so by the ota2_bootloader. You need to build the ota2_extract application before building your full application. It is automatically downloaded when the ota2_example application is build as the make file of ota2_example points to the binary of ota2_extract. Following directives should be added in the make file of application for OTA2 support

#OTA SoftAp application
OTA_APPLICATION := snip.ota2_extract-$(PLATFORM)
OTA_APP := build/$(OTA_APPLICATION)/binary/$(OTA_APPLICATION).stripped.elf


As already discussed in the Bootloader section, the ota2_extract application is extracted from the OTA2 staging area/OTA2 factory restore area hence it should be a part of the update image. To include ota2_extract in the image, the OTA_APP directive should be added to the make file of the application as mentioned above.

The CYW43907 product guide provides the overview of CYW43907 features and how to use them in WICED Studio. To learn more about each feature please click on  resource links on this page that will take you to a document/ blog covering given feature in detail.



The CYW43907, 802.11n Wi-Fi wireless MCU is uniquely suited for single-chip Internet-of-Things applications. It supports all rates specified in the IEEE 802.11 a/b/g/n specifications.The device includes an Arm® Cortex®-R4 MCU dedicated for applications, a single stream IEEE 802.11n MAC/baseband/radio, a dual-band 5 GHz and 2.4 GHz transmit power amplifier (PA), and a receive low-noise amplifier (LNA). Device has 2 MB RAM to support memory intensive applications for example audio, any application that needs large buffer for data or involves intensive algorithms.


    • Block diagram



System Resources and Peripherals

          For power management of different resources, CYW43907 consists of Power Management Unit (PMU).The Power Management Unit (PMU) core manages power and clock resources for the entire chip, including Clock/Reset management and Power Managment.  PMU reduces power consumption through dynamic clock control, rapidly switching among different internal clock frequencies in response to current system bandwidth and latency requirements.


          After the device is powered on, ROM Bootloader executes first. Then application gets loaded from SFlash to RAM. This behavior slightly differs between warm boot and cold boot. Always ON Ram contains warm  bootloader which is loaded after ROM Bootloader if it is warm boot.


                   The two subsystems– APPS and WLAN – can transition into different low-power operation states independently.

Depending on different power save modes current consumption in CYW43907 varies. Different low power save modes and their details are described in detail in Application note. There is also another Application note available inside of WICED Studio in path WICED-Studio-6.0\43xxx_Wi-Fi\doc\WICED-Powersave-App-Note.pdf


          Over The Air (OTA) update is the wireless delivery of new application or data to device. Together OTA and OTA2 offer features including failsafe operation. OTA2 can update all parts of system excluding Bootloader. However, OTA2 implementation requires nearly 8 MB memory.


               CYW43907 supports both JTAG and SWD for connecting a JTAG debugger to both sub systems. JTAG_SEL pin and TAP_SEL pin should be set to '1' state. JTAG_SEL is exposed on a dedicated physical pin. TAP_SEL uses the GPIO_8 physical pin. If JTAG is not used then JTAG_SEL should be connected to ground. Debugging through JTAG using Olimex connector is supported from inside of WICED Studio.



  • Cypress Serial Interface

          There are two I2C-compatible and two SPI Compatible interfaces available on CYW43907. I2C can work upto 400 Kbps and SPI upto 26 MHz with 25 ns hold time. Bit Banging is also available on the same pins using the driver available from WICED Studio. Both SPI and I2C compatible interfaces can act as Master and their drivers are available from WICED Studio.


          There are three UART ports available on CYW43907 - fast UART, slow UART and GCI UART. Fast UART can support speeds upto 3 Mbps, has 64 bytes deep buffer and also 4 wire UART. Slow UART can support upto 115.2 Kbps. UART pins are however multiplexed on GPIOs and other pins.


  • USB 2.0

          CYW43907 has both USB host and device controller. CYW43907 can operate in the host-only, device-only, and dual-role device (DRD) modes. In DRD mode, the CYW43907 can be configured as either the host or a device on the fly but must remain in the same mode until the next boot cycle.


         CYW43907 provides up to six independent pulse width modulation (PWM) channels. Each PWM channel is a square wave generator. Each channel has capability to create different duty cycle waveforms. In addition adjacent PWM channels can be configured to be differential/complementary. They can be independently or synchronously driven.


          CYW43907 integrates a high performance Ethernet MAC controller. PHY needs to be located external to the chip which is interfaced through Media Independent Interface (MII) or a Reduced Media Independent Interface (RMII). The controller can transmit and receive data at 10 Mbps and 100 Mbps.


  • GPIO
    • There are 17 GPIOs avaibale in CYW43907. Some of them are used as Bootstrap pins. JTAG lines are also multiplexed on to GPIO lines. Please refer to CYW43907 Datasheet for more information.


WLAN subsystem

          CYW43907 provides support for single and dual antennas. Software Antenna Diversity is supported through WICED Studio. There are different NVRAM parameters available in WICED Studio for setting different options related to Software Antenna Diversity.


Additional topics

          CYW43907 supports loading more than one application into external flash and executing one among them.

          External display can be connected to CYW43907 through I2C for different graphics applications.

          CYW43907 has an external SD card slot which can be used to load different files and directories.

          Due to inappropriate clock setting, CYW43907 may enter in a state when it cannot be programmed any longer. To download further programs in CYW43907, unbricking has to be done.

Filter Blog

By date:
By tag: