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

时间:2024-02-25 17:12:21

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

蓝牙模块中一个比较核心的文件是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 

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