Infineon-AIROC HCI UART Control Protocol ModusToolbox - pdf-Software-V01 00-En
Infineon-AIROC HCI UART Control Protocol ModusToolbox - pdf-Software-V01 00-En
Infineon-AIROC HCI UART Control Protocol ModusToolbox - pdf-Software-V01 00-En
ModusToolbox™
Intended audience
This document is intended for application developers using a ModusToolbox™ Bluetooth® software
development kit (BTSDK) to create and test designs based on AIROC™ Bluetooth® devices.
Table of contents
About this document ....................................................................................................................... 1
Table of contents ............................................................................................................................ 1
1 About this document .............................................................................................................. 9
1.1 Acronyms and abbreviations .................................................................................................................. 9
1.2 IoT resources and technical support ...................................................................................................... 9
1.3 Hardware and Ssoftware prerequisites .................................................................................................. 9
2 Introduction ......................................................................................................................... 10
3 Downloading an application and configuration data ................................................................. 11
3.1 Introduction........................................................................................................................................... 11
3.2 Preparing for HCI commands................................................................................................................ 11
3.3 Download file formats ........................................................................................................................... 12
3.4 Downloading an application to RAM .................................................................................................... 13
3.4.1 HCI commands and events during a RAM download ...................................................................... 13
3.5 Downloading an application to serial flash .......................................................................................... 14
3.5.1 HCI commands and events during a serial flash download ........................................................... 14
4 AIROC™ HCI Control Protocol definition ................................................................................... 17
5 AIROC™ HCI Control Protocol commands ................................................................................. 19
5.1 Device commands: HCI_CONTROL_GROUP_DEVICE ........................................................................... 19
5.1.1 Reset ................................................................................................................................................. 19
5.1.2 Trace Enable ..................................................................................................................................... 19
5.1.3 Set Local Bluetooth® Device Address .............................................................................................. 20
5.1.4 Push NVRAM Data ............................................................................................................................. 20
5.1.5 Delete NVRAM Data .......................................................................................................................... 20
5.1.6 Inquiry............................................................................................................................................... 20
5.1.7 Set Visibility ...................................................................................................................................... 21
5.1.8 Set Pairing Mode .............................................................................................................................. 21
5.1.9 Unbond ............................................................................................................................................. 21
5.1.10 User Confirmation ............................................................................................................................ 22
5.1.11 Enable Coexistence .......................................................................................................................... 22
5.1.12 Disable Coexistence ......................................................................................................................... 22
5.1.13 Set Battery Level .............................................................................................................................. 22
5.1.14 Read Local Bluetooth® Device Address ........................................................................................... 23
5.1.15 Start Bond ........................................................................................................................................ 23
User Guide Please read the Important Notice and Warnings at the end of this document 002-16618 Rev. *J
www.infineon.com page 1 of 139 2021-11-30
AIROC™ HCI UART Control Protocol
ModusToolbox™
Table of contents
Note: Throughout the document, references to the ‘watch’ application are applicable to any application
running on the CYWxxxxx that supports the HCI control protocol defined in this document. Any
sample application that calls the wiced_transport_init() API with a valid callback in the
wiced_transport_data_handler_t member of the parameter struct supports the HCI
Control Protocol defined in this document.
2 Introduction
The ModusToolbox™ BSDK includes sample applications that can be executed on AIROC™ CYWxxxxx Bluetooth®
devices.
A real Bluetooth® product could have an onboard MCU that uses CYWxxxxx device to provide Bluetooth®
functionality. For such a product, MCU software would likely be used to control the device through a UART or
SPI interface via a protocol that allows the MCU to send and receive commands, events, and data. This
document describes a sample protocol for communication between an MCU and a CYWxxxxx device.
The CYWxxxxx devices support two operating modes: the Bluetooth® Host Controller Interface (HCI) mode and
the application mode. In the Bluetooth® HCI mode, the embedded stack in the device is not exercised and the
device behaves as a standard Bluetooth® HCI controller. A standard Bluetooth® HCI controller supports the
Bluetooth® HCI interface as defined in the Bluetooth® core specification [2]. In the Application mode, the
embedded stack in the CYWxxxxx device is used and the device does not behave as a standard Bluetooth®
controller.
Figure 1 shows the Bluetooth® HCI mode and application mode logical interfaces. In the Bluetooth® HCI mode,
the MCU communicates to the CYWxxxxx device using the standard Bluetooth® HCI protocol. In the application
mode, the MCU uses the AIROC™ HCI protocol defined in this document.
MCU MCU
Application Application
RFCOMM SDP SMP GATT/ATT RFCOMM SDP SMP GATT/ATT
L2CAP Virtual L2CAP
Bluetooth® HCI
Link Manager/Hardware Interfaces Link Manager/Hardware Interfaces
Interface
Figure 1 CYWxxxxx MCU interfaces in the Bluetooth® HCI and application modes
This document provides a sample protocol, referred to as the AIROC™ HCI Control Protocol, which can be used
in the application mode to support communication between the MCU (host) and an application running on the
CYWxxxxx device (controller).
When the CYWxxxxx device powers on, boot logic determines whether a serial flash is connected and, if so, it
contains a valid application image. If there is a valid application, the CYWxxxxx device loads and executes the
application. If there is no serial flash, then the CYWxxxxx device boots into and stays in the Bluetooth® HCI
mode where it waits for the MCU (host) commands. While in Bluetooth® HCI mode, the standard Bluetooth® HCI
protocol is used to download an application to the CYWxxxxx device and change the device mode to an
application mode. Note that the application may be downloaded and then executed from RAM, or may be
downloaded to the serial flash and then executed on the subsequent device reboot.
The AIROC™ HCI Control Protocol is defined in AIROC™ HCI Control Protocol definition.
Note: The code present in the ROM is in most cases is sufficient to perform the download. In some cases,
the MCU needs to load the minidriver which is used during the remainder of the download process.
The minidriver is a set of code and data that replaces the download code in the ROM of the
CYWxxxxx device. The minidriver download, provides a way to adapt the download process to
handle scenarios that the ROM code does not. For example, a design using the CYWxxxxx may
require downloading to a serial flash that requires a different protocol than the ROM can supply.
Downloading a minidriver that supports this protocol prior to downloading the application would
solve this situation. Minidrivers are not required and are not supplied for some platforms.
Minidrivers are optional and specific to each platform and when they are supplied can be found in
the 'platforms' subdirectories of the wiced_btsdk project (created when creating any AIROC™
board application with ModusToolbox™). For example, the CYW20819 minidriver can be found
here:
<USER_HOME>\mtw\mtb_shared\wiced_btsdk\dev-kit\20819A1\<git-
branch>\platforms\minidriver-20819A1-uart-patchram.hex
Note that the vendor-specific HCI commands described in this section have address and length fields in little-
endian byte order.
Note: Following a successful LAUNCH_RAM command, the device is in the application mode and the
application is running.
In the application mode, the UART configuration depends on the application. If the application
sets the baud rate to 3 Mbps at start-up then the MCU must also configure the UART for 3 Mbps
operation to successfully communicate with the CYWxxxxx device. The application sets the baud
rate using the following command: uart_SetBaudrate(0, 0, 3000000). The default
application baud rate is configured in the call to wiced_transport_init().
2. To speed up application downloading, the MCU host commands the CYWxxxxx device to communicate at a
new, higher rate by issuing the following vendor-specific UPDATE_BAUDRATE command:
01 18 FC 06 00 00 xx xx xx xx
In the above command, the xx xx xx xx bytes specify the 32-bit value of the new rate in bits per second.
For example, 115200 is represented as 00 C2 01 00.
The following response to the UPDATE_BAUDRATE command is expected within 100 ms:
04 0E 04 01 18 FC 00
3. The host switches to the new baud rate after receiving the response at the old baud rate.
4. If successful, the host issues the following DOWNLOAD_MINIDRIVER command:
01 2E FC 00
The following response is expected from the CYWxxxxx device within 100 ms:
04 0E 04 01 2E FC 00
If there is not response to the DOWNLOAD_MINIDRIVER command, the device may be in autobaud mode
(see Preparing for HCI commands). While it is required to send the DOWNLOAD_MINIDRIVER command, it
is optional to download a minidriver itself. The ROM download code behavior is sufficient to perform the
download for some cases. For these cases, the download process continues directly to step 5 to download
the application image.
If needed, the minidriver is loaded using WRITE_RAM vendor-specific commands, as described in step 5.
The hex file format indicates the RAM address for each data chunk in the file. Data chunks from the file can
be grouped up to the payload size of the WRITE_RAM command. To start the minidriver, use a LAUNCH_RAM
command, as described in step 8, to begin minidriver execution at the first address of the minidriver image.
For example, if the minidriver download starts at 0x220000, then the LAUNCH_RAM command should use
0x220000 as the launch address. After launching the minidriver, continue the application download process
with step 5.
5. After downloading the minidriver, the CHIP_ERASE command is sent. If it is desirable to preserve some data
in flash and only erase sectors that will be written, this step may be skipped.
Note: A SECTOR_ERASE command is also available for scenarios where only certain targeted sectors
need to be erased, though that is not part of the download procedure. Contact Infineon support
for information if that advanced functionality is needed.
The protocol follows the standard Bluetooth® HCI rules for parameter byte ordering. For example, the attribute
handle 0x210 is sent in two bytes, 0x10 followed by 0x02.
All commands and events are split into groups. Table 1 shows the groups defined by the AIROC™ HCI Control
Protocol.
See AIROC™ HCI Control Protocol commands for information on the AIROC™ HCI Control Protocol commands.
See AIROC™ HCI Control Protocol events for information on the AIROC™ HCI Control Protocol events.
5.1.1 Reset
The Reset command causes the CYWxxxxx to restart. After initialization completes, the CYWxxxxx sends a Device
Started event (see Device Started).
5.1.6 Inquiry
The Inquiry command lets an application cancel or start a Bluetooth® inquiry procedure.
If a device is found during an inquiry, the CYWxxxxx sends an Inquiry Result event (see Inquiry result).
When an inquiry procedure completes, the CYWxxxxx sends an Inquiry Complete event (see Inquiry complete).
Note: Attempts to make the CYWxxxxx discoverable and non-connectable will be rejected because,
according to the Bluetooth® specifications, a discoverable device should also be connectable.
After the CYWxxxxx receives this command, it reports command success or failure in the Command Status event
(see Command Status).
5.1.9 Unbond
The MCU can use this command to instruct the CYWxxxxx to remove bonding information (that is, security keys)
for the device whose Bluetooth® device address is passed as a parameter.
After the CYWxxxxx receives this command, it reports command success or failure in the Command Status event
(see Command Status).
Item Description
indicated by a null octet (0x00), and the following
octets (to fill up 248 octets, which is the length of the
parameter) do not have valid values.
5.2.1 LE Scan
The LE scan command instructs the CYWxxxxx to start or stop device discovery. The scan mode, window,
interval, and duration are configured locally in the application running on the CYWxxxxx (see the wiced_bt_cfg.c
file in ModusToolbox™). When the device starts scanning, it executes a high- duty-cycle scan where it listens for
advertisements during programmed windows occurring at programmed intervals for a programmed duration.
Unless canceled by the application, the device then automatically switches to a low-duty-cycle scan. The
device stops scanning after the low-duty-cycle scan duration.
Figure 2 shows an advertisement scanning cycle.
(Defined as (Defined as
high_duty_scan_duration_Slots) low_duty_scan_duration_Slots)
When the CYWxxxxx receives and processes this command, it reports the scan state change in the Scan Status
event (see LE Scan Status). Scan Status events are also sent when the CYWxxxxx switches from a high-duty-
cycle scan to a low-duty-cycle scan and from a low-duty-cycle scan to not scanning.
5.2.2 LE Advertise
The LE Advertise command instructs the CYWxxxxx to stop or start sending advertisements. Typically,
advertisements are sent so that a central device peer can discover and optionally connect to a peripheral
device peer. When a CYWxxxxx receives this command, it sends advertisements based on parameters
configured in the wiced_bt_cfg_ble_advert_settings_t structure of the wiced_bt_cfg_settings_t structure (which
is in the wiced_bt_cfg.c file of ModusToolbox™).
Initially, advertisements are sent out using a programmed high-duty-cycle advertisement profile. After the
high- duty-cycle duration (for example, high_duty_duration) expires, advertisements are sent out in
accordance with a programmed low-duty-cycle advertisement profile, which also has a duration (for example,
low_duty_duration). After the low_duty_duration, the CYWxxxxx stops sending advertisements.
Figure 3 shows the high-duty-cycle and low-duty-cycle advertisement-sending profiles.
When the CYWxxxxx receives and processes this command, it reports advertisement state changes in the
Advertisement State event (see LE Advertisement State). Advertisement State events are also sent when the
CYWxxxxx controller switches from the high-duty-cycle advertisements to low-duty-cycle advertisements and
from low-duty-cycle advertisements to no advertisements.
5.2.3 LE Connect
The LE Connect command instructs the CYWxxxxx to establish a connection to a specified peer device.
When the CYWxxxxx receives and processes this command, it reports the status to the Command Status event
(see Command Status).
When a connection is established, the CYWxxxxx sends the LE Connected event (see LE Connected).
5.2.5 LE Disconnect
The LE Disconnect command terminates a previously established Bluetooth® LE connection. The connection
handle is a two-byte value reported in the LE Connected event (see LE Connected), sent by the CYWxxxxx upon
a successful connection.
When the CYWxxxxx receives and processes this command, it takes one of the following actions:
• If the connection does not exist, it reports not connected in the Command Status event (see Command
Status).
• If the connections exist:
− It reports success in the Command Status event.
− It starts the disconnection process.
− It reports the LE Disconnected event when the disconnection process finishes.
5.2.6 LE Repair
This command instructs the CYWxxxxx to delete link keys associated with a previously paired device and re-
initiate a pairing sequence with the same device.
The NVRAM ID parameter should match the value reported to the MCU after the successful pairing in the NVRAM
Data event (see NVRAM Data).
Item Description
Advertisement data type (1 byte)
See wiced_bt_ble_advert_type_e which is in the
wiced_bt_ble.h
Length (2 bytes)
In little endian format
Read Request
Read Response
Figure 5 shows an example where BT2 must get an attribute value from MCU2.
Read Request
Read Response
When a GATT Read Response or a GATT Error Response is received over the Bluetooth® link, the hci_control
application sends the GATT Event Read Response (see GATT Event Read Response). The MCU should not send
any new discovery, read, or write commands until after receiving the GATT Event Read Response.
GATT Event Write Response). If all transmit buffers are already allocated and, thus, unavailable, then the
hci_control application saves the data received in the command and delays sending the GATT Event Write
Response until a transmit buffer becomes available and the data gets scheduled for transmission. The MCU
should not send any new discovery, read, or write commands until after receiving the GATT Event Write
Response.
Write Command
GATT Event Write Response) to a connected MCU. The MCU should not send any new discovery, read, or write
commands until after receiving the GATT Write Completed event.
Figure 7 shows a GATT Command Write Request sequence where the peer device does not require involvement
from its MCU.
Write Request
Write Response
Figure 7 GATT Command Write Request – peer MCU not involved in the write
Figure 8 shows a GATT Command Write Request sequence where the peer device requires involvement from its
MCU before executing the write.
Write Request
GATT Event Write Request
GATT Event Write Response). See Figure 8 for an example message sequence where this command is used.
When the command is received over the UART, the hci_control application sends a GATT Event Write Response
for the attribute handle received in the command.
GATT Event Write Response). If no transmit buffers are available, then the hci_control application saves the
notification data and delays sending the GATT Event Write Response until a transmit buffer becomes available
and the data is scheduled for transmission. The MCU should not send new discovery, read, or write commands
until after receiving the GATT Event Write Response.
Figure 9 shows a GATT Command Notify message sequence where a peer server (BT1) is prompted by its MCU
(MCU1) to send a characteristic value notification to the client (BT2).
GATT Event Write Response). The MCU should not send new discovery, read, or write commands until after
receiving the GATT Event Write Response.
Figure 10 shows a GATT Command Indicate message sequence where a peer server (BT1) is prompted by its
MCU (MCU1) to send a characteristic value indication to the client (BT2).
5.4.1 HF Connect
The HF Connect command instructs the CYWxxxxx to establish a connection to a specified Audio Gateway (AG),
which is typically a phone.
When a connection is established, the CYWxxxxx sends an HF Open event. The status field of that event tells
whether the connection could be established or not.
5.4.2 HF Disconnect
The HF Disconnect command instructs the CYWxxxxx to remove an existing connection to an AG.
When the CYWxxxxx receives and processes this command, it disconnects the connection identified by the
passed handle. When the connection is disconnected, it sends an HF Closed event.
When the CYWxxxxx receives and processes this command, it attempts to open an audio connection on the AG
identified by the passed connection handle. When an audio connection is established, it sends an HF Audio
Open event.
When the CYWxxxxx receives and processes this command, it attempts to close an audio connection on the AG
identified by the passed handle connection. When the audio connection is closed, it sends an HF Audio Close
event.
When the CYWxxxxx receives and processes this command, it attempts to accept/reject the SCO connection on
the AG identified by the passed handle connection.
5.4.7 HF AT commands
Each HF AT command instructs the CYWxxxxx to send a specific AT command to an AG.
Table 51 HF AT command
Item Description
Operating code See Table 51
Parameters Connection handle (2 bytes)
Command code (1 byte)
Numeric value (2 bytes)
Optional supporting character string (variable bytes)
Table 51 shows various available settings for the command code, numeric value, and optional string
parameters of the HF AT command.
When the CYWxxxxx receives and processes this command, it attempts to send the corresponding AT command
to the AG identified by the connection handle. When a response is received from the AG, it is sent back via an HF
Response event (see HF Response). Another command should not be sent until after the response event is
received.
Item Description
Parameters Address Bluetooth® device
(6 bytes) address of the peer
device.
Audio route 0: I2S
(1 byte) 1: UART
2: Sine (sends a sine
wave)
Item Description
(1 byte) 1: 32 kHz
2: 44.1 kHz
3: 48 kHz
Channel mode 0: Mono
(1 byte) 1: Stereo
After sending the Audio Stop command, the MCU should not send an Audio Start command until after it
receives an Audio Stop event.
Item Description
Operating code 0x07
Parameters -
When a peer device establishes a connection, the HID Opened event (see HID Opened) will be sent to the MCU.
At that time, the MCU can start sending HID reports.
If the CYWxxxxx is not connected to a paired host when it receives a HID send report command, it will try to
establish a HID connection. When this happens, the report will be lost.
Item Description
Operating code 0x03
Parameters Data Data received in the
(variable bytes) NVRAM Data event.
Note: This command should only be used in the case of PTS testing. Target side connections are made in
conjunction with an audio source connections.
The MCU can send this to the CYWxxxxx to establish an AV remote control target connection to a specified
device. Upon receiving this command, the CYWxxxxx establishes an ACL data connection if one does not exist,
performs the Service Discovery Protocol (SDP), searches for the AVRC service, and establishes an AVCTP
channel.
If the operation succeeds, the CYWxxxxx sends the AVRC Connected event (see AVRC Controller Connected)
back to the MCU. If the operation fails, the CYWxxxxx sends the AVRC Disconnected event (see AVRC Controller
Disconnected).
Note: This command should only be used in the case of PTS testing. Target side connections are made in
conjunction with an audio source connections.
The MCU can send this command to disconnect a previously established AV remote control connection.
Note: This command should only be used in the case of a standalone AVRC controller application. If
remote controller functionality is combined with the speaker, the AVRC command will be
established automatically when audio connection is established.
5.14.1 AG Connect
the MCU sends this command to the CYWxxxxx to establish a Bluetooth® Hands-Free audio gateway connection
to a specified device. Upon receiving the command, the CYWxxxxx establishes an ACL data connection,
performs an SDP search for the RFCOMM service, establishes a connection with the RFCOMM service, and
establishes a signaling connection with the specified Hands-Free device.
After an AG connection is successfully established, the CYWxxxxx will send the AG Connected event (see
5.14.2 AG Disconnect
The MCU sends this command to disconnect a previously established AG signaling connection.
After a CYWxxxxx receives this command, it sets the new value in the database and, if a value/time trigger is set
and the condition is met, sends a notification or indication with the new value to the AIO client.
After a CYWxxxxx receives this command, it sets the new value in the database and, if a value/time trigger is set
and the condition is met, sends a notification or indication with the new value to the AIO client.
After the CYWxxxxx receives this command, it tries to establish a connection to the specified AIO server. If a
Bluetooth® device address is not specified or set to all zeros, it starts LE scanning and connects to the first AIO
server it finds. After a connection is established, the CYWxxxxx performs characteristic and characteristic
descriptor discoveries.
Item Description
Index Index of the analog,
(1 byte) digital, or aggregate IO,
starting with 0.
After a CYWxxxxx receives this command, it sends a read request to the AIO server. After a read response comes
back from the AIO server, the CYWxxxxx will send the value back to the MCU in an AIO Read Response event (see
AIO Read Response).
After the CYWxxxxx receives this command, it sends a write request to the AIO server.
After a CYWxxxxx receives this command, it sends a write request to the AIO server to set a client characteristic
configuration descriptor. The notification and/or indication configuration is set through a combination of the
client characteristic configuration descriptor and the value and/or time trigger settings. See AIO Set Value
Trigger and AIO Set Time Trigger for information regarding setting value and time triggers.
User Guide 70 of 139 002-16618 Rev. *J
2021-11-30
AIROC™ HCI UART Control Protocol
ModusToolbox™
AIROC™ HCI Control Protocol commands
After a CYWxxxxx receives this command, it sends a write request to an AIO server to set a value trigger
descriptor.
Item Description
Values These bytes are a
(variable bytes) function of the condition
set.
After a CYWxxxxx receives this command, it sends a write request to the AIO server to set a time trigger
descriptor.
After a CYWxxxxx receives this command, it terminates its connection with the AIO server.
When the CYWxxxxx receives and processes this command, it attempts to accept or reject the audio stream
start request identified by the passed handle.
5.18.1 Connect
The Connect command instructs the CYWxxxxx to establish a LE COC connection to a specified device. Upon
receiving the command, the CYWxxxxx establishes a LE COC connection on the PSM set by the MCU.
If the operation succeeds, the CYWxxxxx will send the LE COC Connected event back to the MCU.
5.18.2 Disconnect
The LE COC Disconnect command instructs the CYWxxxxx to disconnect a previously established COC
connection.
Note: New alerts radio button should be selected before issuing the command.
Note: Unread alerts radio button should be selected before issuing the command.
Item Description
4: Confirm Value Failure
5: Pairing Not Supported
6: Encryption Key Size
Failure
7: Invalid Command
8: Pairing Failure
Unknown
9: Repeated Attempts
10: Internal Pairing Error
11: Unknown I/O
Capabilities
12: SMP Initialization
Failure
13: Confirmation Failure
14: SMP Busy
15: Encryption Failure
16: Bonding Started
17: Response Timeout
18: Generic Failure
19: Connection Timeout
Bluetooth® device address (6 bytes)
Item Description
HCI error codes defined as per Core Bluetooth®
specification.
6.2 LE events—HCI_CONTROL_GROUP_LE
The LE events are related to the Bluetooth® LE GAP profile and reported by the CYWxxxxx.
1
The high-duty-cycle and low-duty-cycle scan parameters for each state are defined in the wiced_bt_cfg.c file, which is included in
every application.
User Guide 88 of 139 002-16618 Rev. *J
2021-11-30
AIROC™ HCI UART Control Protocol
ModusToolbox™
AIROC™ HCI Control Protocol events
6.2.5 LE Connected
The hci_control application sends the LE Connected event when the CYWxxxxx establishes a connection with a
peer Bluetooth® LE device identified by address type and address. The connection handle identifies the
connection and can be used in consecutive requests to disconnect or transfer data. If the Role parameter is
zero, then the CYWxxxxx performs in the central role in a newly established connection. Otherwise, the
CYWxxxxx performs as a peripheral. If the CYWxxxxx is performing as a GATT client, then the MCU can issue the
GATT Command Read Request, GATT Command Write, or GATT Command Write Request commands to send
data to the peer. Otherwise, the GATT Command Notify or GATT Command Indicate commands should be used.
1
The advertisement intervals and durations for each state are defined in the wiced_bt_cfg.c file, which is included in every application.
User Guide 89 of 139 002-16618 Rev. *J
2021-11-30
AIROC™ HCI UART Control Protocol
ModusToolbox™
AIROC™ HCI Control Protocol events
6.2.6 LE Disconnected
When the Bluetooth® LE connection with a peer device is disconnected, the hci_control application sends the LE
Disconnected event. The connection handle and disconnection reason are passed as parameters.
See Figure 5 for a message sequence example where the GATT Event Read Request is used.
Item Description
Parameters Connection handle This is the connection
(2 bytes) handle reported in the LE
Connected event.
Data -
(variable bytes
See Figure 4 and Figure 5 for message sequence examples where the GATT Event Read Response is used.
See Figure 8 for a message sequence example where the GATT Event Write Request is used.
See Figure 8 for a message sequence example where the GATT Event Write Response is used.
See Figure 10 for a message sequence example where the GATT Event Indication is used.
See Figure 9 for a message sequence example where the GATT Event Notification is used.
6.4.1 HF Open
This event is sent when an RFCOMM connection is established with an AG. At this point, the Service Level
Connection (SLC) is still not established, so commands cannot yet be sent. The Bluetooth® device address and
connection handle are passed as parameters. The connection handle can be used by the MCU to send
commands or to identify a peer device that caused the event.
6.4.2 HF Close
This event is sent when an RFCOMM connection with an AG is closed.
6.4.3 HF Connected
This event is sent when the Hands-Free device and the AG have completed the protocol exchange necessary to
establish an SLC. At this point, the application can send any commands to the CYWxxxxx.
6.4.7 HF Response
The HF Response events are sent when a response is received from the AG for a command sent by the
application.
Table 199 shows various available values for the operating code, numeric value, and optional string
parameters of Table 198.
Item Description
Status AVRC Response Status
(1 byte)
Attribute ID 1: Title
(1 byte) 2: Artist
3: Album
4: Track number
5: Number of tracks
6: Genre
7: Playing time
Attribute length The length of the
(2 bytes) attribute data string.
Data Attribute data string.
(variable bytes)
Item Description
Bit 0: Unused
Bit 1: Off supported
Bit 2: All track scan supported
Item Description
Volume level (1 byte). The percentage (0 to 100) of
the maximum volume level of the local audio player
to be set.
Item Description
4: Characteristic is not found.
5: Characteristic descriptor is not found.
6: Invalid parameters passed in the
command
Item Description
(1 byte)
Minutes (1 byte) Current minutes
Seconds (1 byte) Current seconds
Exact time 256 Current seconds fraction. LSB = 1/256
(1 byte) seconds.
Day of week Current day of the week:
(1 byte) 1: Monday
2: Tuesday
3: Wednesday
4: Thursday
5: Friday
6: Saturday
7: Sunday
Adjust Reason Bit field indicating the reason for the change
(1 byte) in the time on the server.
Bit 0: Manual time update
Bit 1: External reference time update
Bit 2: Time zone change
Bit 3: Daylight savings time change
Item Description
Result Provides additional
(1 byte) status information, see
Command Status
Item Description
Handle (2 bytes) iAP2 EA session handle.
6.18.1 AG Open
This event is sent when RFCOMM connection is established with a Hands-Free device. At this point, the Service
Level Connection (SLC) is still not established, so commands cannot be sent. The Bluetooth® device address
and connection handle are passed as parameters. The connection handle can be used by the MCU to send
commands or to identify a peer device that caused the event.
6.18.2 AG Close
This event is sent when the RFCOMM connection with a Hands-Free device is closed.
6.18.3 AG Connected
This event is sent when the Hands-Free device and the AG have completed the protocol exchange necessary to
establish an SLC. At this point, the application can send a command to establish an audio connection to the
CYWxxxxx.
Item Description
Channel mode (1 byte) 0x08: Mono
0x04: Dual
0x02: Stereo
0x01: Joint Stereo
6.20.1 Connected
This event indicates to MCU that LE COC connection is established successfully.
6.20.2 Disconnected
This event indicates to MCU that LE COC connection is disconnected.
6.21.3 Connection Up
This event indicates to MCU that the connection with Alert Notification Client is established.
For example, an application that runs on a CYW20819 with power class 1 and built using ModusToolbox™
version 1.1.0.225 would report 0x01, 0x01, 0x00, 0xE1, 0x00, 0x53, 0x51, 0x00, 0x00.
References
[1] CYW920819EVB-02 Evaluation kit user guide
[2] Bluetooth® Core specification, version 4.2
[3] Apple ANCS specification
[4] Apple AMS specification
Revision history
IMPORTANT NOTICE
Edition 2021-11-30 The information given in this document shall in no For further information on the product, technology,
event be regarded as a guarantee of conditions or delivery terms and conditions and prices please
Published by characteristics (“Beschaffenheitsgarantie”) . contact your nearest Infineon Technologies office
(www.infineon.com).
Infineon Technologies AG
With respect to any examples, hints or any typical
81726 Munich, Germany values stated herein and/or any information
regarding the application of the product, Infineon WARNINGS
Technologies hereby disclaims any and all Due to technical requirements products may contain
© 2021 Infineon Technologies AG. warranties and liabilities of any kind, including dangerous substances. For information on the types
All Rights Reserved. without limitation warranties of non-infringement of in question please contact your nearest Infineon
intellectual property rights of any third party. Technologies office.
Do you have a question about this In addition, any information given in this document Except as otherwise explicitly approved by Infineon
document? is subject to customer’s compliance with its Technologies in a written document signed by
obligations stated in this document and any authorized representatives of Infineon
Go to www.cypress.com/support applicable legal requirements, norms and standards Technologies, Infineon Technologies’ products may
concerning customer’s products and any use of the not be used in any applications where a failure of the
product of Infineon Technologies in customer’s product or any consequences of the use thereof can
Document reference applications. reasonably be expected to result in personal injury.
002-16618 Rev. *J
The data contained in this document is exclusively
intended for technically trained staff. It is the
responsibility of customer’s technical departments
to evaluate the suitability of the product for the
intended application and the completeness of the
product information given in this document with
respect to such application.