äìÉ`çêÉ cä~ëÜ HCIStack1.1v17.3.4 Software Release...

bcore-srn-031Pb © Copyright CSR 2003 This material is subject to CSR’s non-disclosure agreement.

CSR Unit 400 Cambridge Science Park

Milton Road Cambridge CB4 0WH

United Kingdom Registered in England 3665875

Tel: +44 (0)1223 692000 Fax: +44 (0)1223 692001

www.csr.com

_äìÉ`çêÉ»cä~ëÜ

HCIStack1.1v17.3.4

Software Release Note

August 2003

http://www.csr.com/

Contents

bcore-srn-031Pb © Copyright CSR 2003 This material is subject to CSR’s non-disclosure agreement. Page 2 of 38

_äìÉ`çêÉ

cä~ëÜ H

CIStack1.1v17.3.4 Softw

are Release N

ote

Contents 1 Introduction .................................................................................................................................................... 3 2 Target Hardware............................................................................................................................................. 4 3 Release Functionality .................................................................................................................................... 5

3.1 Standard Bluetooth Functionality .......................................................................................................... 5 3.2 Extra Functionality ................................................................................................................................ 6 3.3 Functional Restrictions ......................................................................................................................... 7

4 Functional Changes Relative to HCIStack1.1v16.4 ..................................................................................... 8 5 Testing ......................................................................................................................................................... 9 6 Host Tool Compatibility............................................................................................................................... 10 7 Development Tools...................................................................................................................................... 11 Appendix A Functional Changes Relative to HCIStack1.1v16.4 ........................................................................... 12 Appendix B HCI Commands and Events......................................................................................................... 16

B.1 HCI Commands .................................................................................................................................. 16 B.2 HCI Events.......................................................................................................................................... 20

Appendix C Known Issues ............................................................................................................................... 21 Appendix D Issues Addressed Relative to HCIStack1.1v16.4 .............................................................................. 25 Appendix E Default PIO Allocation.................................................................................................................. 35 Document References ........................................................................................................................................ 36 Acronyms and Definitions.................................................................................................................................. 37 Record of Changes ............................................................................................................................................. 38

List of Tables

Table 1.1: HCIStack1.1v17.3.4 BlueCore2-Flash Build Identifiers .......................................................................... 3 Table 5.1: Transfer Rates ....................................................................................................................................... 9 Table 6.1: Host Tool Compatibility ........................................................................................................................ 10 Table Appendix A.1: Functional Changes Relative to HCIStack1.1v16.4 ............................................................. 15 Table Appendix B.1: HCI Commands ................................................................................................................... 19 Table Appendix B.2: HCI Events........................................................................................................................... 20 Table Appendix C.1: Known Issues for HCIStack1.1v17.3.4 Firmware................................................................. 24 Table Appendix D.1: Issues Addressed Relative to HCIStack1.1v16.4................................................................. 34 Table Appendix E.1: PIO Pins’ Default Functions ................................................................................................. 35

Introduction


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

1 Introduction This document describes a version of firmware “HCIStack1.1v17.3.4” to be run from flash memory in CSR’s _äìÉ`çêÉ»OJcä~ëÜ Bluetooth® wireless technology chip.

There are two versions of firmware HCIStack1.1v17.3.4:

1. A version to be run from ROM in a BlueCore2-ROM. Optionally this uses configuration data held in an external EEPROM device, though more typically configuration data is loaded from the device’s host during initialisation.

2. A version to be run from the flash memory in a BlueCore2-Flash “stacked flash” devices. This can use configuration data held in flash, but it cannot access an external EEPROM device.

This document describes the second build variant. The full set of documents describing this build is given in [DOCLIST].

The firmware’s functionality is very similar to HCIStack1.1v16.4, which was written for CSR’s BlueCore2-External Bluetooth chip. The primary change between HCIStack1.1v16.4 and HCIStack1.1v17.3.4 has been porting to BlueCore2-ROM and BlueCore2-Flash, although other minor enhancements and bug fixes have also been included.

The build handles Bluetooth up to HCI only. This document does not describe the functionality of any “RFCOMM” firmware builds, as used with BlueLab™ and BlueCore Host Software (BCHS).

This document deals mainly with software that runs on the Bluetooth chip; any associated “host” software is described only in passing.

This document uses the term “preliminary” to mean that a particular function has had only limited testing by CSR, and so customers wishing to use the function must satisfy themselves that the support is suitable for their use in production.

The firmware is provided in two versions, differing in their maximum effective encryption key lengths:

Maximum Effective Encryption Key Length Full Build Name Build ID

56 bits bc02k_4hci_bt1.1_17.3.4_encr56_noe2 878 (0x36e)

128 bits bc02k_4hci_bt1.1_17.3.4_encr128_noe2 932 (0x3a4)

Table 1.1: HCIStack1.1v17.3.4 BlueCore2-Flash Build Identifiers

A build’s ID is accessible as the “HCI Revision” value returned by the HCI Read_Local_Version_Information command.

Target Hardware


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

2 Target Hardware The release runs from flash memory in CSR’s BlueCore2-Flash Bluetooth chip.

The chip presents a UART or USB host connection.

The firmware uses a flash memory device to hold the program, constant data and Persistent Store (data that survives through power cycling).

The firmware has only been tested using BlueCore2-Flash.

Release Functionality


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

3 Release Functionality

3.1 Standard Bluetooth Functionality

The software has been written against version 1.1 of the Bluetooth Core Specification: [BT]. The release provides:

Bluetooth components: Baseband (including LC), LM and HCI Standard USB (v1.1) and UART (H4) HCI Transport Layers All standard radio packet types Full Bluetooth data rate Operation with up to seven slaves Operation with up to three SCO links, routed to one or more slaves All standard SCO voice codings, plus “transparent SCO” Standard operating modes: page, inquiry, page-scan and inquiry-scan All standard pairing, authentication, link key and encryption operations Standard Bluetooth power saving mechanisms: Hold, Sniff and Park modes, including “Forced Hold” Dynamic control of peers’ transmit power via LMP Master/Slave switch. This allows a device to connect itself to an established piconet Broadcast Limited scatternet Channel quality driven data rate (CQDDR) All standard Bluetooth Test Modes Standard firmware upgrade via USB (DFU)

The build’s supported Bluetooth features are detailed in the standard PICS documents, available from CSR’s web site.



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

3.2 Extra Functionality

The build extends the standard Bluetooth functionality with the following features:

The firmware supports BlueCore Serial Protocol (BCSP), a proprietary, reliable alternative to the standard Bluetooth “H4” UART Host Transport.

The firmware provides a set of approximately 50 manufacturer-specific HCI extension commands. This command set, called BCCMD (BlueCore Command) provides: Access to the chip’s general-purpose PIO port Access to the chip’s Bluetooth clock. (This can help transfer connections to other Bluetooth

devices.) The negotiated effective encryption key length on established Bluetooth links Access to the firmware’s random number generator Controls to set the default and maximum transmit powers (These can help to reduce interference

between overlapping, fixed-location piconets.) Dynamic UART configuration Radio transmitter enable/disable, a simple command connects to a dedicated hardware switch that

determines whether the radio can transmit The firmware can read the voltage on a pair of the chip’s external pins. (This is normally used to build a

battery monitor, using either VM or host code.) A block of BCCMD commands provides access to the chip’s Persistent Store configuration database

(PS). The database sets the device’s Bluetooth address, Class of Device, radio (transmit class) configuration, SCO routing, LM and USB constants, etc.

A UART “break” condition can be used in three ways: Presenting a UART break condition to the chip can force the chip to perform a hardware reboot Presenting a break condition at boot time can hold the chip in a low power state, preventing normal

initialisation while the condition exists With BCSP, the firmware can be configured to send a break to the host before sending data –

normally used to wake the host from a deep sleep state The DFU standard has been extended with public/private key authentication, allowing manufacturers to

control the firmware that can be loaded onto their Bluetooth modules. A modified version of the DFU protocol allows firmware upgrade via the chip’s UART. A block of “radio test” or BIST commands allows direct control of the chip’s radio. This aids the

development of modules’ radio designs and can be used to support Bluetooth qualification. Virtual Machine (VM). The firmware provides the VM environment in which to run application-specific

code. Although the VM is mainly used with BlueLab and “RFCOMM builds” (alternative firmware builds providing L2CAP, SDP and RFCOMM), the VM can be used with this build to perform simple tasks such as flashing LEDs via the chip’s PIO port.

Hardware low power modes: shallow sleep and deep sleep. The chip drops into modes that significantly reduce power consumption when the software goes idle.

SCO channels are normally routed over HCI (over BCSP). However, up to three SCO channels can be routed over the chip’s single PCM port (at the same time as routing any other SCO channels over HCI).

Preliminary support for the chip’s audio CODEC.



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

3.3 Functional Restrictions

The following major functional restrictions apply to this release:

There is only limited support for Bluetooth scatternets, as described in [SCATTERNET]. The chip can support up to seven connections: it can be a slave of up to two masters and/or a master of

up to seven slaves. Some operations are restricted or disallowed in a scatternet. There is no support for SCO when the device is part of a scatternet. The firmware provides preliminary support for SCO over USB and H4 host transports, but testing has

been very limited. (See issue B.104.) There is no support for SCO flow control over HCI. There is only limited support for HCI Quality of Service (QoS), as described in [BCHCI]. In some situations when supporting a scatternet, Bluetooth slaves cannot perform page, page-scan,

inquiry or inquiry-scan. A slave with only a single connection (to its only master) can perform these operations; this is an improvement over HCIStack1.1v15.x builds.

Support for passing multiple audio (SCO) streams over BlueCore2-External’s PCM port is still preliminary.

Support for the chip’s audio CODEC (see K14.16) is still preliminary. The build’s new functionality to allow a system clock to be provided more than 5ms after being

demanded is still preliminary. This is described under K15.46 and controlled with PSKEY_CLOCK_STARTUP_DELAY.

Appendix C lists the firmware’s known issues.

Functional Changes Relative to HCIStack1.1v16.4


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

4 Functional Changes Relative to HCIStack1.1v16.4 The following significant functional changes have been made to the firmware, relative to BlueCore2-External build HCIStack1.1v16.4:

The code base has been ported to BlueCore2-ROM and BlueCore2-Flash. The chip can operate with a wider selection of clock frequencies than BlueCore2-External. Some versions of the chip provide an audio CODEC, suitable for driving a microphone and low power

speaker. Preliminary support has been added to allow this to be connected to a SCO channel. This support is typically used in “RCFOMM builds” to make a headset.

A fuller list of the significant functional changes is given in Appendix A.

Testing


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

5 Testing The firmware has been tested in the following environments:

The firmware has been run on 16 BlueCore2-Flash devices. Two Bluetooth devices running the firmware in a clean radio environment to obtain throughput data

(rates below). One device running the firmware with a second device running a variety of CSR’s previously published

builds.

The testing has included:

Automated exercising of the test schedule from UnplugFests 5, 6 and 7. Category-A Certification testing of the baseband and LM using Cetecom’s certification tester. Automated exercising of each of the HCI commands that were expected to work. All HCI commands

have been subjected to boundary testing. Repeated automated testing of a number of complex operations including managing stored link keys,

master/slave switches, authentication and pairing, repeated ACL and SCO link create/destroy cycles, managing piconets and exercising of Bluetooth low power modes.

Interface testing with BlueSuite™ versions 1.09, 1.10, 1.11, 1.17 and 1.19.

Automated testing has been conducted using all three supported HCI transports (BCSP, USB and H4). UART-based transports have been run at a variety of baud rates.

The following sustained, single-link, bulk ACL transfer rates were observed when transferring 40Mbyte files. The tests were run in a clean radio environment using antennae, and with a wired link with 40dB attenuation:

Host Transport Mode Direction kbps

BCSP uni-directional master → slave 721

BCSP uni-directional slave → master 719

BCSP bi-directional master → slave slave → master

426 409

USB uni-directional master → slave 713

USB uni-directional slave → master 715

USB bi-directional master → slave slave → master

432 432

H4 uni-directional master → slave 703

H4 uni-directional slave → master 701

H4 bi-directional master → slave slave → master

425 422

Table 5.1: Transfer Rates

Host Tool Compatibility


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

6 Host Tool Compatibility The following host tools are compatible with this firmware release:

Host Tools Windows® Versions Tool Versions Note(s)

BlueSuite NT4, Win98, Win98SE, WinME, Win2000, WinXP v1.09, v1.10, v1.11, v1.17, v1.19 DFUWizard NT4, Win98, Win98SE, WinME, Win2000, WinXP v1.00 to v1.20 DFUTools NT4, Win98, Win98SE, WinME, Win2000, WinXP v1.30 to v1.50 (a)

BlueLab NT4, Win2000, WinXP v2.4, v2.5, v2.6

Table 6.1: Host Tool Compatibility

Note: (a) DFUTools v1.30 has known problems with VM applications and 8Mbit flash devices.

DFUTools v1.30 and v1.40 have known problems placing Persistent Store data in DFU files. DFUTools v1.30 was incorrectly shown on CSR’s web site as v1.3.

Development Tools


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

7 Development Tools This firmware build was generated using the following tools:

XAP C cross compiler v3.11 on Sun Solaris 2 XAP Assembler/Linker v1.09 on Sun Solaris 2



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

Appendix A Functional Changes Relative to HCIStack1.1v16.4 This section lists the significant functional changes made to the firmware relative to build HCIStack1.1v16.4, a previous build for BlueCore2-External. (See also the list of issues addressed in Appendix D.)

ID Description

B-457

The value of PSKEY_ANA_FREQ specifies the frequency of the chip’s crystal or external clock. See H17.133. The BlueCore2-Flash hardware can handle many more clock frequencies than BlueCore2-External, as described in [BC02KFDB] and thus the coding of this PS Key has changed to suit. The PS Key’s value is now the clock frequency expressed in kHz. The PS Key’s value should always be a multiple of 10. Only a handful of the available frequencies have been tested by CSR. See B-470. This change manifests itself in the changed meaning of the value of PSKEY_ANA_FREQ, and in the new PS Keys PSKEY_CDMA_LO_REF_LIMITS and PSKEY_CDMA_LO_ERROR_LIMITS. See B-470 and H17.133.

B-470

The default (psrom) value for PSKEY_ANA_FREQ has been changed from 16MHz to 26MHz. The coding of information held under PSKEY_ANA_FREQ has been changed on BlueCore2-Flash to suit the hardware: the value is now the frequency represented in kHz, so the new default value is 26000. See B-457 and B-519.

B-472

The default value of PSKEY_TXRX_PIO_CONTROL has been changed on BlueCore2-Flash from 1 (use PIO[0] and PIO[1] to drive an external PA/LNA) to 0 (do not drive PIO[0] and PIO[1]). The new value is a better match for Bluetooth Class 2 and 3 devices, as these normally do not use an external PA or LNA. See H17.89.

B-476

The set of acceptable values for PSKEY_CLOCK_REQUEST_ENABLE has been extended on BlueCore2-Flash to allow PIO[2] to request the external clock rather than PIO[6]. The PS Key can also be set so that the external clock is requested on PIO[2] when either the chip needs it (i.e., when the chip is not in deep sleep) or when a signal is applied to PIO[3]. See B-522.

B-486 PSKEY_FORCE_16MHZ_REF_PIO has been given a default of 10. Consequently, if PIO 10 is found to be 1 at boot then the chip assumes it has a 16MHz clock. See B-842.

B-491

Code has been added to compensate for crystal frequency change with temperature, controlled by PSKEY_TEMPERATURE_VS_DELTA_ANA_FTRIM. The PS Key’s default setting leaves this new functionality disabled. This code has not been tested. See H17.125.

B-522

The default value of PSKEY_CLOCK_REQUEST_ENABLE has been changed to 3, meaning the chip requests an external clock be provided on PIO[2], and that the request is a logical OR of BlueCore’s need for a clock and the input on PIO[2]. See B-476.

H16.154 H17.44

Functionality added to the LM has caused the data block it uses to store information on parked slaves to grow by one uint16 word. The default value of PSKEY_PMALLOC_SIZES has been adjusted to suit.

H16.159 H17.69

The “User” host transport, selected by setting PSKEY_HOST_INTERFACE to “phys_bus_user”, has been removed to reduce the firmware program size. The support is only used by the VM. In HCI builds, the VM is almost always used to flash LEDs via PIO pins.



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

ID Description (continued)

H16.66 K15.17 K15.35

The new BCCMD command Bypass_UART allows a UART connection to pass through BlueCore2-Flash to four PIO lines. This lets the host’s UART connect through BlueCore2-Flash to another UART device. The command forces BlueCore2-Flash to enter a deep sleep state, from which it can be woken only by a hardware reset. The command is described in [BCCMDS]. This hardware feature was added to BlueCore2-Flash to allow a cell phone’s baseband chip to use its UART port to connect either to BlueCore or to an infra-red (IrDA) transceiver chip. The preferred approach would have been to connect all three UARTs together, and for the IrDA device to tri-state its UART lines when (not) required (e.g., when its Reset line is asserted). This was impractical, and so the pass-through functionality has been added to BlueCore. Testing has shown that implementation of this command is broken in build HCIStack1.1v17.3.4, but there is a workaround; see known issue B-639.

H17.47 H16.94 H17.105 H17.130 H17.131 H17.141 B-375 B-473

K.8 K15.58 K15.59

Many minor changes have been made to port the BlueCore2-External code base to run on BlueCore2-Flash. The following PS Keys have been created:

PSKEY_RF_TRAP_BAD_DIVISION_RATIOS PSKEY_RADIOTEST_CDMA_LO_REF_LIMITS PSKEY_TEST_DELTA_OFFSET PSKEY_TEST_DELTA_MOD_DELAY PSKEY_RX_DYNAMIC_LVL_OFFSET PSKEY_TEST_FORCE_OFFSET PSKEY_USE_INTERNAL_LOOP_FILTER PSKEY_PCM_LOW_JITTER_CONFIG PSKEY_PCM_CVSD_USE_NEW_FILTER

The following PS Keys have had their default values changed: PSKEY_LC_POWER_TABLE PSKEY_LC_MAX_TX_POWER PSKEY_ANA_RX_LEVEL PSKEY_ANA_RX_FTRIM PSKEY_ANA_CONFIG PSKEY_LO_ADC_AMPL_MIN PSKEY_LO_ADC_AMPL_MAX PSKEY_TX_OFFSET_HALF_MHZ PSKEY_TX_PRE_LVL PSKEY_TX_FILTER_CONFIG PSKEY_CPU_IDLE_MODE PSKEY_RF_RESONANCE_TRIM PSKEY_LOOP_FILTER_TRIM PSKEY_RX_DYNAMIC_RF_TRIM PSKEY_DEEP_SLEEP_CORRECTION_FACTOR

This block of PS Keys has been removed because the PS Keys’ functionality has largely been superseded by the temperature compensation support, described under H17.125.

PSKEY_TXLVL_TX_OFFSET PSKEY_TXLVL_LO_OFFSET PSKEY_TXLVL_TX_MINIMUM PSKEY_TXLVL_TX_MAXIMUM PSKEY_TXLVL_LO_MINIMUM PSKEY_TXLVL_LO_MAXIMUM PSKEY_TXLVL_LUT PSKEY_ENABLE_MAX_TXLVL PSKEY_RXLVL_TRIM_ENABLE PSKEY_RXLVL_RX_OFFSET PSKEY_RXLVL_LO_OFFSET PSKEY_RXLVL_RX_MINIMUM PSKEY_RXLVL_RX_MAXIMUM PSKEY_RXLVL_LO_MINIMUM PSKEY_RXLVL_LO_MAXIMUM PSKEY_RXLVL_LUT

This PS Key’s function and default have changed: PSKEY_TX_MOD_INDEX_TRIM



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote


H17.95

The default value of PSKEY_HOST_INTERFACE_PIO_USB has been changed from “no value” to 9 on BlueCore2-Flash builds. This means that if PIO[9] is high at boot on BlueCore2-Flash then the firmware uses the USB host transport rather than the value stored in PSKEY_HOST_INTERFACE (which defaults to BCSP).

H17.98

On BlueCore2-Flash and later chips, with HCIStack1.1v17.x and later builds, PIO pins can be set to have weak or strong pull up/down, controlled by the new PIO_Strong_Bias BCCMD command. When the chip is reset, PIO pins have weak pull up/down. Writing a 1 to a bit in the command’s uint16 value causes the corresponding PIO pin to apply strong pull up/down.

H17.125

BlueCore2-Flash contains circuitry that allows the firmware to detect changes in temperature. This can be used to adjust the transmitter to compensate for transmit power changes that occur with temperature. This functionality is not normally needed. The support can benefit designs that require an extreme operating temperature range, and that use external components with wide manufacturing tolerances, e.g., transmit filters. The compensation support is controlled with new PS Keys:

PSKEY_TEMPERATURE_VS_DELTA_INTERNAL_PA, which holds a lookup table for values to add or subtract from the internal power amplifier setting at the given temperature.

PSKEY_TEMPERATURE_VS_DELTA_TX_PRE_LVL, which holds a lookup table in the same format for the transmit preamplifier.

PSKEY_TEMPERATURE_VS_DELTA_TX_BB, which holds a lookup table in the same format for the transmit baseband level.

PSKEY_TEMPERATURE_CALIBRATION. This calibrates the temperature compensation code, and must be set during manufacture for each module.

The temperature compensation functionality is only enabled if a value is held in PSKEY_TEMPERATURE_CALIBRATION. By default, this PS Key holds no value. To enable this functionality, it is currently recommended that value {0017, 5eb3} should be written to PSKEY_TEMPERATURE_CALIBRATION (0x03db). See B-491.

H17.132

Added PSKEY_HOST_INTERFACE_PIO_H4 and gave it a default value of zero. If the PIO pin specified by this PS Key (default PIO[0]) is found to be 1 during booting then the firmware uses the H4 host transport, rather than the value of PSKEY_HOST_INTERFACE (which defaults to BCSP). This gives the means to set the host transport to H4 for a ROM part where there is no PS store in EEPROM. Using this mechanism configures the UART to suit H4 (0xa8), overriding the value stored in PSKEY_HOSTIO_UART_PS_BLOCK. If PSKEY_HOST_INTERFACE_PIO_USB is also found to be 1 during booting then the chip uses USB. See issue H17.95. If the new PS Key is given the value 0xffff then it is treated as if it had no value stored in the PS Key, i.e., the feature is turned off and no PIO pin is dedicated to this operation.

H17.133

Added PSKEY_FORCE_13MHZ_REF_PIO and gave it a default value of 1. If the PIO pin specified by this PS Key (default PIO[1]) is found to be 1 during booting then the firmware presumes it is supplied with a 13MHz system clock, rather than the value of PSKEY_ANA_FREQ (which defaults to 26MHz; see B-470). This gives the means to specify the chip’s clock frequency for a ROM part where there is no PS in EEPROM. If the new PS Key has the value 0xffff, then it is treated as if it had no value stored in the PS Key, i.e., the PS Key’s feature is turned off and a PIO pin is not dedicated to frequency selection.

H17.138 The default setting of PSKEY_HOSTIO_MAP_SCO_PCM has been changed to TRUE for BlueCore2-Flash. This setting routes the (first and only) SCO channel over the chip’s PCM port.

H17.139 The default setting of PSKEY_HOSTIO_UART_PS_BLOCK has been changed to set the default baud rate to 115.2kbaud.



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote


K14.16

The BlueCore2-Flash hardware includes an audio CODEC that can drive a microphone and low power speaker. The firmware can connect the CODEC to a SCO channel. The hardware is not available on all BlueCore2-Flash packages; typically, the support is used on (RFCOMM builds for) wireless headsets. The CODEC is configured with new PS Keys:

PSKEY_CODEC_IN_GAIN PSKEY_CODEC_OUT_GAIN PSKEY_CODEC_PIO

Use of the CODEC is described further in [BCHCI].

K15.46

If BlueCore2-Flash is using an external clock source rather than a crystal, when it needs to exit deep sleep it signals via a PIO pin that it needs the clock to be provided. The chip hardware presumes this will be stable within 5ms of being requested. Some hosts cannot provide a stable clock within 5ms, so a rather ugly workaround has been provided. The new PS Key PSKEY_CLOCK_STARTUP_DELAY can be set to describe the period in which the host guarantees to provide a clock. The workaround internally takes over PIO pin 4, so PIO4 must not be connected if a value is written to the PS Key. (By default, no value is stored under the PS Key.) The workaround also results in slightly less efficient power consumption, as the processor must remain powered for longer when entering and leaving deep sleep.

T.572 H17.4

The [BT] specification allows a Class 1 device to perform page and inquiry operations at greater than 4dBm. However, if it makes a connection, and a subsequent exchange of supported feature information reveals that the paged device does not support LMP power control (RSSI), then the local device must not transmit at more than 4dBm to that device. In firmware builds before HCIStack1.1v17.3.4, PSKEY_LC_DEFAULT_TX_POWER sets the transmit power used for page and inquiry operations. It also sets the power used on freshly created links before LMP power control takes effect. These constraints combine to mean that for builds before HCI 17.3.4, the value of PSKEY_LC_DEFAULT_TX_POWER must not exceed 4dBm for a Class 1 device, and thus it can only perform page and inquiry operations at a maximum of 4dBm. In HCIStack1.1v17.3.4, PSKEY_LC_MAX_TX_POWER_NO_RSSI sets the maximum transmit power to be used when the local device determines that the peer doesn’t support LMP power control. This is normally left at its default of 4dBm. This allows the value of PSKEY_LC_DEFAULT_TX_POWER to be set greater than 4dBm for a Class 1 device, so allowing page and inquiry operations at greater power. (The maximum entry of PSKEY_LC_POWER_TABLE for Class 2 and 3 devices make the new PS Key irrelevant for them.)

Table Appendix A.1: Functional Changes Relative to HCIStack1.1v16.4

HCI Commands and Events


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

Appendix B HCI Commands and Events This section lists the implementation status of the HCI commands and events.

B.1 HCI Commands

The firmware accepts all HCI commands defined in [BT]. The “Available” column in the table B.1 indicates whether the command’s underlying functionality is provided.

Where the functionality is not provided, the command is gracefully rejected. For example, attempts to change to optional page scan modes using the Write_Page_Scan_Mode command are gracefully rejected.

Link Control Commands

HCI Command Available Notes

Inquiry Yes

Inquiry_Cancel Yes

Periodic_Inquiry_Mode Yes

Exit_Periodic_Inquiry_Mode Yes

Create_Connection Yes (a) (b)

Disconnect Yes (b)

Add_SCO_Connection Yes (b) (c) (d)

Accept_Connection_Request Yes

Reject_Connection_Request Yes

Link_Key_Request_Reply Yes

Link_Key_Request_Negative_Reply Yes

PIN_Code_Request_Reply Yes

PIN_Code_Request_Negative_Reply Yes

Change_Connection_Packet_Type Yes

Authentication_Requested Yes

Set_Connection_Encryption Yes

Change_Connection_Link_Key Yes

Master_Link_Key Yes

Remote_Name_Request Yes

Read_Remote_Supported_Features Yes

Read_Remote_Version_Information Yes

Read_Clock_Offset Yes



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

Link Policy Commands


Hold_Mode Yes

Sniff_Mode Yes

Exit_Sniff_Mode Yes

Park_Mode Yes

Exit_Park_Mode Yes

QoS_Setup Yes (e)

Role_Discovery Yes

Switch_Role Yes

Read_Link_Policy_Settings Yes

Write_Link_Policy_Settings Yes

Host Controller and Baseband Commands


Set_Event_Mask Yes

Reset Yes

Set_Event_Filter Yes

Flush Yes

Read_PIN_Type Yes

Write_PIN_Type Yes

Create_New_Unit_Key Yes

Read_Stored_Link_Key Yes

Write_Stored_Link_Key Yes

Delete_Stored_Link_Key Yes

Change_Local_Name Yes (f)

Read_Local_Name Yes

Read_Connection_Accept_Timeout Yes

Write_Connection_Accept_Timeout Yes

Read_Page_Timeout Yes

Write_Page_Timeout Yes

Read_Scan_Enable Yes

Write_Scan_Enable Yes

Read_Page_Scan_Activity Yes

Write_Page_Scan_Activity Yes

Read_Inquiry_Scan_Activity Yes

Write_Inquiry_Scan_Activity Yes

Read_Authentication_Enable Yes

Write_Authentication_Enable Yes

Read_Encryption_Mode Yes

Write_Encryption_Mode Yes

Read_Class_of_Device Yes

Write_Class_of_Device Yes



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

Read_Voice_Setting Yes (g)

Write_Voice_Setting Yes (g)

Read_Automatic_Flush_Timeout Yes

Write_Automatic_Flush_Timeout Yes

Read_Num_Broadcast_Retransmissions Yes

Write_Num_Broadcast_Retransmissions Yes

Read_Hold_Mode_Activity Yes

Write_Hold_Mode_Activity Yes

Read_Transmit_Power_Level Yes

Read_SCO_Flow_Control_Enable No (c) (d)

Write_SCO_Flow_Control_Enable No (c) (d)

Set_Host_Controller_To_Host_Flow_Control Yes

Host_Buffer_Size Yes

Host_Number_Of_Completed_Packets Yes

Host Controller and Baseband Commands (continued)


Read_Link_Supervision_Timeout Yes

Write_Link_Supervision_Timeout Yes

Read_Number_Of_Supported_IAC Yes

Read_Current_IAC_LAP Yes

Write_Current_IAC_LAP Yes

Read_Page_Scan_Period_Mode Yes

Write_Page_Scan_Period_Mode Yes

Read_Page_Scan_Mode Yes

Write_Page_Scan_Mode Yes (h)

Information Parameters


Read_Local_Version_Information Yes

Read_Local_Supported_Features Yes

Read_Buffer_Size Yes

Read_Country_Code Yes

Read_BD_ADDR Yes

Status Parameters


Read_Failed_Contact_Counter Yes

Reset_Failed_Contact_Counter Yes

Get_Link_Quality Yes

Read_RSSI Yes



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

Testing Commands


Read_Loopback_Mode Yes

Write_Loopback_Mode Yes (i) (j)

Enable_Device_Under_Test_Mode Yes

Table Appendix B.1: HCI Commands

Notes (for HCI Commands): (a) Up to seven connections: a slave of up to two masters, and/or a master of up to seven slaves. Some

operations restricted or non-functional in a scatternet. (b) Chip resource limits constrain the rate at which ACL and SCO connections can be made and broken to

approx. 20 per 15 seconds. The time limit can be configured. (c) Up to three SCO links. Each SCO link can be routed over the chip’s PCM interface or over HCI/BCSP.

Preliminary support for SCO over USB or H4 is in place, but testing has been light.

(d) No HCI SCO Host Controller to Host flow control support. No HCI SCO Host to Host Controller flow control support.

(e) Limited support for “best effort” and “guaranteed” QoS only. (f) Local name is maintained through a reset/reboot. (g) Commands extended according to [BT] Erratum 1275 to support transparent SCO. (h) Optional paging schemes not supported. (i) Remote ACL loopback sometimes deadlocks when the devices’ flow control mechanisms assert to each

other. Issue H12.93. (j) HCI Reset doesn’t work if the device is in local loopback mode. Issue H15.254.



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

B.2 HCI Events

The Bluetooth module only emits the HCI event messages needed to support the implemented features. For example, the chip does not support the optional page scan modes, so the firmware does not emit the Page_Scan_Mode_Change event. The table’s “Available” column indicates whether the firmware can emit the event message.

HCI Event Available Notes

Inquiry_Complete Yes Inquiry_Result Yes Connection_Complete Yes Connection_Request Yes Disconnection_Complete Yes Authentication_Complete Yes Remote_Name_Request_Complete Yes Encryption_Change Yes Change_Connection_Link_Key_Complete Yes Master_Link_Key_Complete Yes Read_Remote_Supported_Features_Complete Yes Read_Remote_Version_Information_Complete Yes QoS_Setup_Complete Yes Command_Complete Yes Command_Status Yes Hardware_Error Yes Flush_Occurred Yes Role_Change Yes Number_Of_Completed_Packets Yes Mode_Change Yes Return_Link_Keys Yes PIN_Code_Request Yes Link_Key_Request Yes Link_Key_Notification Yes Loopback_Command Yes Data_Buffer_Overflow No (a)

Max_Slots_Change Yes Read_Clock_Offset_Complete Yes Connection_Packet_Type_Changed Yes QoS_Violation No Page_Scan_Mode_Change No (b) Page_Scan_Repetition_Mode_Change Yes

Table Appendix B.2: HCI Events

Notes: (a) Significance and expected recovery procedure is ill defined. (b) Optional paging schemes not supported.

Known Issues


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

Appendix C Known Issues This section lists currently known issues for the HCIStack1.1v17.3.4 firmware.

The “Severity” column gives a subjective assessment [Low, Medium, High] of how severely each issue may affect the firmware’s usefulness in real applications.

ID Severity Description

B.103 Low

A minor problem has been observed when failing to create a connection with another manufacturer’s baseband. This results in the CSR device taking an excessive time to signal the failure to its host. The problem is provoked by a particular sequence between a CSR device and its host:

The host receives an HCI Link_Key_Request event. The host replies with an HCI Link_Key_Request_Reply command. The host receives an HCI PIN_Code_Request event. The host fails to reply with the expected PIN_Code_Request_Reply, e.g.,

because the user hasn’t supplied a PIN code. The LM runs a 30s timer for the first transaction (Link_Key_Request and Link_Key_Request_Reply), so that it can destroy the connection cleanly if the host doesn’t provide the link key. The LM should also run a timer for the second transaction (PIN_Code_Request and PIN_Code_Request_Reply), but this is absent. The request for the PIN code was provoked by the other manufacturer’s peer BT device sending an LMP_in_rand message. The peer runs a timer to ensure it obtains the expected response, an LMP_accepted message, in an acceptable time. If the peer device is from one particular (non-CSR) manufacturer it appears that when this timer fires it doesn’t send the expected LMP_detach message. The CSR device consequently remains in an idle state until the link’s supervision timer fires, which is signalled to its host, approximately 80 seconds after the PIN_Code_Request. If the CSR device used a timer for the second HCI transaction it would be able to signal the link’s loss more quickly.

B.104 H16.169 High

If a system routes HCI SCO channels over USB, there is a high probability that if two SCO channels are opened, and then one of them is closed, then the firmware will crash. This problem has not been seen if only one SCO channel is routed over USB. There is a related, but technically independent, problem. If a USB SCO link is closed, and then a new USB SCO link is opened, it is possible for the second link’s from-air audio to be badly distorted. The audio distortion problem occurs only where both SCO links use 16-bit samples. The distortion occurs where the host does not collect all of the bytes from the last HCI SCO packet of the first SCO link. The second SCO link reuses the first link’s endpoint, and the link’s data incorrectly starts with the first link’s few uncollected bytes. This can be an odd number of bytes, misaligning all subsequent 16-bit samples by one byte. The same audio distortion misalignment can result from a race hazard within the chip, even if the host takes all of the link’s trailing bytes when closing the SCO link. In practice, the race hazard is the primary cause of this problem arising. The distortion issue is similar to issue H13.154, but that issue concerned from-host SCO USB traffic. (HCI builds’ release notes have never claimed support for SCO over USB, mainly because of the lack of suitable test equipment, so it is arguable whether this issue should be categorised as being of “high” importance.)

Known Issues


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

ID Severity Description (continued)

B.110 H16.170 H17.127 H18.46

High

Switching the chip into and out of USB suspend mode can stall the flow of to-host messages. This issue only affects the chip when it is used as a self-powered USB device. The host first puts the chip into suspend mode. Next, the chip produces a message to send to the host, so it uses the Remote Wakeup mechanism to request the host to restore the USB interface to its normal operating mode. However, when the host polls the chip for to-host traffic, it is repeatedly told that no message is available. If the chip queues a second message to send to the host in this state, the blockage is removed, and normal behaviour is restored. This issue has not been reported on Windows, despite extensive testing. The problem has been seen only during prototype development on another operating system.

B-245 Medium

When the code base was ported to BlueCore2-Flash (see H17.47), some improvements were made to the radio’s behaviour in Bluetooth Test Mode. A mistake was made in these improvements: when the firmware is looping back a data stream in Bluetooth Test Mode, it can fail to receive alternate single slot packets. A Bluetooth tester (e.g., R&S CMU200 or Anritsu) normally reports this as 50% packet loss rate. The problem has also manifested itself as a reported failure to respond to LMP power control messages. The problem does not affect normal Bluetooth operation. The issue has not prevented CSR obtaining Bluetooth qualification.

B-254 Low

Issue H16.176 describes support added to overcome an interoperation issue between the current (March 2003) Microsoft XP Bluetooth stack and certain mobile phones. The added support works well for many systems, but it has exposed a new interoperation problem, notably with the Ericsson T68i mobile phone. To combat this particular problem, a minor improvement has been made to the firmware’s HCI code: the firmware responds immediately to an HCI Read_Clock_Offset command on a slave. The interoperation problem arises shortly after a remote device (e.g., a T68i phone) has connected itself as master to a (CSR) device, layered underneath the Microsoft XP BT stack. The Microsoft stack can send an HCI Authentication_Requested command, followed immediately by an HCI Read_Clock_Offset command. The Authentication_Requested command will normally provoke an HCI Link_Key_Request “event”, but the host is not allowed to respond to this “event” because at that moment the Num_HCI_Command_Packets (NHCP) value is zero. This deadlock lasts for 30 seconds, when the LM times out its link key request, and consequently the original authentication request fails. (During the deadlock, the baseband is waiting for HCI Link_Key_Request_Reply and the host is waiting for NHCP to become non-zero.)

B-315 Low A VM application is able to play an audio tone (typically into headset). If the tone’s duration exceeds 8 seconds, the tone lasts until the firmware is rebooted.

B-423 Low The description of PSKEY_PCM_FORMAT notes that if the PS Key is set to 0xffff then the PCM data format is taken from the HCI Write_Voice_Setting command. This functionality is broken: when the PS Key is set to 0xffff, the data is garbled.

B-639 Medium

Firmware build HCIStack1.1v17.3.4 introduced the Bypass_UART BCCMD command, described in H16.66. The command’s implementation is broken. A workaround is to set PSKEY_USB_SUSPEND_PIO_MASK to zero, and then to perform a warm reboot, after which the Bypass_UART command works.

B-708 Low

The radiotest (BIST) command TxStart, described in [BCCMDRADIOTEST], starts operation it emits a momentary spurious outputs at an offset of 1MHz from the main transmitted signal. The spurious emissions occur while the chip’s synthesiser is recalibrated. The spurious emissions may occur regularly (typically every second). The TxStart command is normally used only during development, when the misbehaviour is of no consequence.

Known Issues


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote


B-760 Low PSKEY_TX_USE_DYNAMIC_OFFSET is not used in HCIStack1.1v17.3.4; the PS Key’s description incorrectly suggests the control is still available.

B-761 Low

PSKEY_RX_HIGHSIDE is not used in HCIStack1.1v17.3.4; the PS Key’s description incorrectly suggests the control is still available. In HCIStack1.1v17.3.4, the choice of high or low side receive mixing is made for each hop channel during firmware initialisation.

B-762 High

The PCM interface can be configured to act as a PCM slave, i.e., external hardware provides the interface’s PCM_CLK signal. A problem has been found with this support: if a SCO channel is routed over the PCM port before external hardware provides the interface clock then no data flows. (The problem doesn’t occur if a few clock cycles are provided before opening a SCO connection.) Early analysis suggests that if the SCO channel is closed and then a second SCO channel is created then it will operate correctly.

B-842 High Extra testing, just before approving the build for release, suggests that using PIO[10] only works intermittently when the host transport is USB. See B-486.

H12.93 Low

When two devices use remote loopback mode the flow of ACL link data (local host → local BT → remote BT → local BT → local host) can deadlock. The blockage occurs because the two BT devices assert flow control to each other and fail to deassert it. This has never been seen when using a fast host connection (USB), but readily occurs with a slow host connection (BCSP at 115k2). Workaround: run loopback tests with a fast host connection.

H15.254 H16.123 Low

If the device is in local loopback mode, then an HCI Reset command puts the firmware into an unworkable state. The Reset command apparently succeeds, but it provokes an HCI Hardware_Error event with Hardware_Code FAULT_LC_RESET_FAIL and the device is left in local loopback mode. A subsequent attempt to exit local loopback mode apparently succeeds, but the device remains in local loopback mode. This fault is not critical to normal Bluetooth operation, so it is classed as being of low importance.

H17.51 Low

If a link’s supervision timer is reduced below 150ms, the link can be terminated instantly from a supervision timeout. The probability of this problem occurring decreases as the supervision time increases; 500ms appears to be a safe minimum value to avoid this issue. Most systems leave the timeout at its default of 20s. A set of optimisations was made to the LC’s scheduler to allow addition of IEEE 802.11b co-existence support. One of these changes can provoke this ill effect when using very short link supervision timers. The problem arises from the LC scheduler changes, not from actually using the co-existence support. Using a small supervision timeout value intrinsically makes the link more susceptible to failure, particularly where the period approaches to the connection’s Tpoll value, so this problem only slightly expands the range of unreasonable timeout values. (Setting a small period with the HCI Write_Link_Supervision_Timeout command does not force down the link’s Tpoll value.)

Known Issues


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote


T.591 Low

The firmware should not complain about receiving HCI ACL packets on HCI handles that have recently been destroyed. When the firmware destroys an ACL connection it sends an HCI Disconnection_Complete event to the host. It takes time for the event to reach the host, during which time the host may send ACL packets on that handle. This race hazard is implicit in the design of HCI. The firmware protects itself by placing recently disconnected handles into a “frozen” state, as described in [BCHCI]. If the firmware receives (any) ACL data on an inactive handle, it emits an HCI Hardware_Error event with code 0x23 (FAULT_H4_RX_BAD_PDU). The packet is discarded, though the corresponding Number_Of_Completed_Packets flow control token is returned to the host. As a convenience for the host, it would be better if these error events were not returned for HCI handles when in the frozen state. This is not really a bug; the required behaviour is not defined by [BT].

Table Appendix C.1: Known Issues for HCIStack1.1v17.3.4 Firmware

Issues Addressed Relative to HCIStack1.1v16.4


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

Appendix D Issues Addressed Relative to HCIStack1.1v16.4 This section lists issues that have been addressed relative to build HCIStack1.1v16.4.

The “Severity” column gives a subjective assessment [Low, Medium, High] of how severely each issue may have affected the firmware’s usefulness in real applications. The “Severity” code “N” indicates “not a bug”.

ID Severity Description

B.107 H16.163 H13.215

Low

The BlueCore firmware has an algorithm for limiting the maximum transmit power. This is used to compensate for the fact that at high temperature, the output power for a given amplifier setting may be higher than the nominal value, and hence may be outside the range allowed by the Bluetooth specification. This feature is enabled by setting PSKEY_ENABLE_MAX_TXLVL, and is most often used on Class 2 modules based on BlueCore01b to limit the maximum transmit power to 4dBm. The algorithm has a flaw: it is not being applied immediately upon chip initialisation or reset, and hence it is possible for the initial transmissions to be at an output power greater than 4dBm. With a typical configuration, this is only seen if the chip is powered on or reset at temperatures significantly above room temperature and additionally the radio is used within the next ten seconds. As far as is known, this mechanism is used or useful only on BlueCore01b, although the support remains in place for BlueCore2 chips. Remedy: The algorithm is used from the start of radio operations.

B.108 H16.164 Low

As part of the reworking of the LC scheduler to support limited scatternet operation in HCIStack1.1v16.4 the LC’s watchdog is kicked every 50ms while the radio is generally active. This causes no problem with the firmware’s functional operation, but it marginally increases RF interference, and this has caused problems for one module manufacturer when running in Bluetooth Test Mode. Remedy: Kicking of the LC’s watchdog has been synchronised with other LC radio activity.

B.111 H15.267 K15.65

H16.178 H17.117 H18.19

Low

When the firmware is in Bluetooth Test Mode, as defined by section I:1 of [BT], a CSR LC slave attempts to send each LMP message only once. If the message is not successfully transferred on the first attempt, the link will typically fail after 30 seconds, the master reporting an LMP transaction timeout. The lost message will normally be LMP_accepted, acknowledging receipt of a test command from the host. In practice, this issue is very difficult to reproduce; it normally depends on there being severe radio interference at the instant the LMP message is sent. Remedy: The LC retransmits the LMP message until it is acknowledged.

B-523 N

A firmware build running from ROM has been observed to take roughly 17 milliseconds longer to boot than when running on BlueCore2-Flash. The anomaly arises because when running from ROM, the firmware attempts to identify the flash type, fails, and yet performs a default initialisation of the unknown flash. This harmlessly wastes a little time. The behaviour is unexpected, but this is not a bug.



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote


H13.167 H17.28 Low

The firmware can panic if a peer suddenly sends a large block of LMP messages to the local device. If the local device’s LM cannot deal with the messages fast enough the message queue grows, eventually taking all of the system’s memory and provokes a call to panic(). This will normally reboot the device. This has only been seen where peer devices disobey [BT]. Here is an example: A CSR device sends an LMP_in_rand message to a peer, but the peer has become unresponsive. The CSR device repeatedly sends the same baseband message, hoping the peer will ACK the message. Many tens of milliseconds later the peer unfreezes and sees it has received a block of messages from the CSR device. The peer device fails to detect that these are all the same message, and so treats each separately. The peer responds to each of the “separate” messages, incorrectly giving each a distinct baseband sequence number. The CSR device suddenly receives a block of LMP messages, runs out of memory and panic()s. This problem has never been seen where the peer device obeys [BT], and so it is classed as being of low importance. Remedy: Flood defences (asserting flow control when needed) have been added to prevent being overrun by received LMP traffic on HCIStack1.1v17.x.

H16.171 H17.109 Low

An HCI Reset command very occasionally provokes an HCI Hardware_Error event with code 0x2b (FAULT_LC_RESET_FAILED – “An attempt to reset the Link Controller has failed. The LC reset supports the HCI Reset command.”) The issue has been reproduced at CSR. A complex sequence of operations, including HCI Reset, was run on an automated test system 3000 times. The problem occurred once, and its state was captured. The problem has been analysed and is considered benign. At the end of the code behind the HCI Reset command, a check is made that all connections’ state has been removed. Under rare circumstances, it is possible for a race hazard to delay destruction of part of the LC’s connection state, so the check raises the error report. Assuming the error has been identified correctly, this should have no impact on normal system performance, so the Hardware_Error event can be ignored. Remedy: A potential race hazard has been found by code inspection and fixed. Testing before the fix at CSR showed one occurrence in 3000 operations. Testing after the fix showed no occurrences.



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote


H16.176 H16.185 H17.135

Low

If a CSR slave requires a role switch during connection creation, but this is refused by the master, then the slave drops the link. This is the correct behaviour, but it has caused some interoperation problems, notably with devices attempting to connect to Microsoft’s current XP Bluetooth stack. There are two situations of interest:

(1) A device is paged, causing an HCI Connection_Request event to be sent to the host, to which the host normally responds with an HCI Accept_Connection_Request command. (2) A device is initially configured with the HCI Set_Event_Filter command, allowing the device to complete connections autonomously.

Examining these two cases in more detail: (1) Here is the normal sequence where the decision to accept a connection request is made by the local host. Because the local device insists on being master and the remote device refuses to perform a role switch, the only reasonable behaviour is to drop the link.

1. Local device enters page-scan.

2. Remote device pages the local device and creates a baseband link.

3. Local device sends an HCI Connection_Request event to its host.

4. Host responds with an HCI Accept_Connection_Request command, but with the Role parameter set to require the local device to be the connection’s master, i.e., to require a role switch.

5. The local device requests the peer to perform a role switch.

6. The remote device refuses the role switch.

7. The local device tears down the baseband link and sends an HCI Connection_Complete(failed) event to its host.

The firmware currently implements this behaviour, as required by [BT]. (2) A device can be configured to accept connections automatically with the Set_Event_Filter command. If the command’s Auto_Accept_Flag is set to 0x03, then the firmware is required to perform a role switch on fresh connections. This is discussed in some detail in the description of issue B.76. The sequence is:

1. Local device enters page-scan.

2. Remote device pages the local device and creates a baseband link.

3. During the subsequent LMP chatter, the local device requests a role switch.

4. The remote device refuses the role switch.

5. The local device tears down the baseband link and sends an HCI Connection_Complete(failed) event to its host.

Further to the discussion in B.76, the description of the Role_Change_Not_Allowed error code, section H:1, 6.26 of [BT], removes the ambiguity – the link must be dropped. Thus, the firmware’s current behaviour, dropping the link if the paging device refuses to perform a role switch, is required by [BT]. Investigation of the current Microsoft XP stack indicates that it uses mechanism (1), and that it insists on being master of new links. If a paging device insists on remaining master when it pages the (CSR device in page-scan that underlies the) Microsoft XP stack, the link is dropped because both devices are demanding to be the link’s master. The paging device may refuse the role switch because it doesn’t support it, or because its host requires to be master (typically because its host issues an HCI Create_Connection command with the its Allow_Role_Switch parameter set to 0x00).



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote


H16.176 H16.185 H17.135

continued

(This issue only concerns attempting to perform a role switch during connection creation. After connection creation, if an HCI Switch_Role command is rejected by thepeer, the link remains connected.) Remedy: As a convenience for several distressed users, the firmware can now be configured not to drop the link when the paging device refuses a role switch. This reverses the change made under issue id B.76 for build HCIStack1.1v14.6. If the new PS Key PSKEY_NO_DROP_ON_ACR_MS_FAIL is TRUE, then the link is not dropped. This applies to sequences (1) and (2), above. This change only applies to a role switch refused before the connection’s LMP_setup_complete exchange. A host can tell that the role switch has not occurred because no HCI Role_Change event will be emitted for the nascent connection. Setting this PS Key to TRUE causes the firmware to violate [BT], but it does not currently prevent obtaining Bluetooth qualification. The new PS Key’s default value is FALSE.

H17.17 H16.145 K15.52

Low

An invalid LMP message from a slave can lock up a state machine in the master’s LM, deadlocking the connection. If a CSR master sends an LMP_unpark_PMADDR_req to a slave, then the slave replies with an LMP_accepted, but the slave’s message carries the wrong transaction id (the slave’s, rather than the master’s), then the master’s state machine for the connection locks up. The deadlocked state can only be cleared by an HCI Reset command or by rebooting the firmware. This misbehaviour was seen during testing at UnplugFest 9; it has not been reported by any of CSR’s customers. Remedy: Defensive code has been added to the LM in HCIStack1.1v17.x: the master knows it is expecting the LMP_accepted, so it treats the malformed slave message as the response to its transaction.

H17.18 H16.146 K15.53

Low

If a CSR device makes a baseband connection (to a non-CSR device), then the second device initiates a role switch that subsequently fails, it is possible that the master will block the connection for 30s. After 30s the connection is lost. The problem occurs because the master’s LM state machine makes a presumption about the order in which it will receive the LMP_accepted for the original LMP_host_connection_req and notification of the switch failure. The presumption is valid for CSR peers and for most other known basebands, but it was seen to cause a problem during interop testing at UnplugFest 9. Remedy: The presumption of message order has been removed.

H17.20 H16.148 K15.54

Low

If a slave misbehaves during slave initiated unpark, it is possible for the master to lose control of the connection. If a slave initiates an unpark operation by signalling in a beacon access window, then the master unparks the device in a broadcast message, then the slave’s LMP acknowledgement of the unpark message is somehow lost, the master’s LM state machine for the connection can deadlock. The only way to recover is for the slave to detach the link or for the master’s host to send an HCI Reset. This was seen at Unplugfest 9, where a misbehaving slave sent an L2CAP continuation message with the same baseband sequence number as the LMP acknowledgement of the unpark message. The CSR master correctly discarded the LMP acknowledgement. Remedy: LMP transactions normally use a 30s timeout to detect when the peer fails to respond, but this is not normally used with LMP messages transmitted via broadcast, as broadcast is intrinsically unreliable. For this case a 30s timeout has been added from HCIStack1.1v17.x, so the missing acknowledgement is detected and control of the link is recovered.



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote


H17.31 Low

If the standard C library encounters an arithmetic overflow, e.g., dividing by zero in __div(), then it calls __ovfl(). This blocks in a loop, eventually provoking a watchdog reset. This weakness allows a VM application to reboot the chip. Remedy: The __ovfl() function has been replaced in HCIStack1.1v17.x: it now calls fault() to emit new code FAULT_MATHS_ERROR (0x32), then it returns.

H17.32 H15.262 H16.149 K15.56

Medium

A bug in the psram code in HCIStack1.1v16.4 can cause a failure to write to psram, and possibly can corrupt existing psram values. In practice, this problem can only take effect when a value is written to psram after the radio starts operation. Because psram is mainly used during system initialisation, e.g. to set the device’s Bluetooth address, this problem doesn’t normally affect operation. psram is normally only used with ROM parts. Remedy: The bug has been fixed in HCIStack1.1v17.x (dereferencing of a NULL pointer), giving correct psram operation.

H17.34 H17.100 Low

If the baseband is performing page-scan, and then the host changes its page-scan parameters, then the baseband may delay for up to the original Page_Scan_Interval before switching to the new timing. For example, if the baseband is performing page-scan in R1 mode with typical parameters, {0x800, 0x12}, and then the host uses the HCI Write_Page_Scan_Activity command to change it to R0 mode with parameters {0x400, 0x400}, then it can take up to 0x800 slots (1.28 seconds) before the baseband enters continuous page-scan mode. Remedy: The timing change now takes effect immediately.

H17.36 H16.150 H15.263 K15.60

Low

If the radio receives a broadcast packet which is discarded because it is found to contain too many errors then the LC incorrectly sets the ARQN of the next packet sent to the broadcaster (master) to zero (NAK). Consequently, the master may have to resend the packet that was incorrectly NAK’d. This problem is trivial, and invisible to the end user. Remedy: The ARQN value is not set to zero from HCIStack1.1v17.x.

H17.38 H16.152 K15.62

Low

If a connection is created for which authentication and encryption are required, and the CSR master initiates authentication at the same time as the non-CSR slave initiates encryption, then both transactions can deadlock. This was seen during interop testing at UnplugFest 9; it has not been reported by any of CSR’s customers. All known basebands in commercial products complete authentication before enabling encryption. Remedy: A short timeout has been added from HCIStack1.1v17.x on the master’s transaction; if the slave doesn’t respond in time, the master sends LMP_not_accepted(unspecified error), to tear down the slave’s encryption request.



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote


H17.39 K15.61 N

While a device is parked, no point-to-point ACL data can flow. There is a race hazard, intrinsic in the [BT] specification, which implies that such data can flow to a host just as the device is being parked. In all builds since HCIStack1.1v12.1, the firmware attempts to prevent such data flowing to the host, as it was reported to confuse some host stacks. This means that point-to-point ACL data received from a peer can remain in the baseband while the link is parked, and this passes to the host when the link is unparked. This blockage affects only point-to-point ACL data; broadcast traffic is unaffected. Special pleading has caused CSR to reconsider this design decision; apparently the blocking and implicit delaying of point-to-point ACL traffic can break some implementations of L2CAP. This is marked as “Not a fault” because [BT] gives no direction on the topic. Remedy: From build HCIStack1.1v17.3.4, no attempt is made to prevent point-to-point ACL traffic from flowing to the host.

H17.56 Medium

If a link is put into sniff mode and then a SCO link is added, and if the SCO and sniff parameters exactly overlap, then all ACL and LMP traffic from the master to the slave can be blocked. Control of the link is consequently lost. For example, if the sniff mode is using a Tsniff that is a multiple of 6 slots and an Nsniff_attempts of 1 then the corresponding sniff windows can be exactly overlaid by an HV3 SCO link. A comparable superposition can occur with a Tsniff that is a multiple of 4 slots and an HV2 SCO link. The code that advises on suitable (Dsco) placement of a SCO link relative to the link’s current sniff parameters is broken, consequently the LM’s negotiation can result in an unfortunate Dsco. In all HCIStack1.1v15.x and HCIStack1.1v16.x builds, this can block ACL and LMP traffic flowing from master to slave. (Traffic flowing in the reverse direction can still flow, but LMP transactions need bidirectional communication.) The obvious workaround is to put the link into sniff mode before adding a SCO link. This is the normal way of using SCO with sniff, which is probably why this issue hasn’t been reported to CSR, but was found by CSR’s internal testing. This is not an issue for HV1 links, as these usually use DV packets for LMP and ACL traffic. Remedy: The code which advises on a suitable Dsco for a new SCO link now uses the link’s existing sniff parameters.

H17.58 H16.157 Low

Two minor power consumption inefficiencies were introduced when the LC scheduler was reworked to provide limited scatternet support:

If the radio is used, then the system enters deep sleep, 50ms later the chip wakes up, then falls asleep again.

Under limited circumstances, the first effect can cause the firmware to wake up briefly from deep sleep every 500ms.

These changes have no significant effect on the firmware’s functionality, but they marginally increase average power consumption Remedy: The first issue was traced to improper management of the LC’s watchdog logic; the problem has been corrected. The second problem doesn’t occur, now that the first issue has been addressed.



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote


H17.59 Low

In all builds up to HCIStack1.1v16.x, the system’s clock is slowed from 16MHz to 4MHz when calibrating the slow clock prior to entering deep sleep for the first time. This was necessary on BlueCore01b, but improvements in the hardware design mean that it is not necessary on BlueCore2-Flash, and probably not on BlueCore2-External. The UART uses 8x oversampling for received characters, so if it is set to a baud rate of 500kbps or higher, it stops receiving characters when the system clock drops to 4MHz. This is a minor inconvenience when using BCSP; if the host sends a message during the clock’s calibration, the message is lost, but it is received correctly when the host transmits it again. This is of no consequence for H4, as this is not supported with deep sleep. Remedy: From HCIStack1.1v17.3.4, the internal system clock is no longer slowed to 4MHz when calibrating the chip’s slow clock if the baud rate is 500kbps or higher. (The clock is still slowed for lower baud rates to minimise power consumption.)

H17.63 Low

Bulk data is transferred through BlueCore via MMU buffers. These allocate memory pages on demand, and allow efficient sharing of the available RAM amongst multiple connections. When the supply of MMU pages becomes low, the LC asserts flow control to peer Bluetooth devices. The trip points for asserting the various flow control mechanisms are set in PSKEY_LC_FC_BUFFER_LOW_WATER_MARK. Under extreme loading, during soak testing at CSR, the firmware has been observed to run out of MMU pages before flow control can be asserted. This crashes the firmware. The failure has only been seen where the maximum size of ACL packets transferred to the host has been configured to be abnormally low (configured using PSKEY_HOSTIO_PROTOCOL_INFO_6) and the ACL values returned by the HCI Read_Buffer_Size command have been changed from their normal {8 x 192} bytes to {4 x 384} bytes (adjusted by changing PS Keys, as described in [BCHCI]). The problem has not been seen where the PS Keys have their default values. Remedy: The PS Key’s default values have been adjusted to make the firmware’s flood defences rather more conservative from HCIStack1.1v17.3.4. Associated with this, the algorithm that determines the available resource levels has been improved.

H17.66 H16.158 Medium

A BlueCore2-External slave with firmware HCIStack1.1v16.4 running an HV3 SCO link and (common) ACL sniff parameters {0x800, 8, 4} consumes roughly 20% more power than when using firmware HCIStack1.1v15.3. The extra current consumption comes from LC scheduler changes to handle scatternet operation; the slave wakes up earlier than needed to service the SCO link. Remedy: The scatternet scheduling code has been reworked; the current consumption is now comparable to that on HCIStack1.1v15.x.

H17.76 Low

When passing a CVSD coded SCO channel through the PCM port, very early versions of the BlueCore2-External chip tended to give undue emphasis to low audio frequencies. To counteract this, a software filter was added in build HCIStack1.1v14.3 to boost treble frequencies, controlled by PSKEY_PCM_CVSD_RX_HI_FREQ_BOOST and PSKEY_PCM_CVSD_TX_HI_FREQ_BOOST. Static code analysis with “lint” has found a fault in the filter algorithm: it did not boost the treble as required. Remedy: The algorithm fault has been remedied, although the functionality is useless on BlueCore2-Flash.



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote


H17.80 Low

A SCO connection is clocked at a nominal rate of 8k samples/second. As described in [BCHCI], the firmware sometimes needs to add or discard SCO samples to compensate for any mismatch between the piconet’s and the host transport’s concepts of 8k samples/second. There is a flaw in this code: if the firmware blocks interrupts for an extended period (typically more than one second) then it is possible incorrectly to write zeroes into a small amount of RAM and control registers. This normally crashes the firmware. The problem has occurred only very rarely – it has been seen only a handful of times during extensive soak testing. Remedy: From HCIStack1.1v17.3.4, the data rate compensation firmware only writes zeroes into SCO buffers.

H17.89 Low

The value of PSKEY_PIO_PROTECT_MASK defines a set of PIO port bits that cannot be altered via BCCMD commands. In previous builds, this PS Key’s default value, 0x03, prevented access to PIO[0] and PIO[1], normally used to control an external PA and LNA. The default value is inappropriate for Class 2 and 3 Bluetooth designs, as these normally have no external PA or LNA. A simple workaround to allow access to these two pins is to write zero to the PS Key. See B-472. Remedy: The PS Key’s default value has been changed to zero.

H17.103 H16.167 Low

The [BT] specification strongly suggests that if an active broadcast message is being (repeatedly) transmitted when a beacon starts, then transmission of that message is aborted, i.e., it may be transmitted fewer than NBC times. The firmware contains a bug: if a beacon occurs before an active broadcast message has been sent NBC times the same message is restarted after the beacon. If NBC is large and/or the interval between beacons is small this can cause a single active broadcast message to be sent indefinitely. However, in practice this doesn’t affect systems using typical timings (NBC around 5 and usually around 1 second between beacons). Remedy: The scheduling of active broadcast message has been corrected.

H17.129 H18.51 Low

When the firmware detects an irrecoverable problem it calls panic(). This reboots the chip If the chip’s watchdog is enabled. The reboot is effected by holding on to the processor’s program counter until the watchdog fires. The watchdog is normally set to 3 seconds, so the chip can wait for this long before it reboots. Although this is not a fault, it is unnecessary and sometimes inconvenient. In particular, it causes inconsistency in the time to reboot provoked by restarting a host’s BCSP driver; this causes the BCSP Link Establishment code on the chip to detect the host’s restart, and it reboots the chip by calling panic(). Remedy: A panic() no longer waits for the watchdog to time out.



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote


H18.21 H16.179 Low

A master that misbehaves during authentication can cause the CSR slave to drop the link. This problem has been seen only with one particular (non-CSR) manufacturer’s baseband. As a prelude, the non-CSR baseband is first paired with a CSR device, and then the non-CSR device loses its link key. When the two devices are subsequently connected, with the CSR device acting as slave, the non-CSR device can start to pair at the same time as the CSR device is starting to authenticate. The master should reject the CSR slave’s attempt to authenticate with a “Key Missing” reason code, but it actually uses “LMP Error Transaction Collision”. This violates [BT]. The CSR device does not respond well to the non-CSR device’s misbehaviour – it can drop the link. Remedy: The CSR device backs out of its attempt to authenticate, and re-pairs with the master.

H18.37 H15.268 H16.181 H17.123

Medium

Support for the HCI Set_Event_Mask Command is broken: it is always rejected with Status code 0x12 (“Invalid HCI Command Parameters”). Remedy: The HCI command parser has been repaired.

H18.45 H16.182 H17.126 H15.270

Low

A CSR slave in park mode can crash if it receives a multi-slot packet. This is a serious error, but circumstances conspire to mean it is unlikely to cause a problem for real systems:

A parked slave only listens to its master during a beacon. This allows the slave to resynchronise itself to the master’s clock, receive a (single slot) LMP unpark message or receive a broadcast ACL message.

CSR masters always broadcast using single slot packets. Very few designs use park mode; it is far more common to use sniff mode, as

it achieves much the same functionality, but is simpler to understand, control and implement. The only application that commonly uses park mode is a headset.

In builds before HCIStack1.1v15.3, CSR masters transmit NULL packets during a beacon if they have no LMP or ACL traffic to send.

Thus, this is only likely to be a problem for a parked CSR slave connected to a non-CSR master which is sending bulk (multi-slot) data to a second slave. This is a very uncommon arrangement, which probably explains why this two-year old bug has not been reported by any of CSR’s customers. From HCIStack1.1v15.3, CSR masters can transmit point-to-point multi-slot packets during park beacons. Remedy: The problem was that the interrupt routine used to handle multi-slot packets was turned off in park mode, resulting in random behaviour when a parked slave received such a packet. The problem has been fixed.



_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote


H18.64 H16.187 H17.137

Low

If a device receives an LMP_detach message shortly before receiving an LMP_sniff_req message there is a small chance that the firmware can crash. Receiving these two LMP messages in rapid succession can cause the firmware to dereference a NULL pointer, with indeterminate results. Typically, the firmware crashes. The problem has been seen only during development of a “HID” (mouse) firmware build at CSR; it has not been reported by any customer. HID builds are peculiar in that they use sniff with very tight timings and they frequently drop and recreate connections – both mechanisms are used to minimise power consumption. It is highly unusual for a device to break a link (with LMP_detach), and then for the same device to ask to change the link’s settings (LMP_sniff_req). Remedy: The race hazard has been removed.

H18.65 H17.136 H16.186 K15.69

Low

Slaves do not take account of the master’s Bluetooth clock jitter in Bluetooth test mode. A slave is required to take account of timing jitter in the master’s Bluetooth clock. The slave can either assume the master’s jitter to be 10µs (the worst case), or it can learn it from LMP interaction. A slave uses this knowledge to decide when to search (early) for its master’s transmissions. The firmware does not take account of the master’s jitter in Bluetooth Test Mode. (The clock jitter is correctly handled in normal Bluetooth operation.) This tends to show up as a large packet error rate in Bluetooth Test Mode, despite a very low bit error rate and apparently good radio conditions. Masters with low jitter (obviously) tend to be less susceptible to the problem. Failure to track the master’s clock causes the slave to transmit back to the master at the wrong time, and so the master fails to pick up the slave’s transmission. Remedy: A slave now correctly handles the master’s jitter value in Bluetooth Test Mode.

T.588 H16.168 H17.104

Low

The HCI Get_Link_Quality command reports a measure derived from the (correctable) bit error rate in received packets, as described in [BCHCI]. The code that calculates the error rate has a minor flaw: it gives errors observed in DV and DM packets disproportionate weight. Remedy: The error rate calculation has been corrected.

Table Appendix D.1: Issues Addressed Relative to HCIStack1.1v16.4

Default PIO Allocation


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

Appendix E Default PIO Allocation This appendix lists the PIO pins’ default functions for the build, resulting from PS Keys’ default values.

PIO Pin Default Function

PIO[0] High at boot forces use of H4. See note for PIO[9]. Change reference H17.132 describes default value for PSKEY_HOST_INTERFACE_PIO_H4.

PIO[1] High at boot tell firmware that system clock is 13MHz. See note for PIO[10]. Change reference H17.133 describes default value for PSKEY_FORCE_13MHZ_REF_PIO.

PIO[2] Output to request supply of chip clock. See note for PIO[3]. Change reference B-522 describes the default value of PSKEY_CLOCK_REQUEST_ENABLE.

PIO[3] Input high forces PIO[2] output to be high. Change reference B-522.

PIO[9] High at boot forces use of USB. Change reference H17.95 describes default value for PSKEY_HOST_INTERFACE_PIO_USB. If PIO[9] is high at boot, the value of PIO[0] at boot is ignored.

PIO[10]

High at boot tell firmware that system clock is 16MHz. Change reference B-486 describes default value for PSKEY_FORCE_16MHZ_REF_PIO. If PIO[10] is high at boot, the value of PIO[1] at boot is ignored. See B-842.

Table Appendix E.1: PIO Pins’ Default Functions

Note: By default, AIO[2] is connected to the chip’s internal reference voltage and the pin must be decoupled.

Document References


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

Document References Document ID Document Title, Reference

[BC02KFDB] BlueCore2-Flash Production Information Data Book; CSR document BC215159A-LF-001P

[BCCMDPS] BCCMD Persistent Store Commands; CSR document bcore-sp-004P [BCCMDS] BCCMD Basic Commands; CSR document bcore-sp-005P [BCCMDTEST] Basic BCCMD Test Command Set; CSR document bcore-sp-001P [BCCMDRADIOTEST] BCCMD Radio Test Command Set; CSR document bc01-sp-045P [BCHCI] HCI Implementation; CSR document bcore-me-007P [BT] Specification of the Bluetooth System, volume 1, Core, v1.1, 22 February 2001

[DOCLIST] BlueCore2-Flash HCIStack1.1v17.3.4 Document List; CSR document bcore-me-016P

[HCIEXTN] HCI Extensions; CSR document bcore-sp-009P [SCATTERNET] “2.5” Scatternet Support; CSR document bcore-me-003P

Acronyms and Definitions


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

Acronyms and Definitions ACK ACKnowledge ARQN Automatic Repeat reQuest Number ACL Asynchronous Connection-Less BCCMD BlueCore Command BCHS BlueCore Host Stack; CSR host Bluetooth source code BCSP BlueCore Serial Protocol; proprietary CSR UART protocol BlueCore01b CSR Bluetooth chip BlueCore2-External CSR Bluetooth chip BlueCore2-Flash CSR Bluetooth chip, flash-stacked device BlueCore2-ROM CSR Bluetooth chip BIST Built-in Self-Test (also referred to as radiotest) BlueCore™ Group term for CSR’s range of Bluetooth wireless technology chips BlueLab™ CSR’s software development kit for applications running in BlueCore’s VM

BlueSuite™ Suite of development tools that contains all of the BlueCore utilities. BlueSuite includes BlueChat2, BlueFlash, PSTools, BlueTest and BTCLI

Bluetooth® Set of technologies providing audio and data transfer over short-range radio connections BT Bluetooth CODEC COder DECoder CQDDR Channel Quality Driven Data Rate CSR Cambridge Silicon Radio CVSD Continuous Variable Slope Delta Modulation CTS Clear to Send DFU Device Firmware Upgrade EEPROM Electrically Erasable Programmable Read Only Memory H4 HCI UART Transport Layer (described in section H:4 of [BT]) HCI Host Controller Interface; interface between host and Bluetooth module IrDA Infra-red L2CAP Logical Link Control and Adaptation Protocol; element of Bluetooth LC Link Controller LM Link Manager LMP Link Manager Protocol LNA Low Noise Amplifier NAK Negative AcKnowledge NBC Number of BroadCasts PA Power Amplifier PCM Pulse Coded Modulation (digitised audio sample stream) PICS Protocol Implementation Confirmation Statement PIO Parallel Input/Output QoS Quality of Service ROM Read Only Memory RFCOMM Serial cable emulation protocol; element of Bluetooth RTS Request to Send SCO Synchronous Connection-Orientated SDP Service Discovery Protocol; element of Bluetooth SIG Special Interest Group; the Bluetooth SIG control the Bluetooth specifications UART Universal Asynchronous Receiver Transmitter USB Universal Serial Bus

VM Virtual Machine; environment in the BlueCore firmware for running application-specific code

Record of Changes


_äìÉ`çêÉ

cä~ëÜ H


are Release N

ote

Record of Changes Date: Revision Reason for Change:

12 AUG 03 a Original CSR internal document (CSR reference: bcore-srn-031Pa) 13 AUG 03 b Initial publication of this document (CSR reference: bcore-srn-031Pb)

_äìÉ`çêÉ»cä~ëÜ=

HCIStack1.1v17.3.4 Software Release Note

bcore-srn-031Pb

August 2003

Bluetooth® and the Bluetooth logos are trademarks owned by Bluetooth SIG, Inc. and licensed to CSR.

_äìÉ`çêÉ , BlueSuite™ and BlueLab™ are a trademark of CSR.

All other product, service and company names are trademarks, registered trademarks or service marks of their respective owners.

CSR’s products are not authorised for use in life-support or safety-critical applications.

Date post:	17-May-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

äìÉ`çêÉ cä~ëÜ HCIStack1.1v17.3.4 Software Release...

Documents