Skip navigation
Home > All Places > Software Forums > WICED Studio Bluetooth > WICED Studio Bluetooth Forums > Blog > Authors AmalM_81

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;

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


Filter Blog

By date:
By tag: