BC41B143A-DS-001PE Datasheet, PDF (43/102 Pages) List of Unclassifed Manufacturers – BlueCpre 4-ROM Single Chip Bluetooth v2.0 System with EDR

CSR Bluetooth Software Stacks
The firmware’s supported Bluetooth features are detailed in the standard Protocol Implementation Conformance
Statement (PICS) documents, available from http://www.csr.com
Note:
(1) _{Supports basic data rate up to 723.2kbps asymmetric, maximum allowed by Bluetooth v2.0 + EDR}
specification
(2) _{BlueCore4-Audio ROM supports all combinations of active ACL and SCO channels for both Master}
and Slave operation, as specified by the Bluetooth v2.0 + EDR specification
8.1.2 Key Features of the HCI Stack – Extra Functionality
The firmware extends the standard Bluetooth functionality with the following features:
! Supports BlueCore Serial Protocol (BCSP) – a proprietary, reliable alternative to the standard
Bluetooth UART Host Transport
! 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
! 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 minimise 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, USB and DFU constants, etc.
! A UART “break” condition can be used in three ways:
1. Presenting a UART break condition to the chip can force the chip to perform a hardware reboot
2. Presenting a break condition at boot time can hold the chip in a low power state, preventing
normal initialisation while the condition exists
3. 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 LED’s 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 via 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 remaining SCO
channels over HCI).
BC41B143A-ds-001Pe
This material is subject to CSR’s non-disclosure agreement
Production Information
© Cambridge Silicon Radio Limited 2005
Page 43 of 102