[quote] debugging android Bluetooth (Broadcom Bluetooth and low-power mode)
URL: http://www.phonesdevelopers.com/1695137/
First the combination of grasping this part of the project from a whole:
The Bluetooth module core file is bluetooth.c on electricity, I will call this file bt_enable () function, first call this function inside set_bluetooth_power () then call property_set ("CTL. start "," hciattach "), to start this service hciattach, and thereby this process run brcm_patchram_plus of. This service will load the firmware work. This part of the work is done, we will call property_set ("ctl.start", "bluetoothd"), this service is start our bluz process. If the above is successful, the Bluetooth chip will start working.
Bluetooth need to work properly, in short, need to do a three-part work:
i) the power to the chip.
ii) hciattach the service starts, thus loading the firmware, set the baud rate and so a series of operations. (Hard)
iii to start bluetooth Agreement Bluetooth to work properly. (Soft)
Second, to analyze for specific workflow:
a) Introduction to BT pin
The BT_REG_ON and BT_RESET pulled open the Bluetooth, turn off Bluetooth when low. Usually do not need to control.General on the RF-KILL inside is, can operate on the command line.
UART has been configured as UART (TX / RX / RTS / CTS), can also be configured only when using Bluetooth UART.
I) correspond to each other: TX and RX, RTS and CTS, RTS and CTS are used for hardware flow control
II) pulled the RTS (the other CTS), the other side can not send data
Iii) detection to the CTS (the other RTS), do not give the other data
Iv) BT after power (not done initialized), BT_RTS lower
V) host serial port is not open low
The sleep control foot: HOST_WAKE and BT_WAKE
i) for the AP, a GPO, an interrupt is.
. ii) BT before use, configure, control bluesleep.c.
iii) If you do not use LPM (low power mode), regardless of whether they verify the the bt function of time back in the new board, often do not require a low-power mode.
a) hardware verification
First of all, should do the following things:
i) configure the UART pin
ii) configured BT_REG_ON / BT_RESET pin and changing for the better RFKILL code
the iii) BT_WAKE HOAT_WAKE can unworthy
Followed by the verification process
Under power: by RFKILL low BT_REG_ON and BT_RESET BT default state
Power-on: the same by RFKILL pulled BT_REG_ON and BT_REST the chip is in power-on state
Through the initialization brcm_patchram_plus BT chip
Hciconfig uart0 up
The hcitool scan search equipment, if we can search to the device, then the Bluetooth chip ok.
the b) Brcm_patchram_plus role
As we mentioned above, when start hciattach service will start this brcm_patchram_plus this process. This process is brcm_patchram_plus.c this file compiled with.
Its role is to initialize the Bluetooth chip, the basic parameters configuration: lpm, PCM parameters
The parameters explained (brcm_patchram_plus) listed
-D: display debugging information
The-enable_hci: start HCI protocol
Enable_lpm: start lpm mode
-Baudrate: baud rate specified work
The-patchram: specify HCD file
- BD_ADDR: load the Bluetooth address
- / Dev / ttyxxx: Specifies the serial port
brcm_patchram_plus-d-bd_addrxx: xx: xx: xx: xx: xx - enable_hci - enable_lpm - baudrate3000000 - patchram / etc/bcm4330.hcd / dev/ttyHS0
Hardware verification can be simplified:
brcm_patchram_plus-d - enable_hci / dev/ttyHS0
c) LowPower Mode
the lpm specific parameters set in the brcm_patchram_plu.c code
unsignedchar hci_write_sleep_mode [] = {0x01, 0x27, 0xfc,
0x0c, / ??/ ??command length
0x01, / / ??Sleep_Mode UART
0x01, / / ??Host Idle Threshold, roughly 1 * 300ms
0x01, / / ??Host Controller Idle Threshold
0x01, / / ??BT_WAKE_Active_Mode, 0-active low, 1-active hgih
0x01, / / ??HOST_WAKE_Active_Mode, 0 - active low, 1-active hgih
0x01, / / ??Allow_Host_Sleep_During_SCO
0x01, / / ??Combine_Sleep_Mode_And_LPM
0x00, / / ??Enable_Tristate_Control_Of_UART_Tx_Line
0x00, / / ??Active_Connection_Handling_On_Suspend
0x00, / / ??Resume_Timeout
0x00, / / ??Enable_BREAK_To_Host
0x00 / / Pulsed_HOST_WAKE
};
The BT chip the lpm need HOST bluesleep work simultaneously
We tested the Bluetooth sleep manually to / proc / BCM / Asleep / proto write, you can start the sleep mode.
i) the normal code:
The BlueZ: start BT (bluez bt_enable in bluetooth.c the inside)
Changes init.qcom.rc file to open / close the BT chip lpm
servicehciattach / system / bin / brcm_patchram_plus - enable_hci - enable_lpm - baudrate 3000000 --patchram/etc/firmware/bcm4329.hcd / dev/ttyHS0
ii) AP by BT_WAKE to control BT
The pulled BT_WAKE: BT can not sleep, or to wake up
Pulled low BT_WAKE: BT can sleep, sleep is not sleep to BT
HOST each time before going to send data pulled BT_WAKE
BT sleep will be pulled BT_RTS to prevent HOST data.
iii) Bluesleep.c Overview
bluesleep_init: create a node, bluesleep_probe: application GPIO / INT / WAKE_LOCK, resources, start the timer monitoring host to send data (time-out can be pulled low BT_WAKE), open the interruption to monitor the state of the HOST_WAKE bluesleep_outgoing_data: pulled BT_WAKE wake BT, bluesleep_hostwake_isr: interrupt handler, wake task scheduling.
For new projects, we first ensure INT and of HOST_WAKE and BT_WAKE and GPIO can correct application Secondly ensure the bluesleep is compiled, the following three node is created
/ Proc / bcm / asleep / proto, / proc / bcm / asleep / hostwake, / proc / bcm / asleep / btwake
Third, the project Bluetooth some bug Analysis.
i) in the process of transferring multiple files, transfer several files, transfer progress bar stops moving. And the kernel has been in print h4_recv: Unknown HCI packet type
A: We to apply for Host_wake interrupt type is high. When you first open the Bluetooth Host_wake = 1, this time an interrupt is generated. Then turns to change the interrupt type. When we transfer files to a good many times interrupt, which will respond to multiple interrupt handler, this function will repeatedly open and close the work of the serial. This is where the problem lies.Bt to HOST pass data when repeatedly open and close the serial port, which will result in a period of time the serial port is not working. Therefore cause bt buf overflow. This is the cause of the problem of data frame detection bit: rfcomm_recv_frame: bad checksum in packet.
Our approach is: in the process of transferring files, do not let the HOST to close the serial port. Until the end of our file transfer, and then the kernel timer to close the serial port.
ii) in the transmission process, click on the search for Bluetooth devices in the UI above, nothing happens, or pop-up Bluetooth process is not responding.
A: such problems, ships have a problem, the flow of processing sleep code. Click to search for Bluetooth devices will interface, HOST did not wake up the Bluetooth device.
iii) In the case of standby, the other phone to transfer files to the testing machine, testing machine without any reaction.
A: After analysis, only to find that such a situation: when the other phone to our test machine transfer files to interrupt response, first came to the response, however, the system re-enter the suspend state.
Our approach: just accept the file, you can try HOST wakelock, do not let HOST sleep. This can be a good solution to the problem. But do not forget that in the final plus unwakelock oh.
iv) Bluetooth in certain specific circumstances open. The probability is very low. After restart the phone, the Bluetooth turns on properly.
A: are generally due to the Bluetooth firmware loaded in the patchram_plus not successful, resulting in the. May be caused by the process of blocking. When loading the firmware, try again to load the firmware.
v) some models, KEWEI Car Bluetooth to the phone standby current to 11mA, analysis The following reasons.
A: Bluetooth mobile phone connection on the headset or carkit, even if the state did not call and listen to music, physical link or will remain, the Bluetooth RF still at work (this is stipulated in the agreement, otherwise it will call can not answer with headset or carkit) headset or carkit query link time interval is different (the main link establishment negotiation by the parties in the decision), so standby current performance of different products not the same, as shown in Figure 1 is the phone kewei connection after OTA (air packet analyzer), OTA showed that the POLL and NULL interaction of system is very frequent (KEWEI as the main initiate POLL), which is leading mobile phone standby current rise the main factors. Figure 2 is a and skyworth to establish the OTA link interaction frequency than kewei to 10 times lower, so the performance on the standby current will be smaller.