User's Manual
Table Of Contents
- 2035-UM1xx.book
- Table of Contents
- List of Figures
- List of Tables
- Section 1: Introduction
- Section 2: Hardware System Overview
- Section 3: BCM2035 Usage Models
- Section 4: Hardware Configuration
- Section 5: Software Configuration
- Introduction
- Hardware Power-Up Sequence
- Boot ROM Power-Up Sequence
- Firmware Power-Up Sequence
- BCM2035 Mini-Drivers
- Loading Mini-Drivers from USB
- Load Mini-Drivers From UART
- SCO Configuration
- Frequency Trimming
- UART Sleep Mode Operation
- Section 6: Configuration Data File System
- Section 7: Vendor-Specific HCI Command Reference
- Section 8: ASCII Hex File Download Protocol
- Section 9: ASCII HEX File Format
- Section 10: Configuration Data Download Protocol
- Section 11: Configuration Data Image Format
- Section 12: UART Start-up Sequence
- Section 13: USB Start-up Sequence
9/29/2004 OV4F2
C
O
N
F
I
D
E
N
T
I
A
L
F
O
R
W
I
S
T
R
O
N
C
O
R
P
O
R
A
T
I
O
N
BCM2035 User Manual
04/23/03
Broadcom Corporation
Page 44 Load Mini-Drivers From UART Document 2035-UM100-R
The baud rate for downloading the micro- or mini-driver is negotiated at boot-time or read from configuration
data. The default firmware baud rate is 115200bps. This setting is selected to ensure that
BCM2035 can
support all hosts that may or may not have higher baud rate capability. However, the baud rate for downloading
the subsequent mini-driver and/or firmware can be modified in both the micro- and/or mini-driver because each
application can customize the drivers to allow the fastest transfer rate available between the host and the host
controller.
Prior to booting the firmware, the HOST communicates its intent to download a mini-driver by asserting CTS.
The
BCM2035 will sense CTS assertion by the host and will acknowledge with the ASCII string 41 (0x34 &
0x31). Downloading a micro- or mini-driver before the host controller transmits the acknowledgment characters
will cause the boot code to flush the UART FIFOs and re-start.
When each record of the mini-driver is received and passes the checksum, the
BCM2035 returns 0x2E
(character '.' in ASCII) as an acknowledgement to the host. If a record does not pass the checksum, it returns
0x78 (character 'x' in ASCII) to the host and the boot ROM re-starts. If the host controller receives an ASCII
Intel hex record that is not supported, the boot ROM re-starts. The host has to issue an external reset or cycle
the power to start the power sequences again. These acknowledgements used for hand shaking between the
host and the
BCM2035 are fixed in the PROM.
A similar downloading protocol is used by the micro-/mini-drivers as well as when the firmware is downloaded,
using either the ASCII Intel hex or binary format. If the binary image format is used, the successful
acknowledgment can only be returned after the image is downloaded completely. The hand-shaking protocol
can be modified since it resides in the mini-driver.