android蓝牙的调试（博通蓝牙工作 and 低功耗模式）

首先结合项目从整体上去把握这部分：

蓝牙模块中一个比较核心的文件是bluetooth.c, 在我们上电的时候， 会调用这个文件中bt_enable()这个函数， 在这个函数里面先调用set_bluetooth_power()上电，然后调用property_set("ctl.start", "hciattach")， 去启动hciattach这个服务，从而运行brcm_patchram_plus这个进程。这个服务会加载我们firmware等一些工作。这部分工作做完后， 我们会调用property_set("ctl.start","bluetoothd")，这个服务是启动我们的bluz进程。如果以上成功的话，蓝牙芯片将会开始工作。

蓝牙需要正常工作，简而言之，需要做三部分工作：

i)     给芯片上电。

ii)  hciattach服务启动，从而加载固件，设置波特率等一系列的操作。（硬）

iii  启动bluetooth的协议，从而让蓝牙去正常工作。                 （软）

其次来分析下具体的工作流程：

a) BT管脚介绍

BT_REG_ON 和BT_RESET打开蓝牙时拉高， 关闭蓝牙时候拉低。 平时不需要控制。一般放在RF-KILL里面，可以在命令行里面操作。

UART可以一直配置为UART（TX/RX/RTS/CTS）， 也可以只在使用蓝牙的时候配置为UART.

I）相互对应:  TX和RX,RTS和CTS， RTS和CTS用来做硬件流控

II)把自己的RTS(对方的CTS)拉高,对方就不能发数据

III)检测到自己的CTS为高(对方的RTS),就不能给对方发数据

IV)BT上电后(未做初始化),BT_RTS应为低

V)主机串口未打开后应该为低

睡眠控制脚： HOST_WAKE 和BT_WAKE

i) 对于AP来说， 一个是GPO, 一个是中断。

ii) 在BT使用前配置好， 在bluesleep.c中控制。

iii) 如果不使用lpm（低功耗模式）， 可以不管这些， 在新板回来验证bt功能时候， 往往不需要低功耗模式。

a) 硬件验证

首先应该做下面的事情：

i)配置好UART的管脚

ii)配置好BT_REG_ON/BT_RESET的管脚, 并改好RFKILL代码

iii)BT_WAKE和HOAT_WAKE可以先不配

其次验证流程

下电:通过RFKILL拉低BT_REG_ON和BT_RESET让BT进入缺省状态

上电：同样通过RFKILL拉高BT_REG_ON和BT_REST让芯片处于上电状态

通过brcm_patchram_plus初始化BT芯片

Hciconfig uart0 up

Hcitool scan搜索设备，如果能够搜索到设备，则说明蓝牙芯片ok.

b) Brcm_patchram_plus的作用

像我们上面提到的那样， 在启动hciattach服务的时候， 会启动这个brcm_patchram_plus这个进程。这个进程是有brcm_patchram_plus.c这个文件编译而成。

它的作用是初始化蓝牙芯片， 进行基本参数的配置： lpm、PCM等参数

参数解释（brcm_patchram_plus）列出

-d： 显示调试信息

-enable_hci： 启动hci协议

-enable_lpm： 启动lpm模式

-baudrate： 指定工作时的波特率

-patchram： 指定hcd文件

- bd_addr： 加载蓝牙地址

- /dev/ttyxxx: 指定串口

brcm_patchram_plus  -d –bd_addrxx:xx:xx:xx:xx:xx --enable_hci --enable_lpm  --baudrate3000000  --patchram /etc/bcm4330.hcd  /dev/ttyHS0

进行硬件验证时可以简化:

brcm_patchram_plus-d --enable_hci  /dev/ttyHS0

c)  LowPower Mode

lpm的具体参数设定在brcm_patchram_plu.c代码中

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

};

BT芯片的lpm需要与HOST的bluesleep同时工作

在我们测试蓝牙睡眠的时候， 手动往/proc/bcm/asleep/proto写1， 就可以启动睡眠模式。

i)正常代码:

BlueZ:启动BT时,(BlueZ在bluetooth.c的bt_enable里面)

改动init.qcom.rc文件来打开/关闭BT芯片的lpm

servicehciattach /system/bin/brcm_patchram_plus --enable_hci --enable_lpm     --baudrate 3000000 --patchram/etc/firmware/bcm4329.hcd /dev/ttyHS0

ii）AP通过BT_WAKE来控制BT

拉高BT_WAKE: BT不能睡眠,或者必须醒来

拉低BT_WAKE:BT可以睡眠,睡不睡BT自己决定

HOST每次发数据前都要拉高BT_WAKE

BT如果睡眠,会拉高BT_RTS来阻止HOST发数据

iii）Bluesleep.c概述

bluesleep_init: 创建结点,bluesleep_probe: 申请GPIO/INT/WAKE_LOCK资源 ,启动定时器监控主机发送数据(超时即可拉低BT_WAKE),打开中断来监控HOST_WAKE的状态 ,bluesleep_outgoing_data: 拉高BT_WAKE唤醒BT ,bluesleep_hostwake_isr: 中断处理函数,进行wake任务调度。

对于新的项目， 我们首先确保HOST_WAKE和BT_WAKE的INT和GPIO能正确的申请到 ，其次确保bluesleep被编译,如下三个结点被创建

/proc/bcm/asleep/proto、/proc/bcm/asleep/hostwake、/proc/bcm/asleep/btwake

三、项目中蓝牙一些bug分析。

i）在传送多个文件过程中， 传输几个文件后， 传输的进度条停止不动。并且内核一直在打印h4_recv: Unknown HCI packet type

答： 我们申请Host_wake中断类型为高电平。当第一次打开蓝牙时， Host_wake =1时，此时产生中断。然后就轮番改变中断类型。当我们传输文件过程中，会来好多次中断，从而会响应多次中断处理函数，这个函数会进行反复打开和关闭串口的工作。这就是问题之所在。当bt给 HOST传数据的时候,反复打开、关闭串口，从而会造成一段时间内串口是不工作的。因此会导致bt中的buf溢出。这就是数据的帧检测位出问题的原因：rfcomm_recv_frame:bad checksum in packet。

我们的做法是：在传输文件过程中，不要让HOST去关闭串口。直到我们文件传输结束，再用内核定时器去关闭串口。

ii)在传输过程中， 在UI上面点击搜索蓝牙设备， 没有任何反应，或弹出蓝牙进程无响应。

答：这样的问题， 一般是处理睡眠代码的流程有问题。在点击搜索蓝牙设备将界面的时候，HOST没有唤醒蓝牙设备。

iii） 在待机的情况下， 其他手机给测试机传输文件， 测试机没有任何反应。

答：经过分析才发现是这样的情况：当其他手机给我们测试机传文件的时候，中断也来了响应，然而刚来了响应后，系统又重新进入suspend状态。

我们的做法：在刚接受文件的时候，  可以尝试着给HOST加wakelock，不要让HOST睡眠。这样可以很好地解决问题。不过不要忘记在最后也加上unwakelock下哦。

iv）蓝牙在某些特定的情况下打不开。概率非常非常低。重启完手机后，蓝牙可以正常打开。

答：一般都是由于蓝牙在patchram_plus加载firmware没有成功，从而造成的。有可能是进程阻塞引起的。在加载固件的时候，尝试着在再次加载固件。

v）某些型号（如kewei）车载蓝牙连上手机待机电流为11MA,分析下原因。

答：手机蓝牙连接上耳机或carkit后，即使在没有打电话及听音乐的状态下，物理链路还是会保持的，也就是蓝牙的射频仍然在工作（这是协议规定的，否则会发生来电时无法用耳机或carkit接听等问题），而不同的耳机或carkit查询链接存在的时间间隔有所不同（主要由双方在链路建立时协商决定），因此在待机电流上则表现为不同的产品不一样，如图1是手机与kewei连接上后的OTA（空中数据包分析仪），OTA表明系统的POLL和NULL交互非常频繁(kewei作为主，主动发起POLL)，这是导致手机待机电流上升的主要因素。图2 是和skyworth建立链接后的OTA，其交互频率要比kewei低10倍，因此表现在待机电流上会小些。

相关文档 下载： http://download.csdn.net/detail/angelbosj/4484676

版权声明：本文为博主原创文章，未经博主允许不得转载。