Android手机中基带跟踪数据的导出功能设计＊

黄一峰，黄俊伟，吴恋

（重庆邮电大学 新一代宽带移动通信终端研究所，重庆400065）

引 言

在目前流行的Android手机设计方案中，应用处理器（AP）和通信处理器（CP）因为对任务实时性的要求不同而相对独立。典型地，AP和CP子系统分别运行手机系统的应用操作系统（Android）和基带操作系统（Nucleus）［1］。

在手机开发过程中，大部分的功能调试通过AP侧来完成。因此，将CP侧的基带跟踪数据导出到AP侧进行保存和分析，对于手机开发过程中的功能调试和Bug修复都具有非常重要的意义［2－3］。

本文设计了一种双硬件芯片环境下的基带跟踪数据的导出方案。其中，基带系统运行在重邮信科公司C6310双模（TD－SCDMA＋GSM）CP芯片上，应用系统运行在三星Exynos 4412四核AP芯片上。两者通过串口机制进行通信和数据共享。本文的设计主要包括AP侧软件模块设计、CP侧软件模块设计，以及串口通信机制设计。

在实际的手机产品中应用本文的设计，进行大数据量、长时间基带跟踪数据导出实验和可靠性分析，得到了良好的实验结果，验证了本文设计的可行性和可靠性。

1 系统框架设计

1.1 系统总体框架设计

图1为基带跟踪数据导出方案的整体框架。整个方案包括CP、AP以及串口机制三个方面。其中，CP侧主要由跟 踪 数 据 产 生 模 块 （ARMLOG TRACE、DSPLOG TRACE）和CP侧串口驱动组成；AP侧主要由数据接收模块（ARMLOG Driver、DSPLOG Driver），USB传输模块（USB Gadget Driver）和 AP侧串口驱动组成。

在CP侧，Nucleus操作系统的跟踪数据进程（ARM－log trace和DSPlog trace）负责产生基带的跟踪数据，经过设备抽象层（DAI）转发后，基带跟踪数据被CP侧串口驱动存入串口缓存Buffer中。

图1 方案整体框架图

同时在AP侧，对应的串口驱动将从串口缓存buffer中读取到的跟踪数据上报给AP侧数据接收进程（ARM－LOG Driver和 DSPLOG Driver）。最后，AP侧数据接收进程调用 USB传输驱动（USB Gadget Driver），将跟踪数据发送到PC端软件进行显示或保存。

串口机制包括物理上的数据缓存（Buffer）和公共的函数接口（API），AP侧和CP侧串口驱动通过调用这些公共的函数接口，即可完成相互通信和数据传输，从而达到两个系统交互的目的。

1.2 AP侧软件交互流程

图2为AP与CP侧软件交互示意图。基带跟踪数据采用流数据的形式，数据的存储和解析由PC端的Trace软件完成。因此AP侧不关心数据的具体格式，其关注点在于数据的接收和传送过程。AP侧软件流程步骤如下：

① 系统启动以后，AP侧ARMLOG DSPLOG Driver连接USB为向 ARM DSP Gadget Driver发送数据作准备。首先进行相关的初始化工作，包括缓存的申请、一些全局变量的初始化、设备的注册等工作。

② 其后工作主要在ARMLOG DSPLOG Driver中完成。调用在初始化函数中调用的serial＿create＿ch（）函数，注册基带跟踪功能专用的串口通道。

③ 启动工作队列函数trace＿read＿serial＿work（），准备向USB数据缓冲区（usb＿fifo）发送跟踪数据。

④ 在工作队列函数trace＿read＿serial＿work（）中调用串口通道读函数serial＿read＿avail（），获取串口通道中CP侧发来的跟踪数据长度r，r表示串口通道中可读数据长度。

⑤ 如果r≠0，表示CP侧发来数据，则继续调用serial＿read（）函数将通道中的跟踪数据读取到USB数据缓冲区（usb＿buf）中，ARM／DSP Gadget Driver驱动提供的接口trace＿write（）将缓冲区中保存的跟踪数据通过USB发往PC，发送完成后再调用trace＿read＿serial＿work（），进入下一次数据收发流程；如果r＝0，则说明串口通道中没有可读的跟踪数据，此时调用休眠等待函数wait＿interrupt（），使跟踪进程进入睡眠等待。进程唤醒条件为跟踪通道中有可读数据，中断到来后唤醒跟踪进程。

图2 AP侧和CP侧软件交互图

⑥trace＿read＿serial＿work（）工作队列调用时机说明：trace＿read＿serial＿work（）首次调用放在 USB连接tra－ceusb＿connect（）函数中，当系统检测到有USB插入时，traceusb＿connect（）函数即被调用，当一次跟踪数据通过USB完全送出后，跟踪数据发送完成函数trace＿write＿complete（）会被执行，在该函数中再次调用，准备第二次数据的发送。

1.3 CP侧跟踪数据发送流程

CP侧负责跟踪数据的记录和发送工作。CP侧跟踪数据发送具体流程如下：

① 定时器每10ms判断发送DSP或ARM的跟踪数据。

② 若跟踪数据长度满足发送长度条件，则进行混合帧头封装，不满足则退出。

③ 通过平台无关化调用DAI＿TRA＿SEND（）函数发送L长度的跟踪数据。

④ 函数调用完成后返回处理结果retVal。

⑤判断retVal是否等于发送长度L，若是则更新buffer数据索引然后结束，否则直接结束。

2 串口机制设计

串口机制为AP和CP间的trace驱动提供通信和数据传送功能，起到了一个桥梁的作用。其软件结构设计如图3所示。

图3 串口机制软件结构图

在AP和CP上有对等的串口驱动模块。二者有公共的数据结构和循环数据缓冲区管理接口。

串口机制提供给AP和CP的外部API包括创建数据通道（serial＿create＿ch）、读通道数据（serial＿read）、写通道数据（serial＿write）、注册通道中断（serial＿register＿inthandle）、通道复位（serial＿reset）等。

对外部接口的实现、内部接口的实现、通道对象管理和中断ISR的实现等，AP和CP需要分别实现。AP和CP外部API接口相同，但具体实现不同。

在调试中首先采用的是普通串口方式，我们发现在数据通信过程中会频繁产生中断，占用系统资源过大；同时在大数据量的跟踪数据导出时会产生延迟。因此，在AP侧和CP侧同时采用串口的DMA传输方式，可有效地降低资源占用，同时传输效率得以保证。

3 方案验证分析与测试结果

系统功能的测试主要包括两个测试点：

① 数据通路是否畅通。包括 Trace USB Gadget Driver与 AP ARMLOG／DSPLOG Driver之间的通路，AP ARMLOG／DSPLOG Driver与 AP Serial Driver之间的通路，AP Serial Driver与 CP Serial Driver之间的通路，CP Serial Driver与CP Trace Module之间的通路。

② 导出的跟踪数据是否完整有效。针对第一个测试点，可以在各个数据通路之间采取假数据上报的方式进行测试，譬如，在AP侧Serial Driver中用假数代替从基带获取的跟踪数据送往 AP ARMLOG／DSPLOG Driver中，测试两者间通路是否畅通。

针对第二个测试点，需要在完整的系统平台上，连续测试24小时以上，期间包括基带数据业务的使用，以验证整体模块功能的可行性和可靠性［5］。

具体测试场景设计如表1所列。

表1 测试场景列表

多次测试后，通过PC端的Trace导出软件观察，保存出来的跟踪数据既没有重复显示历史跟踪数据，也没有出现跟踪数据丢失和错乱的情况，有序、准确无误地输出预想的跟踪数据，如图4所示。

图4 导出的基带数据截图

结 语

本文所提出的基带Trace导出功能模块，已经在基于 Linux 2.6.29内核的 Android 4.0定制版本上实现。在模块设计中，采用了串口通信机制，使AP与CP两个独立系统的通信和数据交换十分方便。同时在AP侧的ARMLOG／DSPLOG驱动中，使用工作队列和中断唤醒的技术，在没有数据传送时，整个数据通道处于睡眠状态，有效地节省了系统资源开销。既保证数据的完整有效性，也能满足实际项目的需求。

［1］王海霞.TD／GSM双模手机软件架构的研究与实现 ［D］.南京：南京邮电大学，2010.

［2］李志丹.嵌入式软件调试方法研究［J］.计算机与数字工程，2012（7）：157－159.

［3］朱亚洲.GSM 手机软件开发［D］.武汉：武汉科技大学，2007.

［4］陶少玉.高效基带芯片调试方法的研究及其在MTK手机开发中的应用 ［D］.上海：上海交通大学，2009.