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

2019-04-14 21:56发布

首先结合项目从整体上去把握这部分: 蓝牙模块中一个比较核心的文件是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