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

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

Memory_Layout.JPG

 

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

 

Section Name

Offset

Length

Description

Static Section (SS)

0x500000

0x2000

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

Volatile Section (VS1)

0x500400

0x1000

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

Data Section (DS1)

0x501400

0x3E000

First partition. Used to store application code

Data Section (DS2)

0x520A00

0x3E000

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 at \ModusToolbox_1.1\libraries\bt_sdk-1.1\components[RK1] \BT-SDK\<device>_Bluetooth\platforms\<device>_OCF.btp. More details on the memory layout can be found in the \ModusToolbox_1.1\libraries\bt_sdk-1.1\docs\BT-SDK\WICED-Firmware-Upgrade-Library.pdf file.

 

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

Programming.JPG

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 \ModusToolbox_1.1\libraries\bt_sdk-1.1\components\BT-SDK\<device>_Bluetooth \WICED\internal\<device>\patches\patch.cgs.

The definition of the configuration parameters in the .cgs file can be found in \ModusToolbox_1.1\libraries\bt_sdk-1.1\components\BT-SDK\<device>_Bluetooth \WICED\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 \ModusToolbox_1.1\tools\wiced-scripts-1.0\wiced-gen-cgs.pl script. The ROM patch code and platform .cgs files are also appended.
  5. The \ModusToolbox_1.1\tools\wiced-tools-1.0\BT\CGS\bin\cgs.exe 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 \ModusToolbox_1.1\tools\wiced-tools-1.0\BT\IntelHexToBin\bin\IntelHexToHCD.exe.

 

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 \ModusToolbox_1.1\libraries\bt_sdk-1.1\components\BT-SDK\<device>_Bluetooth\platforms\minidriver.hex.

To understand the download process and HCI commands flow in detail, see \ModusToolbox_1.1\libraries\bt_sdk-1.1\docs\BT-SDK\WICED-HCI-Control-Protocol.pdf.

 

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

ClientCOntrol.JPG

The ClientControl application for Windows, macOS and Linux can be found at \ModusToolbox_1.1\libraries\bt_sdk-1.1\components\BT-SDK\common\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 \ModusToolbox_1.1\tools\wiced-tools-1.0\BT\ChipLoad\bin\.

 

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 <install>/libraries/bt_sdk-1.1/components/BT-SDK/<device>_Bluetooth/platforms/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.

*/

APPLICATION_START ()

{

/* 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 */

case BTM_ENABLED_EVT:

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

break;

 

default:

break;

}

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 under the WICED API Reference Guide in this path Components > RTOS.

 

OwenZ_26

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

 

Example:

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.

 

I2S:

 

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:

 

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.

SheetalJ_96

WICED BT FAQs

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: https://www.cypress.com/documentation/software-and-drivers/ez-serial-ez-ble-module-firmware-platform

 

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.

Note:

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

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;
rtc_init();

rtc_getRTCRawClock(&rtcClock1);
utilslib_delayUs(1000);
rtc_getRTCRawClock(&rtcClock2);

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

 

1. OVERVIEW

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.

 

2. HARDWARE SETUP

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

CYW20719Q40EVB_01

Pin Configuration on 20719

D2

Display Reset Pin

P0 (D2)

Output pin

D3

Display Busy Pin

P33 (D1)

Input pin

D4

Display Enable Pin

P34 (D0)

Output pin

D5

Discharge Pin

P26 (D5)

Output pin

D6

Border Control Pin

P2 (D6)

Output pin

D7

Display IO Enable Pin

P4 (D7)

Output pin

D10

Eink Select Pin

P7 (D10)

SPI CS pin

D11

MOSI Pin

P28 (D11)

SPI MOSI Pin

D12

MISO Pin

P1 (D12)

SPI MISO Pin

D13

SCLK Pin

P38 (D13)

SPI SCLK

GND

GND

GND

GND

V3.3

VDD

  1. 3.3V

VDD

VIO_Ref

IO_Ref

IO_Ref

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

 

3. E-INK DISPLAY SPI CONFIGURATION

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.

 

4. FIRMWARE FLOW OF DISPLAY

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.

 

E-ink.PNG

 

4.2 Refresh Display

E-ink1.PNG

 

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.

Requirment:

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 adv_flag = BTM_BLE_GENERAL_DISCOVERABLE_FLAG | BTM_BLE_BREDR_NOT_SUPPORTED;

    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;

    num_elem++;


    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;

   num_elem++;


    /* 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;

    num_elem++;


    /* 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.

CYW20719:

 

  

CYW20735:

 

Distance (m)

Path Loss (dBm)

0

12

0.01

20

0.02

30

1

50

2

60

5

70

7

80

10

93

15

95

20

96

25

97

30

98

40

99

50

100

80

101

100

102

120

104

140

105

160

107

180

107

200

108

210

109

Related Documents:

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

 

Document

Title

Comment

002-22816

CYW920719Q40EVB-01 Evaluation Board User Guide

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

002-19103

Developing Custom Applications with BT Designer - Document

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

Overview

This blog explains the using the A2DP sink example in WICED. The I2S Configuration requirements and hardware interfacing.

 

Requirements

Tool: WICED Studio 6.1 or above, A2DP Source (Cell Phone), DAC/Codec Breakout or Shields, Loudspeaker or Headphones.

Programming Language: C

Associated Parts: CYW20706

Related Hardware: CYW920706WCDEVAL, CYBT-343026-EVAL

 

Project Description:

A2DP Sink is a ready example project in WICED Studio. It has all the necessary code written to test the functionality. It has capability to establish the connection and route the Audio Stream coming from the A2DP Source via BT to the I2S block which needs to connect to an Audio DAC / Codec to reproduce the sound on a Loudspeaker / Headphones.

Looking at the code one might see codec configuration and get confused with the I2C Codec configuration. BT Audio there are 2 codecs.

  1. BT Codec - this is the codec used by the A2DP profile to compress and decompress the audio data. CYW20706 supports the 'SBC' codec.
  2. Audio Codec - This is the I2S Hardware codec that connects to the external Audio Codec device which converts the digital audio data into electrical analog signals.

The A2DP sink example is located at 'apps/snip/bt/a2dp_sink'.

 

 

I2S Interface:

 

Signal

Description

BLCK / PCM_CLK

Bit Clock

WS/LRC/ PCM_Sync

Word Select / Left Right Control.

DI /PCM_IN

Audio Data In

DO / PCM_OUT

Audio Data Out

 

The I2S is a simple full duplex serial interface, the data on the DI /DO pins is sampled at the BCLK edge. WS/LRC simply indicates if the data on DI/DO is for Left or Right channel of audio. The frequency of this signal indicates the selected Audio Sampling Rate. Refer the codec datasheets for timing diagrams, register configuration.

 

I2S in CYW20706:

I2S Mode: Master Mode (Codec is Slave)

Sample Rate: 44.1Khz or 48Khz (set based on the capabilities of the A2DP Source)

Data width: 16 bits for each Channel.

Bit CLK: Sample Rate * Data Width. Uses internal ACLK to generate this)

 

 

Connections:

 

Function

CYW920706WCDEVAL

CYBT-343026-EVAL

I2S – DI

J22 – Pin 7

J4 – Pin 2

I2S – DO

J22 – Pin 8

J4 – Pin 1

I2S – BCLK

J22 – Pin 5

J7 – Pin 2

I2S – WS / LRC

J22 – Pin 6

J4 – Pin 5

 

 

Fig1: Wiring Example CYW920706WCDEVAL1 + Adafruit MAX98357 I2S Class D Mono AMP

 

 

 

Notes: CYBT-343026-EVAL

The onboard User button SW3 shares a pin with WS/LRC signal. To run the code correctly 2 changes are needed.

  1. 1) DIP Switch J9 should be open or in the ‘Off’ position.
  2. 2) Make sure AUDIO_MUTE_UNMUTE_ON_INTERRUPT’ is not #defined or commented. This will prevent the SW3 from being used as interrupt for Mute Unmute feature.

 

 

Choosing an I2S Codec:

                 Any codec that can support 16bit Audio at 44.1Kz or 48Khz sample rate will work. Audio Codec’s support configuration of the I2S parameters like Data Width, Sample rate etc. over I2C and some over SPI as well.  As an example, WM8731 by default is set up for a 24bit data, but can be changed to 16bit by modifying a register configuration of the WM8731 through the I2C / SPI control interface.

                MCLK (Master clock) is another important signal. Some codecs generate this internally, other need a TTL or Crystal oscillator. The frequency for MCLK is dependent on the Audio Sample rate, refer the codec datasheet to make sure the correct frequency is provided.

Due to Pin Multiplexing limitations on the CYW920706WCDEVAL & CYBT-343026-EVAL, the I2C pins are not free when I2S is in use. A Codec with SPI interface for configuration would be needed if the default configuration does not match.

 

 

#_msocom_1

Overview

Whitelist functionality in BLE allows a Peripheral to filter out the Central devices trying to scan or connect with the device. Based on the advertising filter policy selected,  the BLE peripheral will give the privilege of scanning or connecting only to the Centrals in whitelist . Whereas for a Central, if filter policy is set ‘whitelist only’, it will process advertisement packets only from the advertisers in the White list.  In this example, the device is configured as a Peripheral where you can select the advertising filter policies as well as you can add the devices to whitelist . Adding to whitelist means that only the Central devices that are added to the Peripheral’s whitelist will be able to receive the scan response packet and establish a connection with it.

 

APIs Used in the Example Project

  1. Setting advertising filter policy – Using the API wiced_btm_ble_update_advertisement_filter_policy( wiced_bt_ble_advert_filter_policy_t advertising_policy); the device advertising filter policy can be set.

                a. This API can be called either before starting the advertisement or while in advertising state.

                b. This API takes one parameter which defines the type of advertising policy.

    This parameter defines how the scan and connection requests are filtered

        •   BTM_BLE_ADVERT_FILTER_ALL_CONNECTION_REQ_ALL_SCAN_REQ– Process scan and connect requests from all Central devices.
        • BTM_BLE_ADVERT_FILTER_ALL_CONNECTION_REQ_WHITELIST_SCAN_REQ– Process scan requests only from devices in the White List and connect requests from all devices.
        • BTM_BLE_ADVERT_FILTER_WHITELIST_CONNECTION_REQ_ALL_SCAN_REQ– Process scan requests from all devices and connect requests only from devices in the White List.
        • BTM_BLE_ADVERT_FILTER_WHITELIST_CONNECTION_REQ_WHITELIST_SCAN_REQ– Process scan and connect requests only from devices in the White List.

 

Check the API details in wiced_bt_ble.h file (Path: /20719-B1_Bluetooth/include/20719/wiced_bt_ble.h)

           c. This API is useful when you want to change the advertising filter policy in runtime.

 

   2. Adding device to whitelist - Using the WICED   API wiced_bt_ble_update_advertising_white_list(wiced_bool_t add,wiced_bt_device_address_t remote_bda); you can add or remove the devices from  whitelist. In current implementation,  you can add only two devices to the whitelist using this API. If you want        to add more than 2 devices to the device whitelist, then  you can use the Vendor specific command. For that use the WICED API                         wiced_bt_dev_vendor_specific_command with the below parameters.  Check the API details in wiced_bt_dev.h (Path: /20719-B1_Bluetooth/include /20719               /wiced_bt_dev.h)

     a. Example: If you want to add device address 0x00A050112233 to whitelist, call the API                              wiced_bt_dev_vendor_specific_command(opcode,param_length,param_buffer,callback); where

          i) Opcode         : 0xE9 for adding whitelist

          ii) param_length  : 9  bytes

          iii) param_buffer :

          1. Length                    : 0x0E
          2. Address Type          : 0x00
          3. Address                  : 0x33,0x22,0x11,0x50,0xA0,0x00 ( LSB First )
          4. Enabling whitelist     : 0x04

          iv) callback     : call back for command complete

     b. Make sure you are stopping the advertisement before adding the device to whitelist

 

     3. Removing the device from whitelist: Using the  API wiced_bt_ble_update_advertising_white_list(wiced_bool_t add, wiced_bt_device_address_t      remote_bda); by passing the first parameter as False , the device can be removed from the whitelist. Note that you should call this API when the connection is           down, not in any other BLE states.

 

     4. To get maximum limit of whitelist: Using the API wiced_bt_ble_get_white_list_size(void); you will get the size of whitelist on the controller side.  Check the API details in wiced_bt_ble.h file.

 

Steps for Testing

 

  1. Connect the Eval board to PC and load the whitelist project attached below. Refer to the corresponding Kit User Guide for details on programming the firmware.
  2. Open the teraterm and open peripheral uart port with baud rate 115200bps
  3. You can see the logs as in Figure 1.
  4. Press ‘F’ for selecting the filter policy. For verifying ‘connecting from whitelist’ policy, select either 2 or 3
  5. Press ‘A’ to add the device address to whitelist and enter the device address (12 nibbles of address – MSB first).
  6. Press ‘S’ for starting advertisement. Device will start advertising with device name as ‘Whitelist_Demo’.
  7. Open any of BLE client apps (For example open CySmart app in mobile or PC). Try to connect to the device. The central won’t be able to connect, unless its address is what we added in whitelist (‘0x00A050112233’)
  8. Press ‘D’ to stop advertising.
  9. Make sure you are stopping the advertisement before adding the next device to whitelist.
  10. Refer Figure 1 for Debug logs.

 

Figure 1: Debug logs for Whitelist DemoLog.png

Overview

CySmart™ is a Bluetooth® Low Energy (BLE) or Bluetooth Smart utility developed by Cypress Semiconductor Corporation. CySmart can be used with any BLE products including BLE development kits from Cypress. It is available for Android as well as for iOS. Follow these links to download the app.

App StoreGoogle Play

To learn more about the app, download source code and to download app user guide, please visit CySmart – Mobile App.

 

Using CySmart with WICED Bluetooth devices

Though there are number of open-source mobile application that can be used with WICED application, this blog documents how to use CySmart with CYW920719Q40EVB-01 evaluation kit. Technically app can be used with any BLE compliant device as it follows Bluetooth SIG standard and hence this blog is merely a getting started guide for WICED users who are using CySmart for the first time. We will take the example of Hello Sensor application to leverage CySmart app on a peer device (iOS/Android device).   

Hello Sensor application - Hello Sensor application in WICED Studio provides paired devices with the following information (this blog uses CYW920719Q40EVB-01 evaluation kit and the user switch name is used accordingly. However, blog is valid for other boards as well and switch name shall be read accordingly):

  • A Hello Service (a proprietary service) with two proprietary characteristics:
    • The Hello Input characteristic (read-only) is used to read the number of times button (SW3) is pressed on the evaluation kit
    • The Hello Configuration read-write characteristic is used to configure the number of times an LED on the evaluation board blinks
  • A Device Information Service that provides information including:
    • Manufacturer Name
    • Model Number
    • System ID
  • A Battery Service that provides a battery-level indication

Note: Please download the CYW920719Q40EVB-01 kit user guide at www.cypress.com/cyw920719Q40EVB-01 (or respective kit guide for your target kit from kit's webpage) for download instructions for WICED Studio and to learn how to program the board with Hello Sensor application. Follow the steps and program the board with Hello Sensor application.

 

Testing Hello Sensor application with CySmart -  Once the board is programmed, please open CySmart application on your phone. It will show all available Bluetooth devices along with RSSI value. Hello Sensor application uses name "Hello" (device name can be changed in wiced_bt_cfg.c located under hello_sensor application directory in demo directory in WICED Studio). So, look for device named "Hello" (Figure 1).

 

Figure 1: Device named "Hello" appears in CySmart App

IMG_4971.PNG

Select the Hello device on the screen and it will connect to the Hello device (your kit) and take you to the next screen. Once connected, app opens services screen. CySmart detects the services supported by the device. As application has three services - Hello Sensor service (proprietary service), Device Information Service and Battery service, three services as well as GATT database options can be scrolled from left to right or vice versa on the screen (Figure 2).

 

Figure 2: Hello Sensor device services as seen by CySmart application

IMG_4991.PNGIMG_4972.PNG

IMG_4990.PNGIMG_4986.PNG

To review Hello Sensor Service, click on "GATT DB" or "Unknown service" (unknown service will eventually ask to use GATT DB as Hello Sensor is not a standard Bluetooth SIG service and can not be recognized by the app) (Figure 2). Once GATT DB is opened it will show three services supported by the device as shown in Figure 3(a). Select Unknown Service for Hello Sensor service. Two characteristics are supported by this service as mentioned earlier - a read-only characteristic "Hello Input" (Figure 3(b)) and a read/write characteristic "Hello configuration" (Figure 3(c)).

Select Read And Notify And Indicate Unknown characteristic (Hello Input) and it will lead to GATT database for this characteristic. Press read and observe value. Now press SW3 and then press read on the app and observe Hello count increases (Figure 3(d)). Now, come back to characteristic and select Read And Write Unknown characteristic (Hello Input) and it will lead to GATT database for this characteristic (Figure 3(d). Enter the hex value for the number of times you want to blink the LED on the board (Figure 3(e)). Once the value is entered and write is pressed, observe the LED on the board toggles for the number of times mentioned in the app.

 

Figure 3: (a) GATT database for Hello Sensor device services, (b) Characteristics within "Unknown Service"/customer service, (c)  Hello Input characteristic GATT database, (d) Hello configuration characteristic GATT database, (e) Writing value to control number of times LED blinks on the board

IMG_4973.PNGIMG_4974.PNGIMG_4977.PNG

IMG_4979.PNGIMG_4981.PNG

Navigate to the services screen to review Device Information Service (Figure 2). Select Device Information Service to observe device information (Figure 4).

 

Figure 4: Various Device Information Service characteristics

 

IMG_4992.PNG

Finally, navigate to the services screen to review Battery Service (Figure 2). Select the service and press Read button (Figure 5). Every time Read is clicked, battery level increases by 1% (0-6%). In Hello Sensor application, battery value is not an actual measured value. It is a dummy value that is increased on each read.

 

Figure 5: Battery level indicated by Battery Service

IMG_4987.PNG

This concludes the evaluation of Hello Sensor application with CySmart mobile application. Try changing various values in Hello_sensor.c file, program the device and observe the change in value on the app.

Filter Blog

By date:
By tag: