当前的Android手机设计中通常将应用子系统(AP)和通信子系统(CP)分离。比较典型的情况是应用子系统运行Android操作系统，通信子系统运行Nucleus操作系统，两者相对独立，通过一定的接口进行通信[1]。

    在手机运行过程中，通信子系统(即基带子系统(CP))会产生一些需要动态更新的数据，譬如手机系统数据、TD参数、GSM参数、音频校准数据等[2-3]。每台手机的这些数据都不尽相同。一般这些数据通过非失忆性介质(即NV(NonVolatile)模块)来进行保存和管理。因此，需要设计一种机制将CP侧的NV数据保存下来，以供基带子系统启动或运行时使用。
    本文设计了一种双硬件处理器环境下将基带NV数据保存到手机文件系统（Flash）中的方案。其中，基带系统运行在ARM9核心的单核CP芯片上，应用系统运行在Cortex A9核心的四核AP芯片上。两者通过IIC机制进行通信和数据共享。本文的设计主要包括AP侧软件模块设计、CP侧NV数据发送流程设计以及IIC通信机制设计。
    在实际的手机产品中应用本文的设计，进行大数据量、长时间基带NV数据保存测试，并进行可靠性分析，得到了良好的实验结果，证明了本设计的可靠性和可行性。
1 系统方案设计
1.1 系统总体框架设计
    基带NV数据保存方案包括AP侧软件模块、CP侧数据发送流程以及IIC通信机制三个方面，如图1所示。

    其中，CP侧主要由NV数据产生模块(NVM Process)和CP侧IIC驱动组成；AP侧主要由数据接收模块(NVM Driver)、NV数据守护进程(NVM Daemon)和AP侧IIC驱动组成。
    在CP侧，Nucleus操作系统的NV数据进程(NVM Process)负责产生基带的NV数据，经过设备抽象层(DAI)转发后，基带NV数据被CP侧IIC驱动写入IIC缓存Buffer中。
    在AP侧，对应的IIC驱动将从IIC缓存Buffer中读取到的NV数据上报给AP侧数据接收进程(NVM Driver)。最后，AP侧NVM守护进程收到数据接收进程上报的数据，进行数据包的解析，并将其保存在Flash设备中。
    IIC通信机制包括物理上的IIC连接(IIC TX、RX、CTS、RTS)和公共的函数接口(API)，AP侧和CP侧IIC驱动通过调用这些API即可完成相互通信和数据传输，从而达到两个系统命令和数据交互的目的。
1.2 AP侧软件模块设计
1.2.1 AP侧数据接收流程
    NV数据采用包的形式，数据包的解析由守护进程NVM Daemon来完成。因此底层的驱动程序NVM Driver和IIC Driver不关心数据的具体格式，只关注数据的接收和传送过程[4]。如图2所示，AP侧数据接收流程如下：

    (1)NVM Daemon程序启动成功之后，首先打开NVM驱动设备，若打开成功，则返回设备号，否则打印错误信息并退出。
    (2)NVM Daemon通过read系统调用从NVM Driver获取更新后的NV数据。NVM Driver从IIC通道读取基带更新数据时，会首先判断通道中是否有可读数据，如果没有，则进程进入睡眠，等待唤醒条件到来，唤醒条件为通道中有可读数据；如通道中有可读数据，则直接读取，并将数据送往NVM Daemon。CP侧不定时更新数据，并将数据送往IIC通道。
    (3)从内核空间得到的基带数据是以包的形式封装的，所以接下来NVM Daemon要做的工作就是解析包头，从包中取出有效数据，并且进行NV数据的保存工作，这一步很重要，将在下节详细介绍。
    (4)NVM Daemon将NV数据完整地保存到文件系统后，发送应答ACK包通知CP侧数据保存完成。如果在收包过程中出现异常，则发送ACK包通知CP侧重传。
1.2.2 AP侧数据保存机制
    NV数据以包的形式发送，不同NV数据的数据包可能交错发送，NVM Daemon应能够正确组包，正确地将NV数据保存到文件系统中。NV数据包格式结构体的定义为：
    typedef struct _pkginfo{
        u8 head;        //包头首部
        u8 type；   
//当前包的NV数据类型
        u8 cur_id;   
//当前传输的数据包id
        u8 total_id；  //总数据包个数id
        u32 data_len；//当前包传输的有效数据字节长度
    }pkginfo;
    同时，为了响应AP和CP间的数据收发动作，需要发送ACK包，ACK包格式结构体定义为：
    typedef struct _ackinfo{
        u8 head;  //包头首部字段
        u8 type； //数据类型
        u8 result；//当前包传输结果
        u8 tail； //包尾字段
    }ackinfo;
    ackinfo结构体成员result表示当前包传输结果，返回0表示接收正确，返回1表示接收错误，要求CP侧重传。
    NVM Daemon对NV数据的保存过程如图3所示，以动态NV数据(nv_dynamic)为例，简述如下：
    (1)Daemon程序启动后首先初始化全局变量n，用来统计本次接收过程中总共接收了多少个nv_dynamic类型的NV数据包。

    (2)进入read系统调用，收到数据后，首先解析包头数据，获取数据类型、总包数、当前包数、有效数据长度等，并将这些信息保存到包格式pkginfo结构体中。
    (3)打开nv_dynamic.bin文件，将变量n的值加1；判断是否n>pkginfo->total_id，若大于，则表明接收到的包数已经超过了本次传输的总包数，为异常情况，打印相关的异常信息并且退出，重新调用read读取数据包，否则继续。
    (4)判断是否n=pkginfo->cur_id，如果不等，则说明此时得到的NV数据不是按正常顺序发送到AP端的，此时发送ACK包给CP，要求重传。
    (5)若n=pkginfo->cur_id，接着判断是否n=pkginfo->total_id，如果不等，则直接将NV数据保存到nv_dynamic.bin中，然后进行下一个数据包的接收。
    (6)如果n=pkginfo->total_id，则说明此次接收的是整个传输的最后一个包，将NV数据保存到nv_dynamic.bin文件。然后发送ACK包通知CP整个数据接收完成。将n清0，关闭nv_dynamic.bin文件后退出。
    通过上述流程，可以有效解决NV数据发送过程中的包序错乱、发包重复等问题，保证NV数据的有效保存。
1.3 CP侧NV数据发送流程
    CP侧负责NV数据的产生和发送工作。CP侧NV数据发送具体流程如下：
      (1)内部定时器每20 ms判断基带NV数据是否有更新。
      (2)若NV数据有更新，且长度满足发送条件，则进行包头封装，完成组包工作，不满足则退出。
      (3)NV数据组包完成后，平台无关化接口函数DAI_NV_SEND()调用CP侧IIC驱动发送长度为L的NV数据。
      (4)DAI_NV_SEND()函数调用完成后返回数据发送结果retVal。
      (5)判断retVal是否等于应发送长度L，若是则更新缓存Buffer数据索引后结束，不是则直接结束。
2 扩展的IIC通信机制设计
      IIC通信机制建立在普通IIC通信机制之上，除了一般的IIC数据收发功能外，还扩展了通道注册、通道对象管理、通道中断处理等功能。
      IIC通信机制为AP与CP间的NV数据驱动提供通信和数据传送功能，起到了一个桥梁的作用。其结构设计如图4所示。

    硬件连接与通用IIC通信协议相同，在AP和CP侧有对等的IIC驱动模块。二者有相同的数据结构和循环数据缓冲区管理接口。
    对于外部接口、内部接口，通道对象管理和中断ISR服务等，AP和CP侧需要分别实现。AP和CP外部API接口相同，但具体实现不同。
    IIC通信机制提供给AP和CP的外部API包括：创建数据通道(iic_create_ch)、读通道数据(iic_read_ch)、写通道数据(iic_write_ch)、注册通道中断(iic_register_inthandle)、通道使能(iic_enable_inthandle)等。
3 系统功能测试与结果分析
    系统功能的测试主要包括两个测试点：(1)数据通路是否畅通；(2)NVM Daemon保存的NV数据是否完整有效。
    针对测试点(1)可以在各个数据通路之间采取假数据发送的方式进行测试，例如，在AP侧IIC Driver中用假数代替从基带获取的NV数据送往NVM Driver中，测试两者间通路是否畅通。
    针对测试点(2)将假数据以包的形式发送，分多种类型，分开不按顺序发送，测试NVM Daemon的组包能力。
    在进行数据通路测试的同时，使用一定压力的基带业务，以测试系统的抗压能力[5]。具体测试场景设计如表1所示。

    重复以上测试场景多次后，将AP侧保存的NV数据导出到PC上观察可知，保存的NV数据正确，也没有出现数据包丢失和错乱的情况，符合系统设计的目标，如图5所示。

    本文提出的基带NV数据保存功能模块已经在基于Linux 2.6.32内核的Android 4.1定制版本上实现。
    在AP和CP侧通信机制设计中采用了扩展功能的IIC机制，使AP与CP两个独立系统的通信和数据交换十分方便。同时，在AP侧的NV驱动中使用了中断唤醒的技术，在没有数据传送时，整个数据通道处于睡眠状态，有效地节省了系统资源开销。最后，AP侧的NVM Daemon在组包过程中考虑到了数据包错乱、重复等异常情况，并设计了相应的容错机制。既可保证数据的完整有效性，也能满足实际项目的需求。
    本方案已经被应用于国家重大专项“TD-SCDMA增强型多媒体手机终端的研发和产业化”中。
参考文献
[1] 王海霞.TD/GSM双模手机软件架构的研究与实现[D]. 南京：南京邮电大学，2010.
[2] 朱亚洲.GSM手机软件开发[D].武汉：武汉科技大学，2007.
[3] 周非，亓英杰，刘永康，等.TD-SCDMA终端探测设的DSP设计与实现[J].电子技术应用，2012，38(4)：16-19.
[4] 孟小华，黄宗轩.Android系统非标准设备驱动程序设计[J].微型机与应用，2011，30(14)：7-9.
[5] 李志丹.嵌入式软件调试方法研究[J].计算机与数字工程，2012(7)：157-159.