首先结合项目从整体上去把握这部分：
蓝牙模块中一个比较核心的文件是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
版权声明：本文为博主原创文章，未经博主允许不得转载。
