說明

本文檔對如何審核一個項目的軟件是否符合量產要求進行闡述；審核目的為確保軟件足夠健全、穩定、易于量產，做出更有品質的產品；該文檔不一定會講清楚每個檢測項，但會盡可能提示你如何掌控調整方向。

本文檔適用于桃芯科技軟件平臺衍生品。

主要檢測項

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 前綴表示二進制。為避免潛在錯誤，應在賦值操作前檢查數字字面量的前綴，確保其符合預期的進制表示，例如：

16低級錯誤檢查

檢查所有switch case 是否有丟失 break而造成邏輯隱患或錯誤的問題。

檢查是否直接判斷一些沒有賦值的局部變量造成邏輯異常的問題。

檢查是否有指針沒有賦值則直接調用的情況，指針用之前需要判斷非空，是否直接分配堆后立即判斷非空。

檢查邏輯上是否可能使用已被釋放的指針，造成hardfault等問題；

檢查是否存在同一個中斷硬件在多個地方注冊回調的情況；

檢查free掉一個指針后是否在其后面添加了設置該指針為NULL的操作，這往往是必要的。

檢查邏輯上是否存在內存泄露的風險，例如：malloc一塊內存后，用完未free，或邏輯缺陷導致無法free，隨著代碼運行，內存申請越來越多，最終導致泄露。尤其內存泄露要很久時間才會發生時，不易察覺，所以，應盡量在設計階段避免。

17時鐘校準

檢查使用內部RC低頻時鐘時，低功耗是否開啟了時鐘校準。

18詞語小介紹

檢查使用數組時，有沒有做最大值判斷，避免數組越界使用。

檢查使用指針時，有沒有做最大值判斷，避免指針空間越界使用。

檢查藍牙回調事件中回調參數的使用是否添加const關鍵：這些參數只能讀，不能寫和修改，意外修改會造成未知異常。