概述

IEC60730的附錄H(H.2.22)中對軟件進行了分類
A類軟件：軟件僅實現產品的功能，不涉及產品的安全控制。B類軟件：軟件的設計要防止電子設備的不安全操作。C類軟件：軟件的設計為了避免某些特殊的危險。本文主要介紹針對其中B類軟件而開發的CLASSB軟件包，安全庫相關代碼基本是獨立于芯片外設IP，軟件包中各型號的example都是基于AT-START開發板，其余暫未支持型號用戶可自行參考移植。

軟件庫總體架構

Class B檢測診斷庫軟件包，基于AT32芯片的V2版本固件庫的文件夾結構，刪除了原固件庫中的demo、middlewares、dsp lib等IEC60730不需要的部分，添加集成IEC60730安全檢測相關代碼。軟件包文件夾總體結構框架如下表：
表1.Class B軟件包文件夾結構STL軟件由芯片外設驅動libraries、class b STL和user application組成，其中class b STL分為兩個主要部分：啟動時檢測和運行時周期檢測，架構整體框圖如下：表2.軟件架構整體框圖

軟件庫設計

本章節介紹STL例程通用的基本原理，并對工程結構以及配置和調試相關信息進行說明。各個開發環境（IAR、Keil、AT32IDE）會有一些差別，也進行了說明。

故障安全處理

當自檢程序檢測到故障時，故障安全處理函數selftest_fail_handle()被調用。at32_selftest_startup.c文件中定義了該函數。該程序的目的是提供自定義故障處理接口并允許用戶立即做出反應。例程內部對該函數沒有特定處理，只輸出調試打印信息，然后執行系統復位。該程序的內容由用戶根據實際應用自行開發，在該函數執行應用必須的操作，以保證應用處于安全的狀態。該函數從程序的不同故障位置進行調用，為判斷故障問題的嚴重程度，用戶可以重新定義該函數，添加一個特定的輸入參數（預先定義好的簡單常量）用于區分不同的故障。

程序RAM分布

為便于描述，將IEC60730必須用到的相關變量命名為Class B變量，用戶應用相關的變量命名為Class A變量。每個Class B變量都使用一對互補值儲存在兩個單獨的RAM區。正常值和補碼值始終放在不相鄰的內存位置。指定具體內存地址的變量定義根據開發編譯環境的不同而寫法不同，具體的實現代碼通過宏定義區分，定義在at32_selftest_startup.c文件。

• IAR通過修改xxx.icf鏈接文件指定固定地址
• Keil通過修改xxx.sct分散加載文件指定固定地址
• AT32 IDE通過修改xxx.ld鏈接文件指定固定地址

每次使用Class B變量數值前，用戶必須確保比較每一個數值對（正常值和補碼值）的完整性。如果發現任何數值對的完整性被損壞，應調用故障安全處理函數。如果變量值變化，需要同步更新存儲位置的補碼值以保持正確的數值對。下圖是STL程序中對于RAM區域使用情況的分布圖：圖1.RAM分布圖

工具特定集成設置

目前STL支持IAR、Keil和AT32 IDE三種IDE，對于不用的IDE，以下事項需注意：

• 修改鏈接腳本文件*.icf（IAR）、*.sct（Keil）、*.ld（AT32 IDE），定義RAM區域的使用分布情況和CRC checksum位置。
• 啟動時的自檢代碼函數selftest_startup_check()，需要進入主程序前，進行處理調用。IAR和AT32 IDE編譯器都是通過修改固件庫內對應的原始啟動文件startup_at32xxx.s，Keil編譯器通過修改$Sub$$main()程序。
• 執行完啟動時的自檢程序后，需要跳轉進入標準C的main主函數，因為不同編譯器方式不同，所以用宏goto_compiler_startup()進行定義。
• 在Keil中調用goto_compiler_startup()時，通過ENTER_MAIN_FLAG宏定義的CRC外設的CDT寄存器值，來判斷是進入啟動自檢程序還是真正的mian主程序。

程序執行流程

Class B軟件包程序檢測內容分為兩個主要部分：啟動時的自檢和運行時的周期自檢，總體流程框圖如下，圖中藍色框圖是相對于原應用程序，執行Class B需添加的部分。圖2.程序流程總框圖啟動時的自檢必須在應用啟動之前執行，調用函數selftest_startup_check()，在進入主循環前先調用函數selftest_runtime_init()做周期自檢初始化配置，然后函數selftest_runtime_check()進行周期自檢。例程中周期性自檢時基是采用1ms的systick中斷，根據變量time_base_flag判斷是否進行檢測，檢測時間間隔由宏定義SYSTICK_10MS_TB決定，用戶可以根據自己應用進行調整，例程中是每10ms執行一次周期自檢。注意：運行時如果自檢程序耗時太長，會影響正常應用程序的進行，可以將自檢流程進行拆分，用systick中斷進行周期性的自檢。理論上，自檢模塊集成添加到應用程序中時，用戶需要提供以下步驟：

• 在用戶程序啟動之前，執行啟動前的初始檢測
• 在用戶程序執行過程中，進行周期性的檢測
• 程序運行時，設置看門狗并及時喂狗防止復位
• 對RAM和Flash在初始階段和運行階段的測試，設置合適的測試區域
• 對于自檢測試發生的錯誤，以及其他hardfault等錯誤，需要進行合理的安全處理

注意：當在啟動時的測試期間，如果程序啟用了調試信息，因為一些外設接口驅動程序可能會用到一些變量，在進行完內存測試后，內存中的內容可能會丟失，所以需要用戶保證恢復這些變量。

啟動時檢測流程

啟動時檢測包括：

• CPU檢測
• 看門狗檢測
• 系統時鐘檢測
• Flash完整性檢測
• RAM功能檢測
• 控制流檢測

下圖是執行啟動時自檢的流程框圖。圖3.啟動時自檢流程結構

一、CPU啟動時檢測

進行CPU寄存器的相關檢測，主要檢查內核標志、寄存器和堆棧指針等是否正確。如果發生錯誤，就會調用故障安全處理函數Selftest_fail_handle()。該部分檢測源代碼是用匯編所寫，在KEIL、IAR以及AT32 IDE等不同的編譯環境下有差異，另外不同CPU內核調用的指令可能也有差異，具體查看代碼。Cortex-M4內核的MCU系列流程框圖如下圖4.cpu啟動時檢測流程

二、看門狗啟動時檢測

驗證看門狗復位功能是否正常，保證后續運行中如果因為程序計數器出現非預期異常情況導致程序跑飛時可以通過看門狗復位恢復。例程中為方便用戶參考，宏定義開啟了wwdt和wdt，實際應用中，根據需求選擇開啟某一個或兩個都開啟。看門狗測試通過判斷復位狀態寄存器的復位標識來判斷是否測試成功，測試流程如下：
A. 判斷wdt reset flag和wwdt reset flag是否都沒有置起，如果是則執行步驟B開始wdt測試，如果不是則跳轉到步驟CB. 配置wdt并使能，然后不喂狗，等待wdt計數器超時而復位回到步驟AC. 判斷wdt reset flag是否置起，并且wwdt reset flag沒有置起，如果是則表明wdt測試通過，執行步驟D開始wwdt測試，如果不是則跳轉到步驟ED. 配置wwdt并使能，然后不喂狗，等待wwdt計數器超時而復位回到步驟AE. 判斷wdt reset flag和wwdt reset flag是否都置起，如果是，則表明wdt和wwdt都測試通過，完成整個測試，如果不是則表明測試過程中有未知異常情況，清除所有reset flag，然后執行軟件復位，回到步驟A重新開始測試。注意：為減少啟動階段的測試時長，啟動時的看門狗超時時間配置為最小值，運行時的超時時間需要根據實際應用喂狗間隔時間配置。注意：測試過程中正常情況會有多次系統復位發生，測試完成后需清除所有的復位標志位。流程框圖如下圖5.看門狗啟動時檢測流程

三、時鐘啟動時檢測

啟動階段的時鐘檢測通過內部低速時鐘源（LICK）和系統時鐘的交叉測量結果來驗證。系統時鐘頻率作為基準頻率，采用外部高速時鐘源（HEXT）或者內部高速時鐘源（HICK）。啟動階段的時鐘檢測盡量使測試時間短，例程中MCU通常是通過專用的定時器TMR（時鐘源為系統時鐘）的某個通道輸入捕獲LICK邊沿頻率，定時器兩次捕獲時數據寄存器計數值之間的差值進行計算得到LICK實際測量值，與芯片數據手冊上列出的LICK規格的典型值進行比較。如果LICK實際測量值在規格范圍的最大和最小范圍內，則測試成功；如果超出了規格范圍值，則測試失敗。圖6.時鐘啟動時檢測流程四、Flash啟動時檢測Flash自檢是存儲器檢測的一部分，程序中測試范圍內的Flash數據用CRC外設的算法計算，將結果值跟編譯時已存儲在Flash指定位置的預先計算好的CRC值進行比較。Flash的CRC值需要在調試或者燒錄階段跟正常應用代碼一起下載到芯片Flash，所以需要在集成開發環境(IDE)編譯生成的HEX或者BIN檔中進行添加，下面分別介紹Keil、IAR、AT32 IDE，如何增加CRC到已編譯的HEX或者BIN文件中，因為Flash CRC運行時周期檢測是每次128字節，所以該處設置的CRC地址范圍需128字節對齊。圖7.Flash啟動時CRC檢測流程注意：CRC計算的Flash范圍需根據整個程序的實際情況進行配置，配置方法在各個IDE上有所不同。KEIL:使用雅特力自己的工具AT32_SelfTest_CRC，將Keil生成的hex檔添加CRC值另存為新的hex檔（也支持bin檔），程序代碼中使用硬件CRC進行計算，描述設置CRC檢測方法如下：1) 將執行文件AT32_SelfTest_CRC.exe和參數文本SelfTest_CRC_Initparam.txt放在keil工程目錄中的同一個文件夾，程序例程是放在crc_tool文件夾中2) 工程中配置選擇對應的文件夾路徑調用AT32_SelfTest_CRC.exe，將KEIL編譯生成的classb_demo.hex文件中的數據進行CRC計算，生成CRC chec_sum，合并到新的classb_demo_checked.hex文件中圖8.keil選項中添加AT32_SelfTest_CRC.exeSelfTest_CRC_Initparam.txt用于配置參數1) input file：原始hex文件的名稱和地址，地址為hex文件相對Kei工程文件的路徑2) output file：添加CRC的hex文件的名稱和地址，地址為hex文件相對Kei工程文件的路徑3) start addr：計算CRC范圍的開始地址4) end addr：計算CRC范圍結束，CRC checksum放置地址5) fill blanks：CRC范圍內原始hex文件的空白位置填充值，可以設置0xFF或者0x00圖9.配置文件內容在下載或者調試中，都需要用最終生成的classb_demo_checked.hex代替原始的classb_demo.hex，所以在Keil配置選項中需添加crc_load.ini文件用于加載新的hex文件IAR：IAR配置選項支持CRC計算，只需要配置好參數，編譯生成的文件就會自動將CRC check_sum值添加到選定Flash計算范圍后面，Checksum參數配置是根據測試MCU型號的硬件CRC外設模塊來確定，目前雅特力不同型號MCU的硬件CRC外設都相同，配置參數如下。圖10.IAP配置CRCAT32 IDE：使用雅特力自己的工具AT32_SelfTest_CRC，將AT32 IDE生成的hex檔添加CRC值另存為新的hex檔（也支持bin檔），程序代碼中使用硬件CRC進行計算，描述設置CRC檢測方法如下：1) 將執行文件AT32_SelfTest_CRC.exe和參數文本SelfTest_CRC_Initparam.txt放在AT32 IDE工程目錄中的同一個文件夾，程序例程是放在crc_tool文件夾中2) 工程中配置選擇對應的文件夾路徑調用AT32_SelfTest_CRC.exe，將AT32 IDE編譯生成的classb_demo.hex文件中的數據進行CRC計算，生成CRC chec_sum，合并到新的classb_demo_checked.hex文件中SelfTest_CRC_Initparam.txt用于配置參數，具體參數內容參考上文中Keil章節的介紹。圖11.AT32 IDE選項中添加AT32_SelfTest_CRC.exe在下載或者調試中，都需要用最終生成的classb_demo_checked.hex代替原始的classb_demo.hex，所以在AT32 IDE配置選項中需配置加載新的hex文件，采用AT-Link調試器時配置如下圖圖12.AT32 IDE debug選項加載新的有CRC checksum的hex檔注意：計算CRC值的Flash范圍根據應用程序的實際大小確定，生成的CRC32 check sum存儲地址需位于Flash空白區，否則可能覆蓋修改到該存儲地址的原始數據從而導致異常。

五、RAM啟動時檢測

RAM自檢是存儲器檢測的一部分，支持和不支持硬件SRAM奇偶校驗功能的型號可以采用不同的方式檢測。對于支持硬件SRAM奇偶校驗功能的型號，如果使用硬件RAM檢測的方式，需使能芯片的硬件RAM校驗功能，該功能的開啟推薦在量產階段同代碼燒錄一起完成。前期開發設計階段，可以通過ICP等工具配置開啟。支持硬件SRAM奇偶校驗功能的型號硬件SRAM校驗功能開啟后，因為上電SRAM數據是隨機值，所以需要在程序啟動階段對SRAM數據進行初始化，對于Keil、IAR、AT32 IDE三種IDE，都是修改.s啟動進行SRAM數據初始化，代碼寫法可能稍有差異，下圖是Keil的.s啟動文件添加SRAM初始化為全0x00的代碼圖13.Keil啟動文件添加SRAM初始化使用硬件SRAM檢測功能，工程代碼有兩處宏定義修改：1) at32_selftest_param.h文件中開啟宏定義HW_RAM_CHECK2) 工程匯編配置中開啟宏定義HW_RAM_CHECK，下面分別是Keil、IAR、AT32 IDE配置截圖圖14.Keil匯編配置開啟HW_RAM_CHECK圖15.IAR匯編配置開啟HW_RAM_CHECK圖16.AT32 IDE匯編配置開啟HW_RAM_CHECK不支持硬件SRAM奇偶校驗功能的型號采用March C算法，用值0x55555555和0xAAAAAAAA逐字交替填充整個RAM并檢查，基本物理單元是4字，下圖單元格內的編號代表測試填充的順序。圖17.RAM基本單元原理RAM采用March C算法測試時分6個步驟，前3個循環按照地址遞增執行，后3個循環按照地址遞減執行。測試步驟如下，如果采用March X算法則省略步驟3和4：1. 全部范圍寫0x55555555，按照地址遞增順序執行2. 檢測是否全部范圍為0x55555555，然后全部范圍寫0xAAAAAAAA，按照地址遞增順序執行3. 檢測是否全部范圍為0xAAAAAAAA，然后全部范圍寫0x55555555，按照地址遞增順序執行4. 檢測是否全部范圍為0x55555555，然后全部范圍寫0xAAAAAAAA，按照地址遞減順序執行5. 檢測是否全部范圍為0xAAAAAAAA，然后全部范圍寫0x55555555，按照地址遞減順序執行6. 檢測是否全部范圍為0x55555555，按照地址遞減順序執行流程框圖如下：圖18.RAM啟動時檢測流程

六、控制流啟動時檢測

控制流檢測也屬于程序計數器檢測的一部分，啟動階段控制流檢測主要分為了兩個節點，因為RAM檢測會導致所有變量被清除，包括定義為控制流檢測相關的變量也會被清除，所以其中一個檢測節點是在RAM檢測之前，通過控制流變量值判斷是否前面所有測試項都正確完成，另外一個節點是在RAM檢測后，主要是運行階段檢測必須操作的流程的配置，比如CRC參考變量初始化、棧溢出pattern設置。對于控制流檢測，基本上每項檢測模塊都可以定義檢測兩層結構，其一是該項檢測模塊流程上是否正確調用(CALLER)，其二是該項檢測模塊是否被正確執行(CALLEE)，檢測方法概述如下：1. 定義兩個變量指示控制流進度，設置初始值ctrl_flow_cnt為0x00000000，ctrl_flow_cnt_inv為0xFFFFFFFF，其初始狀態互為取反的2. 給每項測試模塊定義兩個固定數值分別表示CALLER和CALLEE，并賦予不同的值3. 調用一項檢測模塊前，將ctrl_flow_cn增加CALLER的固定值，標示該模塊已經調用4. 進入對應檢測模塊內部，將ctrl_flow_cn增加CALLEE的固定值，標示該模塊正在執行5. 執行完對應檢測模塊內部，退出前ctrl_flow_cn_inv減少CALLEE的固定值，標示該模塊執行正確6. 完成對應檢測模塊，進入下一項檢測模塊前，將ctrl_flow_cn_inv減少CALLER的固定值，標示該模塊調用正確7. 檢測ctrl_flow_cnt和ctrl_flow_cnt_inv是否仍互為取反的，如果是則表明對應檢測模塊流程上被正確調用，并且該檢測模塊被正確執行

運行時周期檢測初始化

如果啟動時的自檢成功通過，并且標準初始化也完成了，運行時的周期自檢必須在進入主循環之前進行初始化。該部分主要是一些后續自檢會使用到的變量的初始化、中斷中可能用到的數據的同步處理以及看門狗的配置等。

運行時周期檢測流程

運行時的檢測是以systick作為時基，進行周期性的檢測。運行時周期檢測包括：

• 局部CPU內核寄存器檢測
• 系統時鐘運行檢測
• Flash CRC分段檢測
• 堆棧邊界溢出檢測
• 控制流檢測
• 局部RAM自檢(在中斷服務程序中進行）
• 看門狗喂狗

圖19.運行時周期自檢及中斷服務流程結構

一、CPU運行時檢測

CPU運行時周期自檢跟啟動時的自檢類似，只是不檢測內核標志和堆棧指針。圖20.CPU運行時檢測流程

二、系統時鐘運行時檢測

運行時系統時鐘的檢測跟啟動時時鐘檢測原理相同。因為運行時的時鐘檢測會一直循環執行，對某些用戶應用，如果采用定時器捕獲LICK邊沿的方式，可能中斷頻率太高會有影響，所以也可以采用其他方式進行測試，測試原理不變仍然是通過內部低速時鐘源（LICK）和系統時鐘的交叉測量結果來驗證，AT32F403A和AT32F415例程分別采用了兩種不同的測試方法，供用戶參考。

• 在AT32F403A例程中，跟啟動時時鐘檢測方法相同，仍然采用專用的定時器TMR輸入捕獲LICK邊沿頻率的方式進行測試，下圖是采用定時器捕獲LICK測試方式的流程。

圖21.系統時鐘運行時定時器捕獲LICK檢測方式流程

• 在AT32F415的例程中，使用ERTC（時鐘源為LICK）和Systick定時器（時鐘源為系統時鐘）之間交叉測量，ERTC按照數據手冊上LICK典型值作為時鐘源配置秒中斷參數，Systick定時器中斷配置為1毫秒，Systick中斷計數變量tick_cnt_val累加，ERTC秒中斷時獲得Systick的計數變量數值，以此計算得到LICK實際測試值，如果在規格范圍內的最大和最小值之間，測試通過。下圖是采用ERTC獲取Systick變量值測試方式的流程圖。

圖22.系統時鐘運行時ERTC獲取Systick值檢測方式流程

三、Flash CRC運行時檢測

運行時進行Flash CRC的自檢，因為檢測范圍不同耗時不同，如果一次計算檢測全部范圍CRC可能耗時過長，影響正常應用部分的執行，所以可以根據用戶應用程序大小配置分段CRC計算，當計算到最后一段范圍時，再進行CRC值比較，如果不一致則測試失敗。圖23.Flash CRC運行時檢測流程

四、棧邊界運行時溢出檢測

可驗證尋址和數據路徑測試相關，定義特殊固定值的Magic Pattern數組，放置在棧區域最底部地址，通過運行中檢測Magic Pattern數組完整性來判斷棧是否溢出。如果原始Pattern被破壞，則表明棧溢出測試失敗，調用故障安全程序。這一區域根據設備及應用有不同的配置。用戶必須為堆棧定義足夠的區域，并保證pattern正確放置。圖24.堆棧邊界溢出運行時檢測流程

五、RAM運行時檢測

對于不支持硬件SRAM奇偶校驗功能的型號，運行時的RAM自檢是在systick中斷函數中進行的。測試范圍可以根據用戶實際應用需求調整，通過修改代碼中宏定義RUNTIME_RAM_START_ADDR和RUNTIME_RAM_END_ADDR來完成，需注意的是因為測試包括了測試區域前后相鄰的字，所以測試范圍前后要保留適當余量，不要覆蓋臨時保存數據的緩沖塊(buffer block)和溢出芯片RAM范圍。測試流程方法概要描述如下：

• 測試根據systick時基分批次進行，每次測試按照CLASS B部分4個字的區域偏移，為保障耦合故障覆蓋率，每次測試的實際內存塊還包括測試區域前后各1個相鄰字，總共6個字。
• 首先將待測試內存塊(RAM block)的數據存儲到專門用于測試過程中臨時保存數據的緩沖塊(buffer block)
• 然后跟啟動時檢測RAM類似，對測試內存塊(RAM block)采用March C算法測試
• 測試完成后將緩沖塊(buffer block)中保存的數據恢復至測試內存塊(RAM block)

下圖描述了故障耦合的基本原理，圖中數據編號表示操作先后順序。圖25.局部RAM檢測故障耦合加擾模式原理圖26.局部RAM運行時檢測流程

六、看門狗運行時刷新

作為程序計數器檢測的一部分，運行時需要定期喂狗保證系統正常運行，看門狗的刷新部分放置在每次檢測最后部分。注意：運行時的看門狗超時時間，根據用戶程序中刷新喂狗代碼的調用頻率配置，軟件庫源代碼通常采用的是10ms調用一次，所以源代碼中看門狗超時時間配置大于10ms。

注意事項

用戶使用中可能會根據實際情況對CLASSB代碼進行修改，如果改動不符合要求可能導致檢測失敗，本章節列舉了一些常見的注意事項。

一、程序中自定義參數修改

系統主頻根據實際應用修改，函數為selftest_system_clock_config()。其余配置參數定義在at32_selftest_param.h文件以及各自集成開發環境的鏈接或者分散加載文件中，根據實際應用進行修改，下面分別對Keil、IAR、AT32 IDE進行說明。at32_selftest_param.h文件中各個集成開發環境通用部分如下：圖27.通用可修改參數at32_selftest_param.h文件中跟各個集成開發環境相關寫法不一致的部分如下Keil：圖28.Keil可修改參數IAR：圖29.IAR可修改參數AT32 IDE：圖30.AT32 IDE可修改參數

二、Flash CRC檢測范圍設置

因為在Flash CRC運行時檢測是分段進行的，所以設置的總大小范圍需要跟代碼中的分段大小宏定義ROM_ONCE_VERIYF_SIZE成整數倍對齊，否則可能導致最后計算CRC失敗。

三、RAM檢測范圍設置

因為在運行時檢測是每次4個字，所以檢測范圍也需要保證4字對齊，并且因為檢測范圍前后還需2個字的空隙，所以設置范圍時要防止覆蓋到測試RAM時臨時保存數據的緩沖塊(buffer block)或者溢出芯片RAM范圍，導致在RAM測試時程序出錯。

四、編譯器影響

1. 編譯器的優化不僅會導致程序分析調試困難，還可能導致程序出現非預期的結果，所以強烈建議在使用中針對CLASSB部分代碼不要進行優化。2. 當使用不同版本的編譯器時，程序可能有差異。新版CLASS軟件庫對于不同型號MCU的工程，為方便使用不同編譯器版本的用戶移植，可能使用了不同的編譯器版本。

軟件庫說明

一、軟件庫下載各個已支持型號對應的軟件庫源代碼開放于Example Code中，用戶可以通過官網下載，官網中Example Code內容的鏈接地址為https://www.arterytek.com/cn/support/index.jsp?index=2，可搜索關鍵字“60730”快速查找已支持型號MCU的軟件庫，例如AT32F403A的軟件庫文件為“AT32F403A 407 IEC 60730 CLASSB LIB”。二、軟件庫演示下面以SC0127 AT32F403A 407 IEC 60730 CLASSB LIB為例，AT32F403A安全庫的例程運行環境如下：

• KEIL工程為V5.36版本，IAR工程為V8.2版本，AT32 IDE工程為V1.0.09版本。
• Demo運行基于F403A芯片，運行在AT-START-F403A開發板。
• 工程路徑為：utilities\classb_demo

圖31.運行打印信息