Monday, January 14, 2013

BLUETOOTH HCI DEVICE Broadcom Bluejacking

HCI is the layer that handles the BT Controller configuration, remote connections and data transfers.The understanding of basic concepts involving the HCI layer will be assumed for the rest of this manual, please check the "Palowireless HCI tutorial" to get quickly introduced into the protocol.For the complete specification and all the details check the Bluetooth Core v2.0 Specification "Volume 2 Core System Package, Part E Host Controller Interface Functional Specification".Some previous definitions:Host: Both the USB Host and the BT Host (i.e. the PIC32 board).Device: Both the USB Device and the BT Controller (i.e. the USB Bluetooth Dongle).Remote Host: Another device (i.e. phone, PC...) that will establish connection with the Device being controller by the embedded Bluetooth stack we are developing.

Data formats and packet examples:

All the information regarding the data formats can be found in the "Volume 2 Core System Package, Part E Host Controller Interface Functional Specification, 5 HCI Data Formats" and it's very well worth reading (except the 5.4.3 HCI Synchronous Data Packets part).Command packet example:Write local name = 0x13 0x0C 0x0B 0x50 0x49 0x43 0x33 0x32 0x5F 0x42 0x54 0x76 0x31 0x00OpCode = 0x13 0x0C = OCF | (OGF << 10) = 0x13 | (0x03<<10)Parameter Total Length = 0x0B = 11Parameters:Local Name (NULL terminated string) = 0x50 0x49 0x43 0x33 0x32 0x5F 0x42 0x54 0x76 0x31 0x00 = "PIC32_BTv1\0"Notice: This command specification can be found in "Volume 2 Core System Package, Part E Host Controller Interface Functional Specification, 7.3.11 Write Local Name Command".Event packet example:Command complete = 0x0E 0x04 0x01 0x13 0x0C 0x00EvtCode = 0x0EParamaters:Number of HCI Command Packets = 0x01Command OpCode = 0x13 0x0C = Write Local Name CommandReturn = 0x00 = Success (Depends on the command)Notice: This event specification can be found in "Volume 2 Core System Package, Part E Host Controller Interface Functional Specification, 7.7.14 Command Complete Event".Data packet example:ACL Data = 0x00 0x20 0x0C 0x00 0x08 0x00 0x01 0x00 0x02 0x01 0x04 0x00 0x01 0x00 0x43 0x00Connection handle = 0x00 0x20Data length = 0x0C 0x00 = 12 (Remember that the data is in LittleEndian)Data = 0x08 0x00 0x01 0x00 0x02 0x01 0x04 0x00 0x01 0x00 0x43Notice: This is an L2CAP signaling frame. For now is out of scope.

Commands and events:

All the information regarding commands and events can be found in the "Volume 2 Core System Package, Part E Host Controller Interface Functional Specification, 7 HCI Commands and Events". I recommend to have the document at hand in order to follow the next example.

HCI layer implementation:

The complete HCI layer has a huge amount of commands and events to handle all the possible scenarios (low power operation, scatternets, piconets, multiple links, data encryption...) which can be overwhelming and completely out of scope. Fortunately enough the 90% of that complexity can be ignored and still get a decent Bluetooth HCI implementation for a limited device (such as our PIC32).The most important limitations will be:Slave operation only.Single connection oriented.No data encryption.Lack of support for low power operation.Regardless of the limitations listed above the HCI implementation provided with this manual can be scaled up to 100% of compliance without changing the design in any way.Instead of provide a complete interface with all the commands and a complex state machine to work in all the possible scenarios, the implementation provided assumes a lot of aspects (like the protocol version of the Device or that the Remote Host will always be the master of the connection) and simplifies a lot more (like all the security/encryption parameters) making it much more accessible and educational without renouncing to scalability.The HCI layer implemented in this guide works as follows:Configures the Device in a very simple and generic way instead of providing an interface.Accepts any remote connection and maintains it with just a minimal negotiation. Just supports one single ACL connection with a remote device.Provides an interface for both the upper and lower layers to send and receive data.Again, the sources provided can be easily changed to provide just a interface between the Bluetooth application and the Device.

Initialization:

Notice: For more detail just check the function HCI_Init() in hci.c.The initialisation routine simply allocates the configuration and connection data of the HCI control block. Some of the values in the configuration block are populated with the device information:Local name.PIN code.ACL buffer size.Number of ACL buffers.

Command assembly:

Notice: Check HCI_cmd() in hci.c.

Event handler:

Notice: For more detail just check HCI_Event_Handler() in hci.c.

HCI configuration:

Notice: For more detail just check the function HCI_CommandEnd() in hci.c.Here is where the specification of the HCI layer is completely ignored taking a very simple (and yet somehow reliable) way on handling the configuration of the Device. For a minimal implementation only few commands are needed during the configuration steps, all of them can be done in a given order and all of them generate a "Command complete Event". By knowing that the simplest approach is to issue a command and when completed issue the next one in the chain automatically.That's really it: RESET → WRITE HOST BUFFER SIZE → WRITE LOCAL NAME → WRITE CLASS OF DEVICE → WRITE SCAN ENABLEThis is done by switching the command complete event first byte which contains the complete command code that will implicitly point the next command to issue of the above list.

Data transfers:

All the data transfers are managed by the lower levels (USB host stack, main application and Bluetooth application) of the stack. The HCI layer just provides two API functions to handle data HCI_putData() and HCI_putEvent().

HCI USB interface:

Notice: The data comes from the Host, meaning that the I/O are from the Host point of view (IN: Device → Host, OUT: Host → Device).Since the PhysicalBus for the HCI can be implemented with a wide range of protocols (I2C, SPI, UART, USB...) a protocol independent layer is needed between the it and the actual physical bus API.In this case the implementation is really trivial since its reduced to some definitions regarding the frame sizes and a couple of calls to the Microchip USB library. For more detail just check the sources included in this manual, it should be really easy to read and understand.

HCI operation example:

This is an example of the working HCI layer implemented, the entire operation is divided in the 3 main parts of which the HCI layer has to take care of: Device setup, Remote Host connection and data exchange.The format is as follows:HCI {w|r} {CMD|EVT|ACL}: Notice that the CMD (commands) are always w (write, Host → Device) and the EVT (events) are always r (read, Device → Host) but the ACL (data) can be in both directions write (Host → Device → Remote Host) or read (Remote Host → Device → Host).

Bluetooth Controller setup:

RESETHCI w CMD: 03 0C 00COMMAND COMPLETEHCI r EVT: 0E 04 01 03 0C 00WRITE HOST BUFF SIZEACL frame len = 252bytes SCO frame len = 0bytes ACL frame buffers = 0 (Infinite) SCO frame buffers = 0 (Infinite) HCI w CMD: 33 0C 07 FC 00 00 00 00 00 00COMMAND COMPLETEHCI r EVT: 0E 04 01 33 0C 00WRITE LOCAL NAMEName = "PIC32_BTv1\0" HCI w CMD: 13 0C 0B 50 49 43 33 32 5F 42 54 76 31 00COMMAND COMPLETEHCI r EVT: 0E 04 01 13 0C 00WRITE CLASS OF DEVICEMajor class = Computer Minor class = Desktop HCI w CMD: 24 0C 03 04 01 18COMMAND COMPLETEHCI r EVT: 0E 04 01 24 0C 00WRITE SCAN ENABLEInquiry scan = Enable Page scan = Enable HCI w CMD: 1A 0C 01 03COMMAND COMPLETEHCI r EVT: 0E 04 01 1A 0C 00

Connection accept:

CONNECTION REQUESTBD ADDR = 00:22:F7:17:06:C5 Class of Device = Computer, Laptop Link type = 0x01 (ACL) HCI r EVT: 04 0A C5 06 17 F7 22 00 0C 01 1C 01CONNECTION ACCEPTBD ADDR = 00:22:F7:17:06:C5 Role = 0x01 (Remain slave) HCI w CMD: 09 04 07 C5 06 17 F7 22 00 01COMMAND STATUSStatus = Pending Number of HCI command packets = 0x01 Command OpCode = 0x09 0x04 HCI r EVT: 0F 04 00 01 09 04CONNECTION COMPLETEStatus = Connection successfully completed Connection handle = 0x00 0x00 BD ADDR = 00:22:F7:17:06:C5 Link type = 0x01 (ACL) Encryption mode = 0x00 (Encryption not required) HCI r EVT: 03 0B 00 00 00 C5 06 17 F7 22 00 01 00MAX SLOTS CHANGEConnection handle = 0x00 0x00 LMP maximum slots = 0x05 HCI r EVT: 1B 03 00 00 05

Data exchange:

READ ACL DATA PACKETHCI r ACL: 00 20 0C 00 08 00 01 00 02 01 04 00 01 00 43 00


http://www.broadcom.com/products/Bluetooth

http://www.palowireless.com/bluetooth/bluejacking.asp


///-//---//-//---//////BLUEJACK::::::::::::::::


[  Also see:  Bluetooth Security   Bluetooth Testing   Wireless Security  ] 

Bluejacking

 Welcome to our section on "Bluejacking" and related topics. 

Research Reports

Wireless Opportunities in Healthcare 2011 (The Market for Bluetooth, RFID, Zigbee, UWB WWAN, WMAN, WLAN and other technologies)Kalorama Information, Sep 2011Electronic Security SystemsGlobal Industry Analysts, Jan 2012The Mobile Security (mSecurity) Market 2012-2017Visiongain, Feb 2012Worldwide Communications, Multimedia, and Security Interfaces and Technologies Embedded in PCs 2012?2016 ForecastIDC, May 2012More Research Reports  

Interesting Articles

CIO Update Bluetooth: Plugging the Latest Enterprise Security Loophole (10/05) Bluetooth is everywhere today and needs to be secured just like the mini WiFi hub it is. Now that Bluetooth has gained significant deployment and is being used to power real-world business solutions, it faces a problem common to all fast-emerging communications technologies: security...PCWorld 'Car Whisperer' Puts Hackers in the Driver's Seat (8/05) Software connects car Bluetooth systems with a remote PC so hackers can eavesdrop. If you happen to hear a disembodied computer voice tell you to "drive carefully" next time you're behind the wheel, you've probably met the Car Whisperer. Released at the What the Hack computer security conference, Car Whisperer is software that tricks the hands-free Bluetooth systems installed in some cars into connecting with a Linux computer. The software takes advantage of the fact that many of these hands-free systems require only a very simple four-digit security key--often a number such as 1234 or 0000--in order to grant a device access to the system.Bluetooth SIG Bluetooth SIG Response to Recent Analysis of Pairing and Security (6/05) New Scientist reported a new security threat to Bluetooth technology in June 2005 (New hack cracks 'secure' Bluetooth devices) from two Israeli researchers who suggested a way to subvert one of the built-in Bluetooth security mechanisms. Bluetooth devices generate a secure connection by means of the initial pairing process. During this process one or both devices need a PIN code to be entered, which is used by internal algorithms to generate a secure key which is then used to authenticate the devices whenever they connect in the future. The new academic paper puts forward a theoretical process that could potentially "guess" the security settings on a pair of Bluetooth devices. To do this the attacking device would need to listen in to the initial one-time pairing process. From this point it can use an algorithm to guess the security key and masquerade as the other Bluetooth device....Forbes Bluetooth cell phones susceptible to hacker attacks (6/04) The technology information Web portal Xonio recommends owners of Bluetooth cell phones to exercise caution. Cell phones equipped with the wireless data transference technology are relatively susceptible to attacks from hackers, the Stuttgart based online magazine warns. Xonio tested 23 models from various manufacturers, with 13 turning up security problems. For four of the Bluetooth cell phones, it was even possible for a hacker to take complete control of the device and, unbeknown to the owner, do things like dial any desired number.The Advertiser World's first mobile phone virus strikes (6/04) The world's first virus which infects mobile phones has been found – prompting fears of a new generation of assaults on information technology systems. Known as Cabir, the virus infects phones by inscribing Caribe on mobile phone screens each time they are switched on. It was found in France, but mobile users have reported being infected in Adelaide.2006 Wireless Broadband TechnologyThis report introduces managers, investors and technical people to the major wireless broadband technologies IEEE 802.11 (WiFi) and IEEE 802.16 (WiMAX) - and to a number of related technologies. These include short-distance Bluetooth and Ultra Wideband (UWB) and several short distance low-rate systems such as RFID (Radio Frequency Identification), ZigBee (IEEE 802.15.4) and Near-Field Communications (NFCIP).Key sections:- Historical background Principles of operation Technical standards Critical analysis of strengths and weaknesses Competition with other technologies Opportunities for new services Combining technologies Industry consortia, standards bodies, regulators and key vendors Explaining established technologies in detailPublished By: Paul Budde Communication Pty LtdDate Published: Sep 2006* * * * * *

Useful Sites and Resources

BBCNew mobile message craze spreads (11/03) Are you being bluejacked? Phone owners now have something else to do with their handset: bluejacking. This involves sending anonymous text messages to other phone users via Bluetooth short-range radio. Mobile phone buffs have been bluejacking for months but it now looks set to become much more widespread.bluejackqThe world's first website dedicated to bluejacking:what is bluejacking?  how to bluejackBluejacking SoftwareNews and information about Bluejacking.Bluescanner.orgFree Windows tool for Bluetooth vulnerability assessment. Discovers and catalogues all Bluetooth devices in range.EsatoBluejacking? Tips and tricks, Bluejacking: P800/P900, I did something naughty today!, bluejacking and now bluesnarfingand other topics.ZDNetBluejacking spawns 'toothing' on trains (4/04) Bored commuters are employing Bluetooth phones to set up sex with strangers. British commuters take note -- the respectable person sitting next to you on the train fumbling with their cell phone might be a "toother'' looking for sex with a stranger. "Toothing'' is a new craze where strangers on trains, buses, in bars and even supermarkets hook up for illicit meetings using messages sent via the latest in phone technology.'Bluejacking' hits the mainstream (11/03) People with Bluetooth-enable mobile phones can send messages anonymously to those with similar phones nearby, creating a new craze. Bluetooth enables devices within a few metres of each other to exchange information wirelessly - a technology that users with Bluetooth-enabled mobiles are making the most of to send text messages to strangers anonymously. This drive-by messaging has been dubbed 'bluejacking'.Also see:n.runsBTCrack a Bluetooth PIN Recovery tool developed by Thierry Zoller.WM-softThe Real Bluejack is software for smartphones and Pocket PCs, that use Bluetooth. It extends your device's Bluetooth functions. This program can: send Bluetooth messages, browse target-device's filesystem via OBEX protocol, send AT commands, get phonebook, send SMS via target-phone, send files up to 2x faster then file managers, receive files directly into the Storage Card and other features."THE REAL BLUEJACK" IS NOT INTENDED FOR GETTING UNAUTHORIZED ACCESS TO PERSONAL DATA! Authentication is required! (But after you can do everything that you want)

*Diagram Source: Courtesy of Bluetooth SIG,HCI Specs, Fig 1.2 , p 544

¦¦¦¦¦¦¦¦¦¦¦¦¦¦-------------¦¦¦¦¦¦¨¨¨

4.1.1  HCI Firmware    (location: Host Controller)

   HCI Firmware , is located on the Host Controller , (e.g. the actual Bluetooth hardware device). The HCI firmware implements the HCI Commands for the Bluetooth hardware by accessing basebandcommands, link manager commands, hardware status registers, control registers, and event registers. The term Host Controller means the HCI-enabled Bluetooth device 

4.1.2  HCI Driver         (location: Host)

    HCI Driver , which is located on the Host (e.g. software entity). The Host will receive asynchronous notifications of HCI events, HCI events are used for notifying the Host when something occurs. When the Host discovers that an event has occurred it will then parse the received event packet to determine which event occurred. The term Host means the HCI-enabled Software Unit. 

4.1.3  Host Controller Transport Layer   (location: Intermediate Layers)

    The HCI Driver and Firmware communicate via the Host Controller Transport Layer , i.e. a definition of the several layers that may exist between the HCI driver on the host system and the HCI firmware in the Bluetooth hardware. These intermediate layers, the Host Controller Transport Layer, should provide the ability to transfer data without intimate knowledge of the data being transferred. Several different Host Controller Layers can be used, of which 3 have been defined initially for Bluetooth : USB , UART and RS232. The Host should receive asynchronous notifications of HCI events independent of which Host Controller Transport Layer is used. 

4.2  HCI Commands

   The HCI provides a uniform command method of accessing the Bluetooth hardware capabilities. The HCI Link commands provide the Host with the ability to control the link layer connections to other Bluetooth devices. These commands typically involve the Link Manager (LM) to exchange LMP commands with remote Bluetooth devices. The HCI Policy commands are used to affect the behaviour of the local and remote LM. These Policy commands provide the Host with methods of influencing how the LM manages the piconet. The Host Controller and Baseband commands, Informational commands , and Status commands provide the Host access to various registers in the Host Controller. 

4.2.1  HCI-Specific Information Exchange

   The Host Controller Transport Layer provides transparent exchange of HCI-specific information. These transporting mechanisms provide the ability for the Host to send HCI commands, ACL data, and SCO data to the Host Controller. These transport mechanisms also provide the ability for the Host to receive HCI events, ACL data, and SCO data from the Host Controller. Since the Host Controller Transport Layer provides transparent exchange of HCI-specific information, the HCI specification specifies the format of the commands, events, and data exchange between the Host and the Host Controller. 

4.2.2  Link Control Commands

    The Link Control commands allow the Host Controller to control connections to other Bluetooth devices. When the Link Control commands are used, the Link Manager (LM) controls how the Bluetoothpiconets and scatternets are established and maintained. These commands instruct the LM to create and modify link layer connections with Bluetooth remote devices, perform Inquiries of other Bluetooth devices in range, and other LMP commands. 

4.2.3  Link Policy Commands

   The Link Policy Commands provide methods for the Host to affect how the Link Manager manages the piconet. When Link Policy Commands are used, the LM still controls how Bluetooth piconets and scatternets are established and maintained, depending on adjustable policy parameters. These policy commands modify the Link Manager behaviour that can result in changes to the link layer connections with Bluetooth remote devices. 

4.2.4  Host Controller & Baseband Commands

   The Host Controller & Baseband Commands provide access and control to various capabilities of the Bluetooth hardware. These parameters provide control of Bluetooth devices and of the capabilities of the Host Controller, Link Manager, and Baseband. The host device can use these commands to modify the behaviour of the local device. 

4.2.5  Informational Parameters

    The Informational Parameters are fixed by the manufacturer of the Bluetooth hardware. These parameters provide information about the Bluetooth device and the capabilities of the Host Controller, Link Manager, and Baseband. The host device cannot modify any of these parameters. 

4.2.6  Status Parameters

   The Host Controller modifies all status parameters. These parameters provide information about the current state of the Host Controller, Link Manager, and Baseband. The host device cannot modify any of these parameters other than to reset certain specific parameters. 

4.2.7  Testing Commands

   The Testing commands are used to provide the ability to test various functionality's of the Bluetooth hardware. These commands provide the ability to arrange various conditions for testing.  

4.3  HCI Events/ Error Codes/ Flow Control

4.3.1   Flow Control

    Flow control is used in the direction from the Host to the Host Controller to avoid filling up the Host Controller data buffers with ACL data destined for a remote device (connection handle) that is not responding. It is the Host that manages the data buffers of the Host Controller. 

4.3.2  HCI Events

    A number of different events are defined for the HCI layer. The events provide a method to return parameters and data associated for each event. 32 HCI different events have been implemented so far, they range from Inquiry Complete Event to Page Scan Repetition Mode Change Event. See the main HCI specs for mode details. 

4.3.3  HCI Error Codes

    A large number of error codes have been defined for the HCI layer. When a command fails, Error codes are returned to indicate the reason for the error. 35 HCI error codes have so far been defined, from Unknown HCI Command to LMP PDU Not Allowed.See the main HCI specs for mode details. 

4.4  Bluetooth-defined Host Controller Transport Layers

4.4.1  UART Transport Layer

    The objective of the HCI UART Transport Layer is to make it possible to use the Bluetooth HCI over a serial interface between two UARTs on the same PCB. The HCI UART Transport Layer assumes that the UART communication is free from line errors. Event and data packets flow through this layer, but the layer does not decode them. 

4.4.2  RS232 Transport Layer

   The objective of the HCI RS232 Transport Layer is to make it possible to use the Bluetooth HCI over one physical RS232 interface between the Bluetooth Host and the Bluetooth Host Controller. Event and data packets flow through this layer, but the layer does not decode them. 

4.4.3  USB Transport Layer

   The objective of the Universal Serial Bus (USB) Transport Layer is to the use a USB hardware interface for Bluetooth hardware (which can be embodied in one of two ways: as a USB dongle, or integrated onto the motherboard of a notebook PC). A class code will be used that is specific to all USB Bluetooth devices. This will allow the proper driver stack to load, regardless of which vendor built the device. It also allows HCI commands to be differentiated from USB commands across the control endpoint. Note, the above text contains excerpts from the Bluetooth SIG's Specification, as well as various interpretations of the Specs. For complete details of the various sections, consult the actual Bluetooth Specification.  


HCI is the layer that handles the BT Controller configuration, remote connections and data transfers.The understanding of basic concepts involving the HCI layer will be assumed for the rest of this manual, please check the "Palowireless HCI tutorial" to get quickly introduced into the protocol.For the complete specification and all the details check the Bluetooth Core v2.0 Specification "Volume 2 Core System Package, Part E Host Controller Interface Functional Specification".Some previous definitions:Host: Both the USB Host and the BT Host (i.e. the PIC32 board).Device: Both the USB Device and the BT Controller (i.e. the USB Bluetooth Dongle).Remote Host: Another device (i.e. phone, PC...) that will establish connection with the Device being controller by the embedded Bluetooth stack we are developing.

Data formats and packet examples:

All the information regarding the data formats can be found in the "Volume 2 Core System Package, Part E Host Controller Interface Functional Specification, 5 HCI Data Formats" and it's very well worth reading (except the 5.4.3 HCI Synchronous Data Packets part).Command packet example:Write local name = 0x13 0x0C 0x0B 0x50 0x49 0x43 0x33 0x32 0x5F 0x42 0x54 0x76 0x31 0x00OpCode = 0x13 0x0C = OCF | (OGF << 10) = 0x13 | (0x03<<10)Parameter Total Length = 0x0B = 11Parameters:Local Name (NULL terminated string) = 0x50 0x49 0x43 0x33 0x32 0x5F 0x42 0x54 0x76 0x31 0x00 = "PIC32_BTv1\0"Notice: This command specification can be found in "Volume 2 Core System Package, Part E Host Controller Interface Functional Specification, 7.3.11 Write Local Name Command".Event packet example:Command complete = 0x0E 0x04 0x01 0x13 0x0C 0x00EvtCode = 0x0EParamaters:Number of HCI Command Packets = 0x01Command OpCode = 0x13 0x0C = Write Local Name CommandReturn = 0x00 = Success (Depends on the command)Notice: This event specification can be found in "Volume 2 Core System Package, Part E Host Controller Interface Functional Specification, 7.7.14 Command Complete Event".Data packet example:ACL Data = 0x00 0x20 0x0C 0x00 0x08 0x00 0x01 0x00 0x02 0x01 0x04 0x00 0x01 0x00 0x43 0x00Connection handle = 0x00 0x20Data length = 0x0C 0x00 = 12 (Remember that the data is in LittleEndian)Data = 0x08 0x00 0x01 0x00 0x02 0x01 0x04 0x00 0x01 0x00 0x43Notice: This is an L2CAP signaling frame. For now is out of scope.

Commands and events:

All the information regarding commands and events can be found in the "Volume 2 Core System Package, Part E Host Controller Interface Functional Specification, 7 HCI Commands and Events". I recommend to have the document at hand in order to follow the next example.

HCI layer implementation:

The complete HCI layer has a huge amount of commands and events to handle all the possible scenarios (low power operation, scatternets, piconets, multiple links, data encryption...) which can be overwhelming and completely out of scope. Fortunately enough the 90% of that complexity can be ignored and still get a decent Bluetooth HCI implementation for a limited device (such as our PIC32).The most important limitations will be:Slave operation only.Single connection oriented.No data encryption.Lack of support for low power operation.Regardless of the limitations listed above the HCI implementation provided with this manual can be scaled up to 100% of compliance without changing the design in any way.Instead of provide a complete interface with all the commands and a complex state machine to work in all the possible scenarios, the implementation provided assumes a lot of aspects (like the protocol version of the Device or that the Remote Host will always be the master of the connection) and simplifies a lot more (like all the security/encryption parameters) making it much more accessible and educational without renouncing to scalability.The HCI layer implemented in this guide works as follows:Configures the Device in a very simple and generic way instead of providing an interface.Accepts any remote connection and maintains it with just a minimal negotiation. Just supports one single ACL connection with a remote device.Provides an interface for both the upper and lower layers to send and receive data.Again, the sources provided can be easily changed to provide just a interface between the Bluetooth application and the Device.

Initialization:

Notice: For more detail just check the function HCI_Init() in hci.c.The initialisation routine simply allocates the configuration and connection data of the HCI control block. Some of the values in the configuration block are populated with the device information:Local name.PIN code.ACL buffer size.Number of ACL buffers.

Command assembly:

Notice: Check HCI_cmd() in hci.c.

Event handler:

Notice: For more detail just check HCI_Event_Handler() in hci.c.

HCI configuration:

Notice: For more detail just check the function HCI_CommandEnd() in hci.c.Here is where the specification of the HCI layer is completely ignored taking a very simple (and yet somehow reliable) way on handling the configuration of the Device. For a minimal implementation only few commands are needed during the configuration steps, all of them can be done in a given order and all of them generate a "Command complete Event". By knowing that the simplest approach is to issue a command and when completed issue the next one in the chain automatically.That's really it: RESET → WRITE HOST BUFFER SIZE → WRITE LOCAL NAME → WRITE CLASS OF DEVICE → WRITE SCAN ENABLEThis is done by switching the command complete event first byte which contains the complete command code that will implicitly point the next command to issue of the above list.

Data transfers:

All the data transfers are managed by the lower levels (USB host stack, main application and Bluetooth application) of the stack. The HCI layer just provides two API functions to handle data HCI_putData() and HCI_putEvent().

HCI USB interface:

Notice: The data comes from the Host, meaning that the I/O are from the Host point of view (IN: Device → Host, OUT: Host → Device).Since the PhysicalBus for the HCI can be implemented with a wide range of protocols (I2C, SPI, UART, USB...) a protocol independent layer is needed between the it and the actual physical bus API.In this case the implementation is really trivial since its reduced to some definitions regarding the frame sizes and a couple of calls to the Microchip USB library. For more detail just check the sources included in this manual, it should be really easy to read and understand.

HCI operation example:

This is an example of the working HCI layer implemented, the entire operation is divided in the 3 main parts of which the HCI layer has to take care of: Device setup, Remote Host connection and data exchange.The format is as follows:HCI {w|r} {CMD|EVT|ACL}: Notice that the CMD (commands) are always w (write, Host → Device) and the EVT (events) are always r (read, Device → Host) but the ACL (data) can be in both directions write (Host → Device → Remote Host) or read (Remote Host → Device → Host).

Bluetooth Controller setup:

RESETHCI w CMD: 03 0C 00COMMAND COMPLETEHCI r EVT: 0E 04 01 03 0C 00WRITE HOST BUFF SIZEACL frame len = 252bytes SCO frame len = 0bytes ACL frame buffers = 0 (Infinite) SCO frame buffers = 0 (Infinite) HCI w CMD: 33 0C 07 FC 00 00 00 00 00 00COMMAND COMPLETEHCI r EVT: 0E 04 01 33 0C 00WRITE LOCAL NAMEName = "PIC32_BTv1\0" HCI w CMD: 13 0C 0B 50 49 43 33 32 5F 42 54 76 31 00COMMAND COMPLETEHCI r EVT: 0E 04 01 13 0C 00WRITE CLASS OF DEVICEMajor class = Computer Minor class = Desktop HCI w CMD: 24 0C 03 04 01 18COMMAND COMPLETEHCI r EVT: 0E 04 01 24 0C 00WRITE SCAN ENABLEInquiry scan = Enable Page scan = Enable HCI w CMD: 1A 0C 01 03COMMAND COMPLETEHCI r EVT: 0E 04 01 1A 0C 00

Connection accept:

CONNECTION REQUESTBD ADDR = 00:22:F7:17:06:C5 Class of Device = Computer, Laptop Link type = 0x01 (ACL) HCI r EVT: 04 0A C5 06 17 F7 22 00 0C 01 1C 01CONNECTION ACCEPTBD ADDR = 00:22:F7:17:06:C5 Role = 0x01 (Remain slave) HCI w CMD: 09 04 07 C5 06 17 F7 22 00 01COMMAND STATUSStatus = Pending Number of HCI command packets = 0x01 Command OpCode = 0x09 0x04 HCI r EVT: 0F 04 00 01 09 04CONNECTION COMPLETEStatus = Connection successfully completed Connection handle = 0x00 0x00 BD ADDR = 00:22:F7:17:06:C5 Link type = 0x01 (ACL) Encryption mode = 0x00 (Encryption not required) HCI r EVT: 03 0B 00 00 00 C5 06 17 F7 22 00 01 00MAX SLOTS CHANGEConnection handle = 0x00 0x00 LMP maximum slots = 0x05 HCI r EVT: 1B 03 00 00 05

Data exchange:

READ ACL DATA PACKETHCI r ACL: 00 20 0C 00 08 00 01 00 02 01 04 00 01 00 43 00

No comments:

Post a Comment