桃芯科技软件审核简介

说明

本文档对如何审核一个项目的软件是否符合量产要求进行阐述；审核目的为确保软件足够健全、稳定、易于量产，做出更有品质的产品；该文档不一定会讲清楚每个检测项，但会尽可能提示你如何掌控调整方向。

本文档适用于桃芯科技软件平台衍生品。

主要检测项

1软件框架检查

桃芯平台的软件包有很多种，typical、exp等类型，还有noos版本，各自有不同的特点，评估该项目是否选择了最优的类型。

关于软件包的版本选择，请参考如下意见：

普通的产品，对功耗，最大连接数等没有严格要求的，选通用的，用typical版本即可。

追求极致功耗，且连接数比较小，则选择mini包类型。

需要连接数尽可能多，则可以考虑extention包。

需要要体验sdk的一些新特性，或者比较全面的api体验，但可以接受一些bug存在，则可采用实验性质的exp版本。

若不考虑内置freertos系统，或、需要更换其它rtos，则可以以上版本对应的noos版本。

2功能符合性检查

不同的产品功能不同，检查项则不同，这里以蓝牙串口模块为例进行说明，供参考：

蓝牙模块的串口协议指令是否与规格书一致；

蓝牙模块的蓝牙协议是否与规格书一致；

其它和基本功能相关的，统统检查是否与设计目标一致。

3异常应对检查

对于不同的产品，满足基本功能是基本要求，对于一些异常情况发生时，也应该有应对措施，常见的：

EMC干扰导致的接口通讯错误，比如UART或者SPI等；

其它环境因素（比如高温低温）造成的宕机问题等；

应对异常，常见的应对措施：

EMC等导致的通讯错误，可通过增加校验来进行判断，来识别帧错误。同时，对帧接收建立超时机制，来避免两个不同帧之间发生重叠导致的判断错误。以AT指令串口蓝牙模组举例，先发送一个异常uart指令（比如缺少帧尾），间隔200ms以上再发送一个正常指令，观察模组是否可以正常接收第二个正常的指令等等。

对于其它因素造成的宕机问题，一般要用看门狗进行保护。

以上场景针对性比较强，不一定适用所有场景，请根据产品类型，制定详细的异常测试计划。

4Flash存储检查

对于桃芯的芯片，需要检查蓝牙配对使用的kv系统的存储的地址是否被合理规划，他们是否与应用程序区冲突；

如果用户自定义数据未使用kv系统，也要确定地址范围是否与应用程序空间发生重叠；

还要考虑两种自定义数据的地址范围是否与OTA备份区的空间发生重叠；

各种flash存储数据是否使用了循环存储（存满一个扇区才擦除一次的策略）来增加擦写次数，进而来提高产品寿命，按照10万次擦写寿命来看，产品平均使用寿命是多少，是否符合产品预期设计；

5任务优先级（rtos版本）检查

各任务优先级设计是否合理，主要检查：

检查蓝牙协议栈controller任务是否已经是最高优先级。（controller的task优先级应该是最高的）

检查蓝牙协议栈host任务优先级。

检查FreeRTOS timer 任务优先级。

检查用户任务的优先级安排是否合理，与蓝牙协议栈任务优先级等platform任务优先级的关系是否合理。

检查有没有其它用户任务优先级与idle task的优先级一样，影响到睡眠的。

任务优先级检查可以参考如下文档设计：3. FreeRTOS任务优先级在桃芯sdk的设置（https://daklqpbddlx.feishu.cn/wiki/Tdytw22uYi0V8okrwUicFrgBnng）

6中断优先级检查

检查各个硬件中断的优先级安排是否合理，比如重要中断是否优先级是否更高。

7线程安全检查

检查应用代码中有没有在任务和中断中共同访问一个变量或内存的情况发生，这种情况会导致共享资源竞争问题，引起低概率问题，需要在设计阶段避免这样的行为，常用的处理手段有：

对于RTOS的系统，可用信号量，队列等消除线程安全问题；

对于没有RTOS的系统，可用汇编转化为原子操作避免竞争；

检查在调用桃芯蓝牙协议栈接口时，是否通过btstack_push_user_msg的方式送到host任务执行，以避免线程安全问题，或可以直接调用线程安全接口。

8看门狗WDT检查

检查看门狗是否打开：

一般测试阶段不能打开，让其发生死机等异常来暴露问题，方便及时发现和修复；

量产阶段要打开，以确保未知问题导致宕机后无法自恢复。

检查看门狗的超时复位时间和喂狗周期设置是否合理：

检查两者时间是否过于接近，导致容易发生意外复位；

检查喂狗时间是否设置过于频繁，导致cpu时间过多被占用，影响其它任务性能；

检查复位超时时间是否设置过大，导致宕机复位不及时；

检查多程序间跳转，看门狗状态如何，如果狗一直开着，两个程序是不是都进行了喂狗操作。

9编译优化等级检查

检查优化等级是否非-O0，如果是，则需要：

检查寄存器设置是否均有volatile关键字，比如给某个寄存器设置为0，再设置为1，如果没有加volatile，则可能被编译器优化为只赋值为1这一个操作，造成硬件执行错误。

检查部分关键状态变量是否添加volatile关键字，以便于获取真实的RAM变量值，避免逻辑错误。

需要注意的是，大量不必要的添加volatile将会导致程序运行变慢。

10日志检查

日志添加/屏蔽：在调试阶段，往往会打开调试日志，在量产阶段，会关闭日志信息，提高性能，减少延时。 需要注意的是：去掉日志，会引起运行时序的变化，可能引入一些逻辑问题，所以，软件去掉日志后需进行充分测试后软件才能释放。

11蓝牙OTA升级

确认项目是否需要OTA功能，如果需要，则需要添加并测试。

检查OTA是采用备份升级策略还是非备份升级策略。

检查是仅升级APP，还是同时升级platform和APP。

检查FLASH空间结构是否被详细规划，整理一个flash分配图，主要问自己：

哪些地方存储协议栈platform.BIN

哪些存储APP，APP备份区是否足够大

是否需要二级boot

用户数据存储在哪里

检查OTA升级过程是否可以正常进行。

检查升级版本号有没有正确添加，每次发布软件是否修改了版本号。

12版本号控制

检查是否添加了版本号。

检查是否只有一个地方可以修改版本号，多个地方修改容易造成遗漏。

检查通过串口等有线接口获得的版本号是否与预设一致。

检查通过蓝牙接口获得的版本号是否与预设一致。

13RAM相关检查

堆、任务栈大小设置是否合理。

对于带RTOS的包：.S类型启动文件中堆的分配值是否为0（sdk例程默认为0），如果为0，特别注意不能使用malloc，可以使用pvPortMalloc和ll_malloc替代。

而对于非RTOS包：.S启动文件的STACK大小是否足够大。

14死循环检测

桃芯平台的异常检测 hardfault、assert、OOM回调中一般是打印调试信息，并设置死循环。在调试阶段没有问题，但是在量产代码中，这里的死循环应改为软件复位或看门狗复位。

检查程序中每一个while(1)和for(;;)死循环，是否增加了超时退出机制。

检查另外一种比较隐藏for死机：比如uint8_t类型和大于256的数据/数据类型进行比较，永远得不到满足，也会造成死循环，要特别注意。

15代码风格检查

检查是否存在随意使用extern方式引用代码，造成代码结构混乱问题，建议使用同名C文件和H文件，以及引用头文件的方式来调用其它文件的函数。

检查整体代码风格是否统一，尽量不要使用多种风格的代码，使得移植性、阅读性较差；

程序中尽量用宏代替一些关键数字标记，方便统一修改，提高维护效率。

在C语言中，进行变量赋值时，需注意数字字面量的前缀表示不同进制：0x 前缀表示十六进制，0 前缀表示八进制，0b 前缀表示二进制。为避免潜在错误，应在赋值操作前检查数字字面量的前缀，确保其符合预期的进制表示，例如：

C #define TEST_MACRO 09 // 错误，第一个字符0代表八进制，八进制不存在数字9，范围是0~7 #define TEST_MACRO 011 // 正确，第一个字符0代表八进制，八进制11代表9 #define TEST_MACRO 9 // 正确，默认10进制数9 #define TEST_MACRO 0x9 // 正确，十六进制数据 #define TEST_MACRO 0b1001 // 正确，二进制，换算成十进制为9

16低级错误检查

检查所有switch case 是否有丢失 break而造成逻辑隐患或错误的问题。

检查是否直接判断一些没有赋值的局部变量造成逻辑异常的问题。

检查是否有指针没有赋值则直接调用的情况，指针用之前需要判断非空，是否直接分配堆后立即判断非空。

检查逻辑上是否可能使用已被释放的指针，造成hardfault等问题；

检查是否存在同一个中断硬件在多个地方注册回调的情况；

检查free掉一个指针后是否在其后面添加了设置该指针为NULL的操作，这往往是必要的。

检查逻辑上是否存在内存泄露的风险，例如：malloc一块内存后，用完未free，或逻辑缺陷导致无法free，随着代码运行，内存申请越来越多，最终导致泄露。尤其内存泄露要很久时间才会发生时，不易察觉，所以，应尽量在设计阶段避免。

17时钟校准

检查使用内部RC低频时钟时，低功耗是否开启了时钟校准。

18词语小介绍

检查使用数组时，有没有做最大值判断，避免数组越界使用。

检查使用指针时，有没有做最大值判断，避免指针空间越界使用。

检查蓝牙回调事件中回调参数的使用是否添加const关键：这些参数只能读，不能写和修改，意外修改会造成未知异常。