Skip navigation
Home > All Places > Software Forums > WICED Studio Bluetooth > WICED Studio Bluetooth Forums > Blog
1 2 3 Previous Next

WICED Studio Bluetooth Forums

33 posts

Objective: This blog provides information about Bluetooth RF power class in Cypress Bluetooth devices and related certification queries.


WICED version: WICED SDK 6.2.1 or 6.4


Supported WICED device: CYW920706WCDEVAL, CYW20706 based modules


Details: Bluetooth devices may have different RF power classes depending on the Tx power and operating range of device. Following table shows the details about the classification:


ClassMaximum Tx powerOperating range
class 120 dBm~100 meters
class 24 dBm~10 meters
class 30 dBm~1 meter


      For CYW20706 devices, by default, firmware supports class 1 with maximum Tx power +12 dBm for BR/EDR applications and +9dBm for BLE applications. There are two ways to change the Tx power, i.e. RF power class-

1. Using API to set tx power: wiced_bt_dev_set_adv_tx_power() to set the maximum Tx power for BLE advertisement and wiced_bt_dev_set_tx_power() to set maximum Tx power for connection. Please refer Configuring Transmit (Tx) Power on CYW20706 Chip - KBA228573 for more details.

2. Modifying the default CGS file. However, this method is not recommended unless customer wants to do RF test for regulatory certification.


Q. Can the certification available here RF Regulatory Certifications for CYBT-343026-01, CYBT-343029-01, CYBT-143038-01 and CYBT-343151-02 EZ-BT™ Modules - KBA220396 be used for class 2 as well?

Ans: This certification is tested under the maximum output power for class 1. Still, it can be used for class 2 as long as the configured Tx power does not extend the maximum Tx power.


Q. Is CYBT-343026-01 module NCC certified?

Ans. Yes, the module is NCC certified with NCC ID - CCAH20LP2550T0. Please find the certificate attached.

This blog captures the changes one is likely to see when switching from CYW20719-B1 to CYW20719-B2.


  • One Major change for the Application developers is the different IDE requirement for CYW20719-B1 and CYW20719-B2. CYW20719-B1 requires WICED Studio for Application development while ModusToolbox is required for CYW20719-B2.


  • The max tx power and configurable power levels have changed between CYW20719B1 and CYW20719-B2.
    • CYW20719-B1: Max tx power = +4 dBm configurable power levels:[4, 0, -4, -8, -12, -16, -20, -24] dBm
    • CYW20719-B2: Max tx power = +6 dBm configurable power levels:[6, 2, -2, -6, -10, -14, -18, -22] dBm


  • Serial Peripheral Interface(SPI) driver API has been changed. Now it doesn't accept the pin configuration in the app, it needs to be defined in device configurator.
    • Old API 20719-B1:

void wiced_hal_pspi_init(spi_interface_t           spi,

                                          UINT8                        devRole,

                                          UINT16                      spiPinPullConfig,

                                          UINT32                      spiGpioCfg,

                                          UINT32                      clkSpeed,

                                          SPI_ENDIAN             endian,

                                          SPI_SS_POLARITY  polarity,

                                          SPI_MODE                mode,

                                          UINT8                        csPin);

  • New API 20719-B2:

void wiced_hal_pspi_init( spi_interface_t            spi,

                                           UINT32                       clkSpeed,

                                           SPI_ENDIAN              endian,

                                           SPI_SS_POLARITY   polarity,

                                           SPI_MODE                 mode);      


  • I2C combined read API changed. Recieve and transmit parameters have been interchanged for uniformity across devices.


Old API 20719-B1:

UINT8 wiced_hal_i2c_combined_read(UINT8*       tx_data,

                                                                  UINT8        tx_data_len,

                                                                  UINT8*       rx_data,

                                                                  UINT16      rx_data_len,

                                                                  UINT8        slave);


New API 20719-B2:

uint8_t wiced_hal_i2c_combined_read(uint8_t*      rx_data,

                                                                  uint8_t       rx_data_len,

                                                                  uint8_t*      tx_data,

                                                                  uint16_t     tx_data_len, uint8_t slave);


  • Change in enum names. WICED has been appended in front of the names.



























  • Change in structure name. WICED has been appended in front of the names.



typedef struct{

    uint32_t init_count;

    uint32_t toggle_count;

} pwm_config_t;



typedef struct{

    uint32_t init_count;

    uint32_t toggle_count;

} wiced_pwm_config_t;

Objective: This blog provides steps to test app available in WICED SDK for CYW20706 and CYW20719 devices.


WICED version: WICED SDK 6.2.1 or 6.4


Supported WICED device: CYW920706WCDEVAL, CYW20706 based modules, CYW920719Q40EVB_01, CYW20719 based modules

(Here CYW20706 based CYBT-343026 module is used for testing.)


Implementation details:

The watch demo example available in WICED SDK allows the device to demonstrate as Bluetooth A2DP source, AVRCP controller/target and some Apple services. By default, device is configured to send a sine wave to the A2DP sink, for example Bluetooth speaker, Bluetooth earphones/headphones. There are two ways to test this app:

i. Using default sine wave in firmware - When HCI_CONTROL_AUDIO_ROUTE_SINWAVE macro is set, firmware won’t send data request to the transport. It will provide the sine wave internally itself.

ii. Transport case - In UART mode, device will send the audio request to ClientControl. ClientControl will provide the data ( sine wave by default) to the sink device. In SPI mode, ClientControl is connected using PUART with 115200 Baudrate. PCM data cannot be sent over this baudrate so we can't provide the data from ClientControl. Therefore, in this case, hci_uart_spi_bridge app is used to provide the stored sine wave data. Here hci_uart_spi_bridge app acts as SPI master and watch app acts as SPI slave. The connections for the same are given in app comments.

     By default, sine wave in the firmware is used to send to the sink device. The macro HCI_CONTROL_AUDIO_ROUTE_SINWAVE is defined in hci_control_audio.h file.


Code flow:

     Following flowchart shows the code flow of the watch application. Events in the flowchart are as follows:






Testing steps:

1. Program the CYBT-343026 eval board with watch app using following Make Target: download UART=COM39

where COM39 is HCI COM port.

2. Open ClientContol.exe from /apps/host/client_control/Windows. Select HCI COM port from the list, Select Baudrate as 115200 and click on Open Port.

3. Press reset button on eval board, you should be able to see ClientControl tabs getting enabled.Check the attached snapshot for reference.

4. Click Start under BR/EDR Discovery section. Select your A2DP sink device from the list.

5. Select AV Source tab, click on Connect to connect to your sink device.

6. After successful connection, click on Start Streaming and you should be able to hear a sine-wave (continuous beep sound) in your Bluetooth speaker/ headphones.

Please refer attached snapshot.

     Similarly if you want to test the AVRCP functionality, then connect to your phone via Bluetooth and select AVRC TG/ AVRC CT options in ClientControl.

The non-volatile memory for the Bluetooth device (on-chip flash or external serial flash) is divided into five logical sections as shown in Figure 1. Table 1 gives details about each section of the memory layout.


Figure 1. Memory Organization of Non-Volatile Memory



Table 1. Non-Volatile Memory Organization, Off-chip Flash


Section Name




Static Section (SS)



Static section used internally by chip firmware. This typically contains configuration records that don’t change after factory programming.

Volatile Section (VS1)



First volatile section used by the application and the stack to store data in the external or on-chip flash memory

Data Section (DS1)



First partition. Used to store application code

Data Section (DS2)



Second partition. Used to store application code

These values are indicative, and the actual values can be found in BTP file.


The logical sections mentioned in Table 1 are aligned with the erase sector boundaries of the memory. These details can be found in *.btp files located in wiced_btsdk project in ModusToolbox workspace. The complete path inside the workspace looks like \wiced_btsdk\dev-kit\baselib<device>\platforms\<device>_OCF.btp. More details on the memory layout can be found in the WICED Firmware Upgrade Library user Guide located under WICED User Guides at Cypress WICED CYW20719 API Documentation .


Significance of *.btp File

The *.btp file contains information used by the download tools such as the minidriver location, baud rate, memory section addresses and other details. It also contains information such as the BD ADDRESS which can be changed while programming the device. Some of the parameters are:

  • DLConfigCrystalFreqMHz X 10000 – Frequency of the crystal connected to the device
  • DLConfigSerialControlBaudRate – UART baud rate used for programming
  • ConfigDSLocation – DS1 location offset
  • ConfigDS2Location – DS2 location offset
  • DLConfigSSLocation – SS location offset
  • DLConfigBD_ADDRBase – BD address

As explained in Firmware Architecture Cypress device can typically be used in two configurations – Controller mode or Embedded mode.

In controller mode, the host typically downloads some code like the general patch to the Bluetooth device’s SRAM or OCF. If the code is downloaded to SRAM, it needs to happen on each boot as the SRAM contents are lost on reset.

In embedded mode, the device embedded stack is used for some of the host functionality and the application code needs to be downloaded to the device’s OCF.


1. File Formats

Application code is usually kept in .hex or .hcd format. The *.hcd file is typically used for SRAM downloads and *.hex files are typically used for flash downloads. As an intermediate step, the source code along with some configuration values are converted to .cgs (configuration source) format and then converted to .hex or .hcd format. The .hcd file is useful when an external MCU needs to program the Bluetooth device in controller mode as the file size is smaller and the payload format is similar to the HCI commands. Intel .hex file is used when programming to flash. Figure 1 shows the file conversion process.

These files must be parsed and converted to HCI commands to download to the device. In ModusToolbox this is done by the ChipLoad tool.

Figure 1. File Conversion process


1.1 Details of *.hcd Format

The hcd files are binary files that can be parsed and interpreted directly as HCI commands. The hcd files have all the commands in binary format except the packet type which needs to be added by the host. The format of the hcd files are as follows:

  • The first two bytes are the command identifier. For example, the HCI_WRITE command is represented by 0x4C, 0xFC.
  • The next byte is the command payload length. For example, 0x06 indicates that six more bytes will follow to complete the command.
  • The command payload.

To convert the file to HCI commands, only the HCI packet type needs to be added. For example, when sending a command from the host, 0x01 should precede any HCI command to indicate that it is a command rather than an event.

The following WRITE_RAM command is an example:

01 4C FC nn xx xx xx xx yy yy yy …

In this WRITE_RAM command:

  • nn is 4 + N, which represents four address bytes plus N payload bytes.
  • xx xx xx xx is the 4-byte, absolute RAM address.
  • yy yy yy … are the N payload bytes to be loaded into the addressed RAM location.

The following response to each WRITE_RAM command is expected within 200 ms:

04 0E 04 01 4C FC 00


1.2 Details of *.hex Format

The .hex file follows the Intel I32HEX conventions. The format consists of records delimited by ASCII carriage return and line feed (0x0D, 0x0A). The format of the .hex files is as follows:

  • First character is the start code ‘:’ (ASCII 0x3A)
  • Next byte indicates payload length. For example, ‘FF’ indicates 255.
  • Next four bytes indicates 16 address bits. For example, ‘1000’ represents address 0x1000. The type of address depends on the type of command.
  • Next byte indicates the type of command:
    • ‘00’ is for data and the address field represents the lower 16 bits of the destination address.
    • ‘01’ indicates end of file. The payload is 0 and the address field is set as ‘0000’.
    • ‘04’ indicates extended address. The address field indicates the lower 16 bits of the address and the payload represents the higher 16 bits of the address.
    • ‘05’ for a 32-bit address payload. The address field is set as ‘0000’, the payload length is set as ‘04’ and the payload is interpreted as a 32-bit address. This is often used to indicate a LAUNCH_RAM (described later) destination.

1.3 Details of *.cgs Format

The .cgs file contains configuration parameters, patch code, and application code.The .elf file generated from the application source code is converted to .cgs format and is appended to the patch .cgs file located at wiced_btsdk\dev-kit\baselib\<device>\internal\<device>\patches\patch.cgs.

The definition of the configuration parameters in the .cgs file can be found in wiced_btsdk\dev-kit\baselib\<device>\internal\<device>\configdef<device>.hdf.

Parameters such as the crystal frequency, UART configuration, BD_ADDR, local name, and RSSI configuration can be modified using the patch .cgs file.


2. File Generation During Build

The file conversion process is as follows:

  1. The source files (.c, .h) are compiled and converted to .o (object) files using GNU tools.
  2. Library sources are linked to library .a files.
  3. These along with prebuilt library files are then linked to a .elf (executable and linkable format) file by GNU tools.
  4. The .elf file is converted to .cgs (configuration source) file using the wiced_btsdk\dev-kit\baselib\<device>\make\scripts\ script. The ROM patch code and platform .cgs files are also appended.
  5. The wiced_btsdk\dev-kit\btsdk-tools\Windows\CGS tool is then used to convert the .cgs file to Intel hex format. The cgs.exe application takes inputs such as the .cgs file created in the previous step and .btp file. The cgs.exe application can take runtime arguments such as BD ADDRESS and overwrite the BD ADDRESS in the .btp file. This can be useful while programming multiple devices with different addresses.
  6. The hex file is converted to an hcd file using the tool wiced_btsdk\dev-kit\btsdk-tools\Windows\IntelHexToBin


3. Recovery Process

Sometimes, the CYW20719 device may enter an unknown state or the HCI baud rate might have been changed from default. In such cases, it is not possible to program the device using HCI UART. To program the device correctly, the device needs to be put into the recovery mode. This is done by asserting the HCI UART CTS line while resetting the device.

When the Bluetooth device is reset, it checks for status of the HCI UART CTS pin (recovery pin) during power-ON. If the recovery pin is asserted (LOW) during reset, then the device enters what is called recovery mode. This mode will attempt to detect the UART baud rate by checking the RX line for the bit pattern of an HCI_RESET command. When detected, the HCI_RESET response is given at the same baud rate.

In this mode, most of the HCI commands will have no response. To download to the device in this mode, ignore the ‘no response’ to HCI_DOWNLOAD_MINIDRIVER and proceed with the download procedures. If the CTS pin is high after reset, then the device will check the OCF and apply any stored configuration, typically ending in a mode ready to accept all HCI commands at a default baud rate. If no configuration is available, the device will enter autobaud mode. Note that the application code can be directly loaded to the SRAM and executed or to the serial flash and then executed on next boot up.


4. Minidriver

The minidriver is separate FW independent of the ROM code. It is used to download the application code to the on-chip flash. The minidriver contains code to interpret certain HCI commands such as WRITE_RAM and READ_RAM and execute those commands. To download the code to the on-chip flash, first the minidriver needs to be written and executed from SRAM, which will interpret further HCI commands and write the code to the correct location in flash. As soon as the code download is complete, the minidriver is discarded because it is no longer needed. The minidriver will differ if the interface changes from UART to SPI or something else. The default minidriver can be found at wiced_btsdk\dev-kit\baselib\<device>\platforms\minidriver.hex.


5. Other Resources


To understand the download process and HCI commands flow in detail, see WICED User Guides section in Cypress WICED CYW20719 API Documentation. 

1. ClientControl

ClientControl is a WICED application that acts as a Bluetooth host on a PC. It connects to the Bluetooth device using HCI UART and communicates via the WICED HCI protocol. This application can be used to test the CYW20719 device by sending commands to start/stop advertisements, send connection request, test HID profile, etc. as well as download the firmware to the device SRAM. Note that because this tool downloads to the device SRAM, it doesn’t require any minidriver.


Figure 1. ClientControl Window


The ClientControl application for Windows, macOS and Linux can be found at wiced_btsdk\tools\btsdk-host-apps-bt-ble\client_control.


2. ChipLoad

ChipLoad is a command-line utility used to download the firmware to the Bluetooth device. It takes inputs such as the .hex file and .btp file to get the download data and download configuration respectively. It can be found at wiced_btsdk\dev-kit\btsdk-tools\Windows\ChipLoad


Note: The ChipLoad tool supports the Intel hex format.


3. DetectAndId

The DetectAndIdDetectAndId tool performs two tasks: Detect and ID.

At first, this tool tries and detects the serial ports on which Cypress Bluetooth devices are present. This is done by sending an HCI_RESET command on available ports at various baud rates and waiting for appropriate response. In case the serial port is already given as an input to this tool, it skips the port detect part.

The second task is to ID the connected device. This is done by sending a WICED HCI command to read the chip ID. The received ID is then compared to the expected chip ID present in the chip specific ID file in this path wiced_btsdk\dev-kit\btsdk-tools\Windows\DetectAndId/IDFILE.txt.        

This ensures that only the right device is programmed. This can be used by other tools to download the application code.

All Bluetooth wireless systems work the same basic way. The programmer writes the application firmware that calls Bluetooth APIs in the network stack. The stack then talks to the radio hardware, which in turn sends and receives data. When an event happens in the radio hardware, the stack will initiate actions in the application firmware by creating events (e.g., when it receives a message from the other side of the Bluetooth connection). The application code is responsible for processing these events that was pushed up by the stack and doing the necessary post processing for these events. The ROM is preprogrammed with a boot sequence, device driver functions, low-level protocol stack components, and a boot loader. The ROM firmware in CYW207xx handles the Bluetooth stack activities and processes the radio events. The ROM firmware works like a Finite-State Machine (FSM) in handling the Bluetooth events. As an application developer, you do not have to worry about the low-level Bluetooth functionalities.

A minimal C file for an application will look something like this:


#include "wiced.h"

#include "wiced_platform.h"

#include "sparcommon.h"

#include "wiced_bt_dev.h"

/***************************** Function Prototypes *******************/

wiced_result_t bt_cback (wiced_bt_management_evt_t event, wiced_bt_management_evt_data_t *p_event_data);

/***************************** Functions *****************************/

/* Main application. This just starts the BT stack and provides the callback function.

* The actual application initialization will happen when stack reports that BT device is

* ready.




/* Add initialization required before starting the BT stack here */

wiced_bt_stack_init (bt_cback, NULL, NULL); /* Register BT stack callback */


/* Callback function for Bluetooth events */

wiced_result_t bt_cback (wiced_bt_management_evt_t event, wiced_bt_management_evt_data_t *p_event_data)


wiced_result_t result = WICED_SUCCESS;

switch (event)


/* Bluetooth stack enabled */


/* Initialize and start your application here once the BT stack is running */






return result;


The purpose of an RTOS is to reduce the complexity of writing embedded firmware that has multiple asynchronous, response time critical tasks that have overlapping resource requirements. The RTOS maintains a list of tasks known as threads that are in different states such as active, inactive, or scheduled, and executes these tasks based on their priorities. Multi-threaded applications that make use of SoC peripherals should handle thread synchronization in the application when there are resource conflicts such as shared memory, mutual exclusion, hold and wait, and circular wait.

The RTOS in the ROM firmware creates multiple threads immediately after the bootup for handling the Bluetooth functionality and then gives control to the application thread. Currently, ModusToolbox supports multiple RTOSs. The device ROM has ThreadX by Express Logic built in and the license included, which makes this the best choice for developing applications with CYW207xx. To simplify using multiple RTOSs, the BT SDK has a built-in abstraction layer that provides a unified interface to the fundamental RTOS functions. You can find the documentation for the WICED RTOS APIs at Cypress WICED CYW20719: RTOS



Run CYW20706 in HCI Mode

Posted by XinghaoZ_26 Moderator Jun 27, 2019

HCI Mode Introduction


The CYW20706 can run as a single-chip Bluetooth device with the Cortex-M3 microprocessor core or run as a Bluetooth controller only device in HCI mode. A Bluetooth controller only device supports the Bluetooth HCI interface as defined in the Bluetooth Core specification.


In HCI mode, we can connect a HOST MCU, a tester or a system which runs Linux or Android through the HCI UART interface. To successfully run the device in HCI mode, there are some initializations need to be done because the ROM code in the device is too old.


How to Run HCI Mode


There are two conditions for the customer’s application:


1. The device has a flash connected with it.


(1) Download an application FW to initialize the configuration.

You can download any demo code (for example, hello_sensor) in the SDK for the initialization. I attached an application code based on hello_sensor for reference. There are two things to consider:

  • Disable the trace log by wiced_set_debug_uart(WICED_ROUTE_DEBUG_NONE).
  • Set the baud rate for HCI UART in the const wiced_transport_cfg_t  transport_cfg{}.

(2) Pull the CTS to high during the power on reset or hardware reset.

This will enable the device to enter HCI mode and receive all the HCI commands. If you are testing with the CYW20706 kit board or related module kit board, the CTS pin will be pulled up if you plug the USB to the computer while the UART port on the computer is close.

(3) Connect the device with CYBluetool and sent reset command. The baud rate is set in the const wiced_transport_cfg_t  transport_cfg{} configured before. Then the device will accept all the HCI commands.


2. The device doesn’t have a flash connected with it.


(1) Download an application to RAM to initialize the configuration.

You can download an application which is described in the last chapter to the RAM to initialize the device. There are two methods to download application to RAM: using the Client Control or using HCI command. You can find both methods in the document WICED-HCI-Control-Protocol.pdf in the folder like C:\Users\xxxx\Documents\WICED-Studio-6.2.1\Doc\.

(2) Connect the device with CYBluetool and sent reset command. The baud rate is set in the const wiced_transport_cfg_t  transport_cfg{} configured in the application. Then the device will accept all the HCI commands.

This blog gives detailed steps on how to use chipload.exe to program Cypress Bluetooth chips CYW207xx.

Chipload (/<BTdevice_workspace>/wiced_tools/ChipLoad) is a tool provided by Cypress to program the device without using WICED SDK or ClientControl utility. To program to device using Chipload, first run the ChipLoad.exe from the folder location: C:\Users\shjl\Documents\WICED-Studio-6.2\wiced_tools\ChipLoad\Win32


A specific command format is used to download the Hex file to the device, as follows:

./ChipLoad.exe -BLUETOOLMODE [-PORT COM port] [-BAUDRATE nnnn] [-NOVERIFY] [-CHECKCRC] [-MINIDRIVER minidriver file] [-CONFIG config data file] [-BTP btp file name] [-NODLMINIDRIVER] [-LOGTO[X} optional log file] [-DLMINIDRIVERCHUNKSIZE byte size]


Detailed information about every parameter is given below:

PORT              : UART COM port id (HCI UART)

BAUDRATE     : to specify the Baudrate of the device, typically 115200

NOVERIFY      : an optional parameter that prevents the verification of the bytes regardless of what is specified in BTP file

CHECKCRC    : an optional parameter that directs the ChipLoader to do CRC checks on loaded areas

MINIDRIVER    : to specify the minidriver hex file which is used to load the program Hex file to the device

BTP                : to load the BTP file which contains configuration data

CONFIG          : to specify the program .hex file

NODLMINIDRIVER : used if device has never been programmed or device is in recovery mode

LOGTO (or LOGTOX) : an optional parameter allowing to print the logs in a text file, LOGTOX prints more detailed information



ChipLoad.exe -BLUETOOLMODE -PORT COM23 -NOVERIFY -MINIDRIVER C:\Users\shjl\Documents\WICED-Studio-6.2\20719-B1_Bluetooth\platforms\minidriver-20739A0-uart.hex -BTP C:\Users\shjl\Documents\WICED-Studio-6.2\20719-B1_Bluetooth\platforms\20719_OCF.btp -CONFIG C:\Users\shjl\Documents\WICED-Studio-6.2\20719-B1_Bluetooth\build\gpio-CYW920719Q40EVB_01-rom-ram-Wiced-release\gpio-CYW920719Q40EVB_01-rom-ram-Wiced-release.hex


Executing above command downloads snip.gpio app to the CYW920719Q40EVB-01 EVAL board.


Note: You can include all the needed files into a single folder, so that it becomes more simpler to access the files and program the device.

The I2S or PCM clock of CYW20706 can’t be set by the application. The audio firmware / hardware control this based on the current audio stream bit depth, sample rate, number of channels etc.




On the CYW20706, I2S is used for routing audio samples while using the A2DP profile. The direction of the audio samples depends on the A2DP role of the device. If the CYW20706 is configured as a source, then audio samples are received from a hardware codec over I2S. If configured as a sink, then the audio samples are transmitted from CYW20706 to the hardware codec.

In A2DP applications, the audio data is routed over I2S by default and or when the route is configured as AUDIO_ROUTE_I2S. CYW20706 can be configured as the I2S master by setting the is_master flag to TRUE. CYW20706 will then generate the bit clock or SCK based on the sampling frequency negotiated over the A2DP profile. For example, if the CYW20706 negotiates a sampling frequency of 44.1 kHz with the peer Bluetooth device during codec negotiation, then the I2S clock frequency will be set to 44.1 kHz by the internal libraries. The bit depth or word length is set to 16, i.e. frame length is fixed to 32 and cannot be modified. The I2S clock in the master mode can either be 

  • 44.1 KHz x 32 bits per frame = 1411.2 KHz
  • 48 KHz x 32 bits per frame = 1536 KHz

In the slave mode, any clock rate is supported up to a maximum of 3.072 MHz.


Note: If CYW20706 is an A2DP source, you can set the sampling frequency in the application firmware. For example, av_app_cb.audio_sf = 'desired sampling frequency'; in ‘ watch ‘ demo




PCM is a standard method used to digitize audio (particularly voice) for transmission over digital communication channels. CYW20706 includes a PCM interface that can connect to linear PCM codec devices either in master or in slave mode. The PCM interface is used for full duplex bi-directional transfer of 8K or 16K voice samples while using the HFP profile.

The CYW20706 uses 13 bits of the 16 bits in each PCM frame. The remaining three bits need to be ignored at the input device and may be filled with 0s, 1s, a sign bit, or a programmed value on the output. The default format is 13-bit 2’s complement data, left justified, filled with 0's and clocked MSB first.

The PCM clock setting will be done internally based on the sample rate in SCO settings. 

If WBS (wide band speech) is enabled, it will use 16K sample rate , otherwise 8K. Check WICED_BT_HFP_HFP_CODEC_SET_EVT  to check whether WBS enabled or not.

Thus the PCM clock can either be

  • 8khz * 16bit * 2(channel) = 256khz (For narrow band speech)
  • 16khz * 16bit * 2(channel) = 512khz (For wide band speech)

This is taken care by the WICED Stack. You just need to enable or disable WBS in the application project.



Posted by SheetalJ_96 Moderator Mar 27, 2019

Disclaimer: This blog applies to following Cypress devices: CYW20706, CYW20719, CYW20735 and BT/BLE modules based on these devices.


Q. Using A2DP, how much is the expected minimum BT audio latency?

A. BT audio latency depends on many parameters like buffering on both source & sink sides, time required for PCM signals to playout, etc. The jitter buffer can be lowered to 4.1kB to give 50ms latency, but this comes with a cost of reduced audio quality. Therefore, in WICED, the jitter buffer is set to 116ms to avoid music interruptions caused by Wi-Fi and other radio sources. Setting it below 60ms will cause the buffer to overrun, a condition in which the buffer is fed with data at a slower rate than required, resulting in loss of audio.


Q. How to connect external host to Cypress BT chips?

A. Cypress BT chips can be used in host mode, where BT controller is controlled by an external host. We have a combo chip CYW943907WAE3 (check the workspace 43xxx_Wi-Fi), where CYW20707 gets programmed via 43907 MCU. In short, 43907 MCU acts as an external MCU for CYW20707. It takes the BT firmware from /43xxx_Wi-Fi/libraries/drivers/bluetooth/firmware/20706A2/40MHz/bt_firmware_controller.c and executes API bt_firmware_download().

To connect external MCU as host, host and controller should be connected via UART and then BT controller can be programmed by sending commands from Host. Cypress provides tools like ClientControl, CyBluetool for programming the device. Please refer <WICED workspace>/doc/WICED-HCI-Control-Protocol.pdf document for more details.

Note: CYW20707 is not a broad-market chip, but our module vendors like Murata use this chip to integrate it in a SiP along with other Wi-Fi chips. You can use CYW20706 to achieve similar functionalities.


Q. Do Cypress supports AT commands?

A. Cypress devices do not support AT commands. But we have EZ-Serial support for BT/BLE modules like CYBT-343026, CYBLE-022001 and more. Please refer following link for further details:


Q. How can I perform RF testing on Cypress BT devices/modules?

A. You can use mbt (<WICED workspace>/wiced_tools/mbt) or wmbt (<WICED workspace>/wiced_tools/wmbt) tools available in WICED SDK for RF testing. You can also use CyBluetool to allow DUT to enter different modes for regulatory test. Please refer attached pdf for more details.


  1. For BLE, you need to put device in HCI mode to accept commands through UART interface. For classic BT, put the device in Test mode to accept the commands through RF interface. Please refer section “Test Mode Setup” in attached pdf.
  2. MBT uses standard HCI commands and WMBT uses WICED HCI commands defined by Cypress.

SPI example for CYW20706

Posted by AnjanaM_61 Moderator Jan 22, 2019

This application demonstrates how to use SPI driver interface on CYW20706 to send and receive bytes or a stream of bytes over the SPI.


Hardware connections on CYW20706 EVAL:

For SPI Slave use the below pins :

  •   CS   - P26
  • MOSI - P27
  • MISO - P25
  • CLK  - P36

For SPI Master use the below pins :

  •   CS   - P26
  • MOSI - P0
  • MISO - P25
  • CLK  - P36


Test Procedure:

  • Program 1 kit with the spi_master app and another kit with spi_slave app (attached the project).
  • Connect the SPI lines and ground on the 2 kits.
  • Power on the kits. You can see the logs through PUART
  • Reset the SPI master first and then SPI slave.
#include "rtc.h"

tRTC_REAL_TIME_CLOCK rtcClock1, rtcClock2;

rtcConfig.oscillatorFrequencykHz = 32;


WICED_BT_TRACE("NUM TICKS ELAPSED: %d\r\n", rtcClock2.reg32map.rtc32[0] - rtcClock1.reg32map.rtc32[0]);



The tick count above is useful for providing time stamps with a high resolution. The counter goes up to 48 bits, to read more than 32, you’ll need to properly deference the higher bits.

E-ink Display interface with CYW20719



E-INK (electronic ink) is a paper-like display technology, characterized by high contrast, wide viewing angles, and minimal standby power. Unlike conventional backlit, flat panel displays that emit light, E-INK displays reflect light like paper. This makes E-INK displays more comfortable to read, and provides a wider viewing angle than most light-emitting displays. Therefore, E-INK displays are comfortable to read even in sunlight.

Currently we are using CY8CKIT-028-EPD E-INK Display Shield (EPD) interfaced with CYW20719 Eval board. The E-INK Shield has a 2.7-inch E-INK display with a resolution of 264×176 pixels.

The E-INK display contains a basic driver IC that interfaces with the CYW20719 using a custom SPI interface. The driver converts a serial data stream into individual pixel data and generates the voltages required for the E-INK display. Thus, CYW20719 has low level control to the display through the driver IC.

See the E-INK display driver document for more details.



The CYW20719 controls the E-INK display’s reset, enable, discharge and border pins. The controller check the busy status of display via Busy pin of E-ink display. The table below shows the pin to pin connection between CY8CKIT-028-EPD E-INK Display Shield and CYW20719 Eval board.

Table 1: Pin connections

E-ink Display Shield Pins

Pin Defenition


Pin Configuration on 20719


Display Reset Pin

P0 (D2)

Output pin


Display Busy Pin

P33 (D1)

Input pin


Display Enable Pin

P34 (D0)

Output pin


Discharge Pin

P26 (D5)

Output pin


Border Control Pin

P2 (D6)

Output pin


Display IO Enable Pin

P4 (D7)

Output pin


Eink Select Pin

P7 (D10)

SPI CS pin



P28 (D11)




P1 (D12)




P38 (D13)








  1. 3.3V





IO Ref


Pin Significance:

  1. Display Reset Pin: Reset signal for display. This pin need to pull high and low as defined in the E-INK display driver document.
  2. Display Busy Pin: It’s an input pin for CYW20719. When busy pin is high, EPD stays in busy state and EPD ignores any input data from SPI.
  3. Discharge Pin: Used to discharge the excess voltage in charge pump capacitors during EPD power off. This pin must be set high for EPD discharge when EPD power off.
  4. Display Enable Pin – To control the display On /OFF
  5. Display IO Enable Pin – To control the voltage translator IC between the WICED and display. This pin is specific for CY8CKIT-028-EPD E-INK Display Shield.
  6. Border Control Pin: Around the active area of EPD there is a 0.5mm width blank area called Border. After EPD updates with the constant voltage, the border color may degrade to a gray level that is not as white as the active area. To avoid this phenomenon, we should reset the Border per screen update. All these are taken care in the driver code.
  7. SPI interface pins: Uses SPI MOSI, MISO, SCLK and software controlled CS pins for the SPI communication between display and CYW20719



The CYW20719 uses SPI communication with the driver IC of E-Ink display with a SPI speed maximum upto 24MHz. This E-ink display driver needs a software controlled chip select pin. Thus, make sure you have disabled the hardware SPI CS pin of CYW20719. For that, change the pin configuration of default CS (Chip select) pin (P07) to WICED_GPIO in the wiced_platform_pin_config.c file 

(Path: /20719-B1_Bluetooth/platforms/CYW920719Q40EVB_01/wiced_platform_pin_config.c)

The SPI format for display driver differs from the standard. Thus the E-ink driver code is written in such a way that follows the SPI command and timing described in the E-INK display driver document.



The E-Ink Display driver library provides the user low level APIs to use in their end application code. The various driver APIs are provided in the Appendix A. The driver API definitions are written as per the work flow defined in the E-INK display driver document. As an end user, you need not have to worry about the driver code, rather you must be familiarized with the end level driver APIs defined in Appendix A.

The display driver updates the display with respect to the current frame and previous frame written from the CYW20719 controller to the driver via SPI communication. One frame buffer contains 5808 ((246x176)/8) bytes. For converting the image into 5808 bytes’ frame buffer, you can use the GUI given by display vendor (Given in Appendix B). Check Appendix B for image and text formats supported by this E-ink display.

The procedure to update the display is:

  1. Store new pattern in the memory buffer
  2. Power on the display driver
  3. Initialize the display driver
  4. Update the display stage by stage
  5. Power off the display driver

The driver APIs are taken care of the above steps.

Attached a demo project designed for a sensor hub. The demo uses below custom functions which using low-level display driver APIs:

  • Disp_Initialize() for initializing the display
  • Display_Initial_Screen() for  displaying a initial screen
  • RefreshDisplay() for refreshing the screen with sensor value.


4.1 Display Initial Screen

Figure below shows the flow of code for displaying an initial screen on the E-ink display. First power on the E-ink by sending start commands, which is already taken care in the E-ink library API. Disp_Initialize function will initialize the display functions and create the frame buffer from the image buffer created by GUI given in Appendix B. After that clear the display with a white background by calling Cy_EINK_ShowFrame function. Cy_EINK_ShowFrame function will display the image corresponding to current frame buffer. You must call Cy_EINK_ImageToFrameBuffer() function by passing the pointer for image to displayed before calling Cy_EINK_ShowFrame function. Refer Appendix A for function descriptions.




4.2 Refresh Display



The display need to be updated by the sensor values collected. We have hard coded co-ordinates for displaying each sensor values. The RefreshDisplay function will take the sensor values, convert it to hex values and will update the main frame buffer at specific co-ordinates hard coded in the function. Cy_EINK_TextToFrameBuffer function will convert the sensor values to corresponding bytes which will be embedded into the main frame buffer. This main buffer will be passed to the Cy_EINK_ShowFrame function for displaying the screen with sensor values.


5. EH Kit Display Screen details:

Steps involved in the display configuration

  1. First step is to make an initial screen as shown above with pixel format 246 x 176
  2. Convert the image to 5808 bytes’ frame buffer using the GUI given in Appendix B
  3. Display the initial screen by the steps mentioned in section 4.1
  4. The sensor data is passing as text for time, battery, temperature, pressure etc.
  5. Find the co-ordinates to display the sensor data mentioned in step 4 by using Cy_EINK_TextToFrameBuffer() API by trial and error method.
  6. Once you fix the co-ordinates in step 5, hardcode the co-ordinates in function RefreshDisplay() and update only the values in that co-ordinates in timely basis.


Note: Attached the Appendix as well as demo project file.

This blog post discusses implementation of BLE Proximity Profile in CYW20719 and CYW20735 using the Bluetooth Designer tool of WICED Studio SDK.


Tool: WICED studio 6.2, Serial Terminal (Example: TeraTerm, CoolTerm)

Programming Language: C

Associated Parts: CYW20719 / CYW20735

Related Hardware: CYW920719Q40EVB_01 Board (1 or 2) / CYW920735Q60EVB_01 (1 or 2)

Proximity Profile:

The purpose of proximity profile is to keep an eye on the BLE Connection link between two devices and trigger an alert when the link is weakened as path loss increases. This profile supports two roles:

  1. Proximity Server (Reporter)
  2. Proximity Client (Monitor)

The proximity profile must include the Link Loss Service. It may optionally include Tx Power Service and Immediate alert service also. Link Loss Service:  The GATT DB of the link loss service has the “Alert Level” characteristic which may be written by the proximity client. This indicates the level of alert to be triggered in the server when the disconnection happens.Tx power Service:  The proximity client may anytime know the Transmitter Power level of the server. This is enabled by reading the Tx Power level characteristic included in the Tx power service.Immediate Alert Service:  The proximity monitor may keep calculating the path loss as follows:


Path Loss = Tx Power Level – RSSI


If the path loss exceeds a certain threshold, the monitor may write the Alert Level characteristic of the IAS, thereby prompting the user to perform appropriate action to avoid disconnection.

Block Diagram:

Using the Bluetooth Designer to generate Proximity Server project:

We can use the Bluetooth Designer in WICED Studio SDK to generate the GATT DB and an outline code for the firmware. For more details on using the Bluetooth Designer, refer to the Bluetooth Designer Guide in WICED Studio SDK. The GATT DB of the Proximity Server has 3 different services. It is easy to generate the GATT DB and a skeleton code using the Bluetooth Designer Tool. (For more details on the Bluetooth Designer tool, please refer the user guide which can be accessed in the WICED Studio from Project Explorer -> <Platform> -> Doc

  1. In the WICED Studio SDK, go to File -> New -> WICED Bluetooth Designer. Enter the device name as “ProximityServer”, mode as Single Mode LE.
  2. Check the GATT DB enabled option Click Next.
  3. Using the “Add Service” Option, different services are selected.
  4. Add the characteristics as shown above and click “Generate Code” to obtain the skeleton project.

Firmware:This example contains two projects – The proximity server and the proximity client. Proximity Server:  A skeleton code of the proximity server can be generated using the above steps. Certain key features need to be added to the skeleton code to make the server project complete. According to the specification, a proximity reporter has to advertise with the UUID of Link Loss Service. So, the advertisement data should be modified as follows


:/* Set Advertisement Data */

void proximityserver_set_advertisement_data( void )

{    wiced_bt_ble_advert_elem_t adv_elem[3] = { 0 };


    uint8_t num_elem = 0;
    /* Advertisement Element for Flags */ 

    adv_elem[num_elem].advert_type = BTM_BLE_ADVERT_TYPE_FLAG;

    adv_elem[num_elem].len = sizeof(uint8_t);

    adv_elem[num_elem].p_data = &adv_flag;


    adv_elem[num_elem].advert_type  = BTM_BLE_ADVERT_TYPE_16SRV_COMPLETE;

   adv_elem[num_elem].len          = sizeof(lls_uuid);

   adv_elem[num_elem].p_data       = ( uint8_t* )lls_uuid;


    /* Advertisement Element for Name */

   adv_elem[num_elem].advert_type = BTM_BLE_ADVERT_TYPE_NAME_COMPLETE;

    adv_elem[num_elem].len = strlen((const char*)BT_LOCAL_NAME);

    adv_elem[num_elem].p_data = BT_LOCAL_NAME;


    /* Set Raw Advertisement Data */

    wiced_bt_ble_set_raw_advertisement_data(num_elem, adv_elem);


Where lls_uuid is declared and initialized as:

/* Link Loss service UUID  */

const uint8_t lls_uuid[2] = {(uint8_t)UUID_SERVICE_LINK_LOSS & 0xFF, (uint8_t)(UUID_SERVICE_LINK_LOSS >> 8)  };

The proximity server receives Link Loss and IAS Alerts in the form of writes.. The IAS Alert is triggered instantaneously where as the link loss alert happens when there is a disconnection. The Alerts are indicated by the LEDs.Proximity Client:  This is a central / client device that performs read / write operations with the GATT DB of the server. The central starts scanning for peripherals that advertise with a Link Loss Service UUID, upon a GPIO button press and initiates the connection. Then it begins to discover all the three services of the proximity profile in the server, one by one and saves the handles of the attributes. Following this, the TX power characteristic of the server is read. Now the client periodically calculates the RSSI every 100 mS and thus the average path loss. If the path loss reaches beyond certain thresholds, the client writes to the Immediate alert characteristics of the server, resulting in an immediate trigger. The thresholds are as follows:MILD ALERT: Path loss above 90 dB HIGH ALERT: Path loss above 100 dBThe Link loss alert can be written to the server by pressing the GPIO Interrupts on the client Eval Board. Everytime the GPIO is pressed, a different LL alert value is written to the server. 

Programming and Testing:


  1. Install the WICED Studio 6.2 (or above) in your PC. Plug in two CYW920719Q40EVB_01 Boards and let the drivers bind
  2. to the devices. Make sure the jumpers are in place. Open WICED Studio and set the platform as 20719-B1_Bluetooth. For more details, please refer CYW920719Q40EVB_01-Kit-Guide.pdf present in Doc folder in the project explorer.
  3. Copy the ProximityServer and the ProximityClient folders. In the WICED Studio, right-click the Apps folder in the Project Explorer pane and click Paste. You can see these folders under the Apps folder.
  4. Open two windows of Serial Terminal (Example: Teraterm or Coolterm), and bind each of those windows to the PUART COM Ports of each devices. Each device has two COM Ports with consecutive numbers. The COM Port with the bigger number corresponds to the PUART that displays Debug Messages. The one with the smaller number corresponds to the HCI UART. The BaudRate is set to 115200 in the firmware. Make sure the BaudRate in serial terminals is also set to 115200.
  5. Create a Make Target for the project by selecting Project -> Make Target -> Create. Paste the following as the entry in the Target Name field:

ProximityServer-CYW920719Q40EVB_01 UART=COMxx download

Make sure that the Same as the Target Name checkbox is checked. Click OK. Create another target, in addition to the previous one as:

ProximityClient-CYW920719Q40EVB_01 UART=COMyy download

(Note: In the above targets, XX and YY are the PUART COM Port numbers of each of the devices)

    6. Double click the ProximityServer Target you just created, shown in the Make Target Pane on the right. You can see the Secure_hub program being built and downloaded into one of the boards.

     7.  Similarly program the ProximityClient program to the device.

     8. The ProximityServer device will start to advertise. In the ProximityClient device, press the BTN (D2) button for more than 5 seconds for the scan to start. Once the ProximityClient finds the           ProximityServer device advertising, it will automatically initiate connection and pairing process.

     9. The client performs discovery in the server and saves the attribute handles of the Link loss alert, immediate alert and transmit power characteristics. The initial Tx power is also read from the server.

     10. Click the BTN (D2) button to write LL Alert value to the server. Everytime the button is pressed, a different value of alert level (among the 3: NO_ALERT, MILD_ALERT, HIGH_ALERT) is written to the server. When a link loss happens the server will be triggered based on the alert level that was written, as indicated by the LED 2.

     11. The client will also keep calculating the Path loss and writes immediate alerts to the server if the path loss value exceeds a certain threshold. Such alerts immediately trigger the server, as indicated by the LED 1.

Path Loss Vs Distance:


For a Tx Power of 4 dBm in CYW20719 and of 12 dBm in CYW20735, the path loss Vs Distance values are observed as below in an office environment.






Distance (m)

Path Loss (dBm)













































Related Documents:

The below table lists all relevant application notes, code examples, knowledge base articles, device datasheets, and Component / user module datasheets.






CYW920719Q40EVB-01 Evaluation Board User Guide

The  User Guide can be accessed in the WICED Studio from Project Explorer -> 20719-B1_Bluetooth -> Doc


Developing Custom Applications with BT Designer - Document

This document can be accessed from Project Explorer -> <Platform> -> Doc

Filter Blog

By date:
By tag: