http://www.cfanz.cn/?c=article&a=read&id=38202
首先结合项目从整体上去把握这部分： 蓝牙模块中一个比较核心的文件是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倍，因此表现在待机电流上会小些。