基于KeyStone 器件建立魯棒性系統(tǒng)

作者：時間：2016-10-29 來源：網絡

加入技術交流群
- 掃碼加入
  和技術大咖面對面交流
  海量資料庫查詢

摘要

本文引用地址：http://m.butianyuan.cn/article/201610/307368.htm

對于復雜的系統(tǒng)，魯棒性是非常重要的。為了協助客戶建立魯棒性系統(tǒng)，KeyStone 器件提供了多種硬件保護機制，如內存保護、EDC。本文介紹如何利用這些特性在 KeyStone 器件上建立一個魯棒的系統(tǒng)。同時提供了與文檔配套的例程。

1 簡介

如圖1 所示，KeyStone 器件提供了多種協助客戶建立魯棒性應用的特性。

如圖1 所示，在LL2、L1P 及L1D 中集成了內存保護模塊;LL2、SL2 及DDR 控制器中集成了錯誤檢查糾正模塊;L1P 集成了錯誤檢測模塊。

MPAX 和MPU 模塊附在總線上，用于監(jiān)控檢測以避免非法的總線訪問。

每個DSP CorePac 有一個獨立的MPAX 用于監(jiān)控與MSMC 連接的總線。

對于系統(tǒng)中其他的master，根據權限ID 進行分類。對每個權限ID，在MSMC 中集成了2 個MPAX 用于監(jiān)視與該權限ID 相關的訪問。其中一個是SES MPAX 用于保護對DDR3 的訪問，另一個是SMS MPAX 用于保護對SL2 的訪問。關于每個master 對應的權限ID，參考相應的器件手冊。

某些外設的配置端口上添加了MPU，用于保護對該外設配置區(qū)域的非法訪問。但是并非所有的外設都受MPU 的保護，具體參考相應器件手冊中受MPU 保護的外設列表。

每個CorePac 有一個看門狗定時器用于監(jiān)視其活動，如果該核死機，看門狗可以觸發(fā)不可屏蔽中斷或者復位信號。

EMC 可以避免DSP core 訪問沒有映射的的配置空間，XMC 則可以避免DSP core 訪問沒有映射的數據空間。

所有這些功能都由硬件模塊實現，使用這些功能對系統(tǒng)性能基本上沒有影響。使用EDC 會對存儲器的訪問性能稍有影響，但從整個系統(tǒng)層面上看，它幾乎是微不足道的。

在出現問題時，所有這些模塊可以向DSP core 觸發(fā)異常，DSP core 的異常監(jiān)控模塊可以記錄這些狀態(tài)并觸發(fā)異常服務程序執(zhí)行相應的操作。

本文討論這些特性的應用，并給出相關基于寄存器層CSL 實現的例程。代碼使用如下方式定義寄存器指針。

上述各種特性具體描述分布于各自子系統(tǒng)的文檔中，本文最后的參考章節(jié)中列出了所有相關的文檔。在看本文之前，假設客戶已經閱讀了相關屬性對應的文檔，所以本文旨在提供相關的補充信息。

本文適用于KeyStone 1 系列DSP，例程在TCI6614 EVM，C6670 EVM，C6678 EVM 上進行了驗證。對于其他的KeyStone 器件包擴KeyStone 2 系列，基本功能都是一樣的，一些細節(jié)上的些許差異請參閱相應器件手冊。

2 內存保護

文檔“Memory Protection On KeyStone Devices (SPRWIKI9012)”中討論了KeyStone 器件上的內存保護屬性，其中包括其它文檔中沒有的很多有用信息，本節(jié)在其基礎上做一些總結和補充。

表1 總結列出不同內存保護模塊的差異。

系統(tǒng)中有多個master 和slave，位于slave 輸入端口的保護模塊用于阻止來自其他master 對該slave 的非法訪問;位于master 輸出端口的保護模塊用于阻止該master 對所有其他slave 的非法訪問。

每個內存頁、分片或范圍的保護屬性都是可編程的。

2.1 L1 及LL2 內存保護

關于L1 及LL2 內存保護的基本信息參考“TMS320C66x CorePac User Guide(SPUGW0)”中內存保護章節(jié)。

L1 及LL2 內存保護只區(qū)分7 個外部請求ID，但是系統(tǒng)可能有16 個權限ID。默認情況下，系統(tǒng)權限ID 0~5 映射到CorePac AID 0~5，所有其他的權限ID 均映射到AIDx。

CorePac AID 與系統(tǒng)權限ID 之間的映射關系可由EMC 編程配置，具體參考“TMS320C66x CorePac User Guide(SPUGW0)”中“外部存儲控制器(EMC)”章節(jié)。

注意，IDMA 的AID 與其所屬CorePac 的數值一致，EDMA 傳輸的權限ID 與配置并發(fā)起這個傳輸的核的編號一致。

通常L1 被配置為cache，此時所有L1 相關的內存保護屬性寄存器應該清零從而阻止其他master的對L1 的訪問。

CorePac 內部內存保護模塊(保護L1，LL2 及XMC/MPAX)的寄存器被一個鎖保護起來。默認情況下，這些寄存器沒有被鎖住，用戶軟件可以使用自定義的密鑰鎖住這些寄存器，然后，只有用該密鑰進行解鎖后才可以訪問這些寄存器。

2.2 共享內存保護 – MPAX

關于CorePac 共享內存保護的基本信息參考“TMS320C66x CorePac User Guide(SPRUGW0)”中“擴展存儲控制器(XMC)”章節(jié);關于系統(tǒng)中其他master 的共享內存保護基本信息參考“KeyStone Architecture Multicore Shared Memory Controller User Guide (SPRUGW7)”中“內存保護及地址擴展 (MPAX)”章節(jié)。

如下是例程中關于XMC/MPAX 的配置樣例，每一行代表MPAX 中的一個分片配置。

邏輯地址低于0x0C00_0000 的地址訪問不會進入XMC。對地址空間0x0000_0000~0x07FF_FFFF 進行訪問時，在C66x CorePac 內部進行地址解析。這塊地址范圍包括內部及外部配置總線，及L1D、L1P、L2 存儲空間。

對位于0x0C00_0000~0x0FFF_FFFF 區(qū)間的邏輯地址訪問時，會經過L1 cache，并且在讀操作時會經過預取緩存，與該地址范圍對應的內存屬性配置寄存器MAR 是硬件拉死的，不可修改。也就是說對該邏輯地址空間的訪問在進入XMC MPAX 之前不會經過L2 cache，所以這塊邏輯地址空間稱為“快速SL2 RAM 路徑”。

對大于等于0x1000_0000 的邏輯地址訪問會首先經過L2 cache 控制器，然后經過XMC MPAX，這種常規(guī)路徑會增加一個cycle 的時延。

根據上述配置例子，在訪問SL2 時，采用邏輯地址0x0C00_0000 的訪問速率高于使用重映射后的邏輯地址0x1800_0000。但是0x1800_0000 對應的內存屬性寄存器MAR 是可編程的，因此可以配置通過0x1800_0000 訪問的SL2 為non-cacheable 及non-prefetchable。

注意DDR3 起始物理地址為0x8:0000_0000，而0x9:0000_0000 相對起始地址有4GB 的偏移，在大多數系統(tǒng)中這是一個非法的地址。

在真實系統(tǒng)中，應該充分利用好MPAX 的所有片段更好地將存儲空間劃分成盡可能多的小片，并仔細設定各個分片的訪問限定屬性。

不用的地址不應該映射，MPAX 會拒絕對未映射的地址訪問并上報異常事件，從而有助于捕獲軟件錯誤。

當兩個master 通過共享memory 交換數據時，應該確保兩個master 使用的邏輯地址映射到相同的物理地址。

注意EDMA 的權限ID 是繼承于對其配置的CorePac。

警告：

在修改一條 MPAX 表項時，需要確保此時沒有對該表項所覆蓋地址的訪問。在修改之前，需要先將該表項覆蓋地址對應的cache 及預取緩存中的數據進行回寫及失效操作。

對于MPAX 的配置，推薦在程序開始之初且沒有使用任何共享存儲空間之前完成。用于CorePac MPAX 配置的代碼和數據應該放在LL2。

如果要運行時動態(tài)修改一個MPAX 表項，安全的方法是先將新的配置寫到一個未使用的編號高度表項，然后清掉舊的表項。這是由于編號高度表項的優(yōu)先級高于編號低端表項。

在修改MPAX 表項之前需要先執(zhí)行如下操作：

1. 將MPAX 表項對應的存儲空間內容從cache 中剔除出去。即使對于屬性為不可寫的存儲空間，應該使用CACHE_wbInvL2()而非CACHE_inv L2()。

2. 如果對受影響的存儲器空間使能了預取功能，則需要對預取緩存執(zhí)行失效操作。

3. 執(zhí)行“MFENCE”確保回寫及失效操作完成。

CorePac 的MPAX 寄存器受CorePac 的內存保護寄存器鎖保護。SES 及SMS 的MPAX 內存保護屬性寄存器被MSMC 內部分別用于SES 及SMS 的鎖保護。MSMC 內部其他寄存器被MSMC內部用于非MPAX 的鎖保護。

2.3 外設配置端口保護 – MPU

關于MPU 的基本信息參考“KeyStone Architecture Memory Protection Unit User Guide (SPRUGW5)”。

MPU0、MPU1、MPU2 及MPU3 對所有KeyStone 1 器件是相同的。但是對于不同的器件，其附加MPU 的個數，每個MPU 支持的地址范圍表項數，MPU 的默認配置均有所差異。具體可參考相關器件手冊的“內存保護單元(MPU)”章節(jié)。

MPU 與MPAX 的區(qū)別在于，如果訪問地址不在MPU 任何一個地址范圍內，則該地址訪問是允許的;而當該地址與MPAX 中任意表項地址范圍不匹配時，則該地址訪問被拒絕。

注意，如果沒有被MPPA 的設置所拒絕，MPU 單元默認所有的訪問都是許可的。對于一個地址訪問，MPU 首先將訪問的權限ID 與MPPA 寄存器的AID bit 配置進行核對，如果與權限ID 對應的AID bit 為0，則不需要核對地址范圍，該訪問被許可。如MPPA=0 則允許所有的對該空間的訪問，如果要拒絕任意對該空間的訪問則需要將MPPA 配置為0x03FFFC00。L1 及LL2 內存保護的MPPA 設置則有所不同，當MPPA 中AID bit 為0 是拒絕相應的訪問。

當傳輸與MPU 中多個地址范圍匹配時，所有重疊的范圍必須允許其訪問，否則該訪問會被拒絕。最終賦予的訪問權限與所有匹配表項中最低的權限等級一致。如某傳輸與2 個表項匹配，其中一個是RW，另一個是RX，則最終的權限是R。這與MPAX 也是不一樣的。如果一個地址落入多個MPAX 表項，編號高的表項優(yōu)先于編號低的表項。MPAX 只會用編號最高的表項決定權限，并忽略其他匹配的表項。

如下與本文對應例程中一個對MPU1 的配置例子。每行代表MPU 中一個配置范圍。

如上配置知，隊列保護如下：

· 隊列0~2047 只可由AID0~7 進行寫(PUSH)操作;

· 隊列2048~6143 可由AID11 以外所有的AID 進行寫(PUSH)操作;

· 隊列6144~8191 只可由AID8~15(AID11 除外)進行寫(PUSH)操作。

TCI6614 上的MPU6 用于避免ARM 對DDR3 的非法操作。注意，MPU6 是用于低32-bit DDR 物理地址范圍的保護。

注意，為了清除MPU 異常/中斷事件，必須在服務程序的最后向EOI 寄存器寫0.

TCI6614 的MPU 事件與其他KeyStone 器件有所不同。TCI6614 中所有的MPU0~7 事件被合并為一個事件并作為一個系統(tǒng)事件連接到CIC0。由于TCI6614 MPU 事件是電平中斷而非脈沖中斷事件，所有必須首先清除MPU 事件標志，然后才可以清CIC 標志。對于脈沖中斷事件，必須首選清CIC 標志，然后清源標志。

另外，只有在通過PSC 使能BCP 后，才可以訪問TCI6614 中用于BCP 的MPU5。即在訪問TCI6614 中MPU5 寄存器時，如果此時BCP 沒有被使能，則該訪問將觸發(fā)訪問錯誤。

2.4 預留區(qū)域保護

預留區(qū)域(非法地址)被自動保護。對非法地址進行讀操作時將返回垃圾數據，寫操作則會被阻止。對預留區(qū)域的訪問可以產生異常，這有益于捕獲軟件bug。

由于DSP core 的訪問會經過L1D 控制器，所以DSP core 對非法地址的訪問會觸發(fā)L1D 內存保護異常。

DSP core 從非法地址執(zhí)行時將觸發(fā)指令獲取異常。

對于非法寫操作，觸發(fā)的異常取決于相應的目的地址。

DMA 對非法地址訪問時，DMA 模塊會上報總線錯誤。DMA 錯誤事件可以作為異常路由到DSP core。

3 EDC

EDC(Error Detection and Correction)用于存儲器軟錯誤 (Soft Error) 。軟錯誤是一個錯誤的信號或數據，但是并不意味著硬件被破壞。在觀測到一個軟錯誤后，并不意味著系統(tǒng)可靠性會下降。在宇宙飛船中這種類型的錯誤稱為單一事件擾亂。在內存系統(tǒng)中，一個軟錯誤會改變程序中的一條指令或者一個數據值。軟錯誤通常可以通過器件的重啟進行糾正，而硬件錯誤通常不能通過重啟來恢復。軟錯誤不會對系統(tǒng)硬件造成破壞;僅僅會對處理的代碼或數據造成錯誤。產生軟錯誤的原因有：

1. 阿爾法粒子輻射及宇宙射線產生能量中子及質子。發(fā)生的概率取決于器件的地理位置及周圍環(huán)境。通常，一個器件在幾年中才會出現幾次。

2. 軟錯誤也可由隨機噪聲、干擾或信號完整性錯誤引發(fā)，如板載電感應或電容串擾。如果軟錯誤發(fā)送概率高于上述條目1 中的理論值，則應該檢查硬件設計找出其他原因。一個常見的原因是供電電源電壓低于預期，導致器件對噪聲或干擾的影響更敏感。

KeyStone 器件各級memory 中都實現了EDC 機制，下表對不同memory 模塊的實現機制進行了比較。

3.1 L1P 錯誤檢測

關于L1P 及LL2 EDC 基本信息參考“TMS320C66x DSP CorePac User Guide(SPRUGW0)”。

校驗比特生成與核對：校驗比特在進行64-bit 對齊的DMA 寫或L1P cache 緩存時生成。非64-bit對齊的DMA 訪問將使校驗信息失效。在256-bit 對齊的程序讀取或64-bit 對齊的DMA 讀操作時，L1P EDC 邏輯會核對校驗信息。

錯誤檢查設置：器件復位后默認情況下L1P 錯誤檢查特性是關閉的。一旦L1PEDCMD 寄存器中的“EN”bit 被置位，所有L1P memory 中的ED 邏輯被使能。下面是從應用代碼中摘錄的L1P ED 功能使能例子。

注意：要使L1P ED 功能工作正常，必須同時使能L2 EDC。

對L1P cache 訪問時的錯誤處理：對從L1P cache 中獲取程序產生的校驗錯誤，沒有專用的系統(tǒng)事件，然而，錯誤檢測邏輯會發(fā)送一個直接的異常事件給DSP(IERR.IFX 事件)，然后用戶可以使用內部異常事件獲取這個錯誤。L1PEDSTAT 寄存器的PERR bit 會被置位。L1PEDARRD寄存器會記錄包含錯誤bit 的的地址信息。在L1P 錯誤對應的異常處理服務函數中，需要對包含錯誤地址的cache line 進行失效操作。

對DMA 訪問的錯誤處理：對DMA/IDMA 訪問產生的校驗錯誤，對應#113 號系統(tǒng)事件。用戶可以使用這個事件獲取錯誤。L1PEDSTAT 寄存器的DERR 比特位會被置位，并且L1PEDARRD 寄存器會記錄包含錯誤bit 的地址信息。

L1P EDC 功能驗證：通過置位LPEDCMD 寄存器中的SUSP 比特可以暫停L1P EDC 邏輯。使用該特性，可以軟件模仿EDC 錯誤并驗證EDC 功能。與本文對應的例程中提供了驗證L1P EDC功能的代碼，對應函數L1P_ED_test()。

3.2 LL2 錯誤檢查與糾正

校驗比特生成與核對：在對L2 以128 bits 為單元進行內存寫操作時會產生相應的校驗信息。非128-bit 對齊或者小于128 bits 的寫操作會使校驗信息失效。對128-bit 對齊的memory 讀操作時，LL2 EDC 邏輯會核對校驗信息。更多信息參考“TMS320C66x DSP CorePac User Guide(SPRUGW0)”。

錯誤檢查及糾正配置：器件復位后默認情況下LL2 EDC 特性是被關閉的。與某些C64+ DSP 不同的是，KeyStone DSP 不能對內存分塊使能EDC。一旦EDC 使能，EDC 邏輯對整個CorePac L2 內存生效。然而，可以對不同的內存訪問請求者分別使能，如L1D 控制器、L1P 控制器或DMA 控制器。例如，如果用戶只需要對代碼段使用EDC，需要使能下面三個域：

1. 設置L2EDCMD 寄存器中的EN bit 以使能LL2 EDC 邏輯;

2. 設置L2EDCEN 寄存器中的PL2SEN 比特以使能L1 SRAM 的EDC 邏輯對L1P 訪問的檢查;

3. 設置L2EDCEN 寄存器中的PL2CEN 比特以使能L2 cache 的EDC 邏輯對L1P 訪問的檢查。

從關閉到使能狀態(tài)轉變時，LL2 EDC 邏輯不會初始化校驗RAM。因此，在進入使能狀態(tài)后，校驗RAM 中的值是隨機值，需要用戶軟件對其進行初始化，。對L2 EDC 的配置必須遵循“TMS320C66x DSP CorePac User Guide(SPRUGW0)”中闡述的EDC 配置順序。下面是從例程中摘錄的L2 EDC 使能函數參考代碼：

對來自L1D 控制器的訪問錯誤處理：在經過L1D cache 從LL2 中獲取數據時，對所有這些數據會進行錯誤檢查，但是不會有任何的糾正。不管是1-bit 或者是多bit 錯誤，將會通過#117 號系統(tǒng)事件(L2_ED2：不可糾正比特錯誤檢測)上報給DSP core。

對來自L1P 及DMA 控制器的訪問錯誤處理：1-bit 錯誤可以被糾正并通過#116 號系統(tǒng)事件(L2_ED1：可被糾正的比特錯誤)上報。2-bit 錯誤可以被檢測，并通過#117 號系統(tǒng)事件上報該錯誤。

下表列出對于不同存儲器訪問請求者，相應的1-bit 錯誤處理細節(jié)。

錯誤計數器(L2EDCPEC, L2EDNPEC)非常有用，可用于在長時間運行的系統(tǒng)中評估校驗比特錯誤發(fā)生的種類與概率。

下表列出對不同存儲器訪問請求者，相應的2-bit 錯誤處理細節(jié)。

對于大于2 bits 的錯誤，EDC 邏輯可能會檢測并報告為1-bit 或2-bit 錯誤，或者EDC 根本檢測不到該錯誤。所以說，KeyStone 系列EDC 硬件邏輯只能保證檢測2-bit 錯誤或糾正1-bit 錯誤。

通常軟錯誤出現的概率很低，首先出現1-bit 錯誤，在相對長時間后，第二個錯誤bit 也許會產生。由于1-bit 錯誤可以被糾正，而2-bit 錯誤不能被糾正，所以我們應該盡可能在第二個比特錯誤出現前糾正好第一個比特錯誤。

糾正1-bit 錯誤的操作通常稱為“刷新”。為了刷新一塊存儲器，可以使用IDMA，把IDMA 的源地址與目的地址設為相同的地址;字節(jié)長度設置為期望覆蓋的內存塊。地址訪問必須是128-bit 對齊，并且整塊的內存范圍長度必須是128 bits 的整數倍。在IDMA 從LL2 讀取數據時，對于存在有效校驗信息的128-bit 字，EDC 硬件會糾正可能存在于其中的1-bit 錯誤。當IDMA 把數據回寫到相同的地址時，EDC 會對數據產生校驗信息并標識其為有效。

刷新操作通常是在1-bit 錯誤中斷服務函數中進行。但是在1-bit 錯誤發(fā)生之后2-bit 錯誤發(fā)生之前，某些數據也許不會被訪問，在沒有訪問時1-bit 錯誤是不會被自動上報的。為了避免這種情況，應該周期性地刷新整塊存儲器區(qū)間來糾正潛在的1-bit 錯誤。下面是一段LL2 EDC 刷新的代碼例子。

通常，這個函數可以在一個定時中斷中調用。如在一個600 秒周期的定時中斷中調用該函數。

這樣， 1MB 的存儲區(qū)間會每7 天被刷新一遍。

由于刷新操作會與正常的內存操作相競爭，因此會影響正常內存操作的性能。所以刷新操作不能太頻繁，但是必須在2-bit 錯誤產生前完成。在設計時必須權衡考慮。

LL2 EDC 功能驗證：通過設置L2EDCMD 寄存器中的SUSP 比特可以暫停LL2 EDC 邏輯。使用該特性，可以軟件模仿EDC 錯誤并驗證EDC 功能。與本文對應的例程中提供了驗證LL2 EDC 功能的代碼，對應函數LL2_ED_test()。

3.3 SL2 錯誤檢測與糾正

對共享存儲器SL2 的基本信息，參考“KeyStone Architecture Multicore Shared Memory Controller User Guide(SPRUGW7)”。

校驗比特產生與核對：有兩種機制用于MSMC 校驗信息的產生與檢測：

1. 對任意master 發(fā)起的256-bit 內存段的寫操作時，校驗信息會被更新并設置為有效。小于256 bits 的寫操作會使校驗信息失效。當DSP master 發(fā)起256-bit 內存段的的讀操作時，校驗信息會被檢查。

2. MSMC 包含一個后臺錯誤糾正硬件稱作刷新引擎，用于周期刷新存儲器的內容。刷新的周期數可以通過SMEDCC 寄存器中的REFDEL 比特域來配置，每次刷新會讀取并回寫大小是4 個32字節(jié)的塊。在檢測并糾正1-bit 或者檢查到2-bit 錯誤時，刷新引擎還會上報EDC 錯誤。在MSMC用戶手冊中有具體的機制細節(jié)描述。

DSP 復位后，MSMC 硬件會使校驗信息失效，并重新初始化校驗信息。在第一次讀MSMC 存儲器時，軟件必須先檢查SMEDCC 中的PRR 比特(校驗RAM 是否準備好的狀態(tài)信息)。

錯誤檢測與糾正配置：DSP 復位后SL2 EDC 邏輯的刷新引擎被使能，并且會在后臺產生校驗信息。軟件不需要像LL2 EDC 一樣使用DMA 進行存儲器刷新，只需要查詢SMEDCC 寄存器中的PRR(校驗RAM 準備)比特位來確認校驗比特已經產生。為了使能錯誤糾正，SMEDCC 中的ECM比特同樣應該使能。請注意，錯誤糾正邏輯會對從SL2 的讀操作增加1 cycle 的時延(訪問流水線增加了一級)，不過訪問吞吐量并不會降低。

下面是使能MSMC EDC 功能的例程：

錯誤上報機制：MSMC 用戶手冊中有詳細的錯誤上報機制信息，這里總結如下表。

請注意，由刷新引擎上報的錯誤地址是從0 開始的地址偏移，而為非刷新訪問記錄的錯誤地址是器件中從0x0C000000 開始的SL2 地址。

MSMC EDC 功能驗證：可以通過設置SMEDCTST 寄存器中的PFn 比特位(bit0~3)來暫停MSMC EDC 邏輯。SMEDCTST 的地址偏移是0x58。每個SL2 RAM bank 對應PFn 中一個比特(PF0~3 與bank0~3 依次對應)，每個比特可以用于禁止對校驗RAM 的寫操作。這樣可以凍結bank 對應的校驗RAM，因此可以通過故意注入錯誤來破壞SL2 存儲內容與校驗信息的一致性，從而測試檢測糾正邏輯。具體的順序如下：

1. 向測試bank 中的某一個位置寫一個已知值，這樣可以正確地為這個位置初始化一個校驗值。

2. 向SMEDCSTST 對應的PF 比特寫1 以凍結該校驗值。

3. 向上述被寫的位置寫任意字節(jié)來改變該位置的數值，如果檢驗糾正功能則寫一個1-bit 差異的值，如果檢驗檢測功能則寫一個存在2-bit 差異的值。此時該位置的校驗值與其存儲的數值沒有同步。

4. 讀回該位置的值，將會產生所選類型的校驗錯誤。

與本文對應的例程中提供了相應的代碼用于驗證SL2 EDC 功能，對應的函數為SL2_EDC_test()。

4 其它魯棒性特性

4.1 看門狗定時器

對應看門狗定時器的基本知識，請參考“KeyStone Architecture Timer64 User Guide(SPRUGV5)”中“看門狗定時器模式”章節(jié)。

定時器0~(N-1)可用于N 個core 的看門狗。在TCI6614 中定時器8 是ARM 的看門狗定時器。

在看門狗模式下，定時器倒計時到0 時產生一個事件。需要由軟件在倒計時終止前向定時器寫數，然后計數重新開始。如果計數到0，會產生一個定時器事件?？撮T狗定時器事件可以觸發(fā)本核復位、器件復位或者NMI 異常，這可以通過配置相應器件手冊中描述的“復位復用寄存器(RSTMUXx)”來選擇。

使看門狗事件觸發(fā)NMI 異常具有更高的靈活性，在NMI 異常服務函數中，錯誤的原因及某些關鍵的狀態(tài)信息可以被記錄下來，或者上報給上位機來進行故障分析，然后如果它不能自恢復則可以再由軟件來復位器件。

4.2 EDMA 錯誤檢測

關于基本的EDMA CC 錯誤信息可以參考“KeyStone Architecture Enhanced Direct Memory Access(EDMA3)Controller User Guide(SPRUGS5)”中的“錯誤中斷”章節(jié)。

關于基本的EDMA TC 錯誤信息可以參考“KeyStone Architecture Enhanced Direct Memory Access(EDMA3) Controller User Guide(SPRUGS5)”中的“錯誤產生”章節(jié)。

所有的EDMA 錯誤事件可作為異常被路由到 CorePac。

事件丟失錯誤是一種最常見的EDMA CC 錯誤，意味著EDMA 不能按要求及時完成數據的傳輸，或者錯誤的事件觸發(fā)了不應該的EDMA 傳輸。

總線錯誤是一種最常見的EDMA TC 錯誤，通常意味著EDMA 訪問了錯誤的地址(如預留地址或受保護的地址)。

4.3 中斷丟失檢測

中斷丟失或遺漏是實時系統(tǒng)中常見也是常被忽略的問題。中斷丟失檢測是一種用于捕捉這種異常的有效方法。對基本的中斷丟失檢測信息參考“TMS320C66x DSP CorePac User Guide(SPRUGW0)”中“中斷錯誤事件”章節(jié)。

軟件系統(tǒng)應該對路由到DSP core 且有對應軟件服務的中斷使能中斷丟失檢測。在所有中斷配置完畢后可以添加如下代碼使能中斷丟失檢測:

注意，當使能中斷丟失檢測并在CCS/Emulator 下使用斷點或單步進行調測時，由于在仿真停止時中斷沒有被響應，所有此時中斷丟失錯誤上報的概率很高。如果想忽略它，可以在調測時暫時對某些或全部中斷關閉中斷丟失檢測，但是注意不要忘記在正式發(fā)布的程序中重新使能該功能。

5 異常處理

關于異常處理的基本信息參考“TMS320C66x DSP CPU and Instruction Set Reference Guide(SPRUGH7)”中“CPU 異常”一節(jié)。

關于中斷或異常事件路由的基本信息參考“TMS320C66x DSP CorePac User Guide(SPRUGW0)”中“中斷控制器”章節(jié)。

5.1 異常事件路由

所有源自或由CorePac 觸發(fā)的錯誤事件均直接路由到CorePac 的中斷控制器。常被當作異常處理的錯誤如下表所示。

一些其他非致命的錯誤事件，如可糾正的LL2 EDC 錯誤，應該被路由到中斷而非異常。

源自或者由器件中共享模塊觸發(fā)的錯誤事件被路由到CIC。CIC 基本信息參考“KeyStone Architecture Chip Interrupt Controller(CIC) User Guide(SPRUGW4)”。

CIC 事件中常被當作異常處理的事件如下表所示。

每種這樣的異常事件只能路由到一個CorePac。通常所有的這些事件被路由到一個CorePac。下圖描述DSP core 內部控制異常處理的開關。

一旦軟件置位TSR.GEE 及IER.NMIE，不能再由軟件清除，只能在復位后被清除。

TSR.XEN 可以由軟件置位并清除。XEN 可以在進入異常服務函數中由硬件自動清除，并在退出異常服務函數時自動恢復原來的狀態(tài)。

因此，默認情況下，在中斷服務函數中，TSR.GEE=1，IER.NMIE=1 及TSR.XEN=0.

5.2 異常服務函數

異常函數中應該記錄或上報異常原因及相關信息，用于故障分析。

關鍵的記錄信息是NRP。NRP 是異常返回指針，通常用于確定異常觸發(fā)的位置。

實際上，非法操作與NRP 捕獲之間的時延大概在10~100 個DSP Core cycles 之間，具體的時延取決于很多因素，如操作類型，產生異常事件的模塊等等。例如對于向一個被MPU 保護的寄存器執(zhí)行寫操作，其時延包括：從DSP core 到寄存器的寫指令時延;錯誤事件從MPU 到CIC 然后到CorePac 異常模塊的路由時延。因此，當我們獲得NRP 后，應從NRP 指向的位置向后搜索大概10~100cycles 來找有問題的操作。

不過，某些異常NRP 是沒有意義的，例如，對于指令獲取異常及非法操作碼異常。這通常發(fā)生在當程序跳轉到一個非法的地址時，這時NRP 也指向一個非法的地址。我們真正想知道的是在程序跳轉到非法地址前到底發(fā)生了什么，但是這并不能從NRP 推導出來。在這種情況下，寄存器B3，A4，B4，B14 及B15 也許會有所幫助。B3 可能還保存著上次函數調用的返回指針;A4 及B4 也許保存著上次函數調用的參數;B15 是棧指針;B14 是指向某些全局變量的數據指針。更多的細節(jié)可以參考“TMS320C6000 Optimizing Compiler User Guide(SPRUG187)” 中“7.4 函數結構及調用約定”章節(jié)。根據這些信息，我們也許可以推導出在程序跳轉到非法地址前發(fā)生了什么。注意，B3，A4，B4 可能在異常發(fā)生前已經被修改用于保存其它信息，所以它們也許不是有用的。實際上，B3，A4，B4 包含有價值信息的概率還是很高的，所以這些寄存器是值得記錄并分析的。

通用寄存器的值不能用C 代碼記錄，而必須用匯編代碼來記錄。下面的例子是將B3,A4,B4,B14,B15 寄存器記錄在“exception_record”中，然后調用 “Exception_service_routine”。

其它需要記錄的基本信息有：EFR,IERR,NTSR,TSCL/TSCH. EFR 用于判決異常類型：內部、外部或是NMI。對于內部異常，內部異常的原因記錄在IERR。NTSR 記錄異常發(fā)生時的DSP core狀態(tài)。記錄的TSCL/TSCH 用于確定異常發(fā)生前器件運行的時長。

對于外部異常，通過檢查INTC 及CIC 標志寄存器來決定異常原因。對應一個特定的異常，往往有特定的狀態(tài)寄存器可以檢查、記錄或上報。例如對應內存保護異常，需要記錄的關鍵信息是故障地址。參考各模塊的用戶指南了解相關狀態(tài)或標志的更多細節(jié)。

通常，異常服務函數將這些異常信息保存在一個類似如下的數據結構中。

可以在異常服務函數中將這些數據結構中的信息傳遞給主機，或者將其導出來進行錯誤分析。

通常異常服務函數處理的錯誤是致命的，用戶不應該期望從異常服務函數中返回。另外，軟件也不總是能從異常服務函數中安全返回，阻止從異常中安全返回的條件有：

1. 被異常終止的SPLOOPs 不能正確地重新開始。在返回前應該核實NTSR 中的SPLX 比特數值為0.

2. 中斷被堵塞時發(fā)生的異常不能正確地重新開始。在返回前應該核實NTSR 中的IB 比特數值為0.

3. 在不能被安全中斷的代碼處(如一個保護多個賦值的緊湊循環(huán))發(fā)生的異常不能正確地返回。編譯器通常會在代碼中的這些地方關閉中斷;查看NTSR 中的GIE 比特值為1 來驗證滿足這個條件。

4. NRP 不是一個合法的地址。

所以通常異常服務函數以一個while(1)循環(huán)作為結束。

默認情況下在異常服務程序中，TSR.GEE=1,IER.NMIE=1 及TSR.XEN=0.即在異常服務程序中NMI 及內部異常是使能的。

當一個使能的異常發(fā)生在第一個異常服務程序中時，復位向量指向的程序會被執(zhí)行。這時NTSR和NRP 不會發(fā)生改變。TSR 復制到ITSR，此時的PC 復制到IRP。此時為了避免其他外部異常，硬件將TSR 設置為默認的異常處理值，NMIE 中的IER 比特被清零。

通常中斷服務表中的復位向量是跳轉到程序起始位置如_c_int00，這樣，嵌套異常會重啟程序。然而這并非大部分用戶所期望的，我們通常期望的是異常發(fā)生時在異常服務程序執(zhí)行完后結束程序。為了避免嵌套異常導致程序重啟，可以給嵌套異常添加一個額外的異常服務程序，用戶可以修改復位向量跳轉到嵌套異常服務程序。在KeyStone 器件中，加載程序不依賴于復位向量啟動程序，所以修改復位向量不會影響程序的加載。

6 例程

本文相關的例程可以在TCI6614 EVM, C6670 EVM 及C6678 EVM 上跑通。例程可以從以下鏈接下載：

http://www.deyisupport.com/question_answer/dsp_arm/c6000_multicore/f/53/t/47664.aspx

如下為工程目錄結構：