Skip navigation
Home > All Places > WICED Studio Bluetooth > WICED Studio Bluetooth Forums > Blog > 2019 > June

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 OwenZ_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.

Filter Blog

By date:
By tag: