存儲協(xié)議棧的Error流轉過程分析

前言

前面的文章我們詳細分析了NvM，F(xiàn)ee，F(xiàn)ls模塊以及NvM User和NvM的交互，對AUTOSAR架構下的存儲協(xié)議棧應該有了一個比較深入的了解了?；仡^來看，站在NvM使用者的角度來看最關心的是如何使用NvM存儲服務，以及使用過程中出現(xiàn)Error后如何快速定位和分析問題。NvM服務的使用可以參考<>一文，本文就來自低向上的分析AUTOSAR架構下存儲協(xié)議棧的Error處理機制，希望能幫助NvM使用者快速定位和分析問題!

縮略詞：

注：本公眾號文章中使用了一些第三方工具和文檔，若有侵權，請聯(lián)系作者刪除!

參考文檔：

1.AURIXTC3XX_um_part1_v2.0.pdf

2. Specification of Flash EEPROM Emulation

3. Specification of Flash Driver

4.Specification of NVRAM Manager AUTOSAR CP Release 4.3.1

5.AUTOSAR架構下NVM Block連續(xù)寫及Default Value問題分析

6.AUTOSAR架構下NvM模塊詳細分析

7.AUTOSAR架構下Fee詳細分析

8.TC37x芯片F(xiàn)LASH基本概念介紹

9.AUTOSAR架構下Fls詳細分析

10.TC3xx芯片DMU介紹

正文

1.Error自定向上分析

由于從NvM User的存儲服務請求正向自定向下分析Error發(fā)生的條件和流轉十分困難，我們采用自底向上的方法從底層已知Error出發(fā)向上分析Error的流轉，也就是：Fls已知Error àFeeàNvMàNvM User

如下表所示，我們把自底向上分析的結果以表格的形式統(tǒng)計出來，通過這種方式，NvM User就能從JobResult結果查找NvM,Fee,Fls報了什么錯誤，也就能采用對應的應對措施。

Note:

1.該表格僅把NvM最常用的服務（讀，寫，擦除）可能產(chǎn)生的Error統(tǒng)計進去，像NvMCancell這類的不常用服務沒有統(tǒng)計進去。

2.NvM除了底層上報的錯誤外，本身還有很多Error處理機制，比如，調(diào)用底層接口的返回值判斷等，這里錯誤也沒有統(tǒng)計進去，也就是我們僅僅把NvM DMU上報的錯誤統(tǒng)計出來

3.DMU上報的Error的原因，以及對應軟件的處理辦法可以查看數(shù)據(jù)手冊獲得。具體請參考: <<TC3xx芯片DMU介紹>>

2.數(shù)據(jù)INTEGRITY_FAILED錯誤示例

我們把TC3xx芯片的DFlash都擦除掉，然后通過仿真器執(zhí)行重啟。

Fee在處理Read任務時發(fā)現(xiàn)數(shù)據(jù)不一致（Block沒有被寫過），F(xiàn)ee_MainFunction會調(diào)用

NvM_JobErrorNotification通知到上層的NvM模塊。

如果對應的NvM Block配置了Callback函數(shù)，NvM模塊就會調(diào)用該Block的Callback函數(shù)通知到NvM_User，這樣NvM User就能知道當前NvM Block的狀態(tài)。

3. 總結

本文自底向上分析了存儲協(xié)議棧的Error流轉過程，通過本文總結的Error流轉表格，我們可以方便的查找DMU操作出問題的可能原因。但是，對于NvM模塊本身的一些邏輯狀態(tài)上報的Error，這個表格沒有統(tǒng)計，感興趣的朋友可以自己再去研究。

審核編輯：彭菁