前言
前面的文章我們?cè)敿?xì)分析了NvM,F(xiàn)ee,F(xiàn)ls模塊以及NvM User和NvM的交互,對(duì)AUTOSAR架構(gòu)下的存儲(chǔ)協(xié)議棧應(yīng)該有了一個(gè)比較深入的了解了。回頭來(lái)看,站在NvM使用者的角度來(lái)看最關(guān)心的是如何使用NvM存儲(chǔ)服務(wù),以及使用過(guò)程中出現(xiàn)Error后如何快速定位和分析問(wèn)題。NvM服務(wù)的使用可以參考<
縮略詞:
簡(jiǎn)寫(xiě) | 全稱 |
DMU | Data Memory Unit |
Fls | Flash |
OPER | Flash Operation Error |
SQER | Command Sequence Error |
EVER | Erase Verify Error |
注:本公眾號(hào)文章中使用了一些第三方工具和文檔,若有侵權(quán),請(qǐng)聯(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架構(gòu)下NVM Block連續(xù)寫(xiě)及Default Value問(wèn)題分析
6.AUTOSAR架構(gòu)下NvM模塊詳細(xì)分析
7.AUTOSAR架構(gòu)下Fee詳細(xì)分析
8.TC37x芯片F(xiàn)LASH基本概念介紹
9.AUTOSAR架構(gòu)下Fls詳細(xì)分析
10.TC3xx芯片DMU介紹
正文
1.Error自定向上分析
由于從NvM User的存儲(chǔ)服務(wù)請(qǐng)求正向自定向下分析Error發(fā)生的條件和流轉(zhuǎn)十分困難,我們采用自底向上的方法從底層已知Error出發(fā)向上分析Error的流轉(zhuǎn),也就是:Fls已知Error àFeeàNvMàNvM User
如下表所示,我們把自底向上分析的結(jié)果以表格的形式統(tǒng)計(jì)出來(lái),通過(guò)這種方式,NvM User就能從JobResult結(jié)果查找NvM,Fee,Fls報(bào)了什么錯(cuò)誤,也就能采用對(duì)應(yīng)的應(yīng)對(duì)措施。
Note:
1.該表格僅把NvM最常用的服務(wù)(讀,寫(xiě),擦除)可能產(chǎn)生的Error統(tǒng)計(jì)進(jìn)去,像NvMCancell這類的不常用服務(wù)沒(méi)有統(tǒng)計(jì)進(jìn)去。
2.NvM除了底層上報(bào)的錯(cuò)誤外,本身還有很多Error處理機(jī)制,比如,調(diào)用底層接口的返回值判斷等,這里錯(cuò)誤也沒(méi)有統(tǒng)計(jì)進(jìn)去,也就是我們僅僅把NvM DMU上報(bào)的錯(cuò)誤統(tǒng)計(jì)出來(lái)
3.DMU上報(bào)的Error的原因,以及對(duì)應(yīng)軟件的處理辦法可以查看數(shù)據(jù)手冊(cè)獲得。具體請(qǐng)參考: <<TC3xx芯片DMU介紹>>
NvM User | NvM | Fee | Fls |
NvM User可以通過(guò)Block Callback獲取NvM Job請(qǐng)求的結(jié)果, 然后根據(jù)結(jié)果執(zhí)行對(duì)應(yīng)的策略 |
NvM調(diào)用NvM Block配置的Callback函數(shù)JobEndCbkExtFunc_pt,傳入的JobResult為NVM_REQ_NOT_OK NvM_CurrentBlockInfo_t.LastResult_t = NVM_REQ_NOT_OK |
Fee在處理Write任務(wù)時(shí)會(huì)調(diào)用Fls的Compare接口對(duì)比寫(xiě)入DFlash的數(shù)據(jù)和RAM緩存的數(shù)據(jù),如果出現(xiàn)錯(cuò)誤,F(xiàn)ee會(huì)調(diào)用NvM_JobErrorNotification Fls調(diào)用Fee_JobErrorNotification, Fee_JobErrorNotication調(diào)用FeeNvmIllegalStateNotification FeeJobResult == MEMIF_BLOCK_FAILED Note: FeeNvmIllegalStateNotification是一個(gè)Callout函數(shù),由User實(shí)現(xiàn) |
Fls執(zhí)行Compare任務(wù)時(shí)發(fā)生錯(cuò)誤,調(diào)用Fee_JobErrorNotification FlsJobResult == MEMIF_BLOCK_INCONSISTENT Note: 寫(xiě)入Flash的數(shù)據(jù)和RAM緩存的數(shù)據(jù)不一致 |
Fls調(diào)用Fee_JobErrorNotification, Fee_JobErrorNotification調(diào)用NvM_JobErrorNotification FeeJobResult == MEMIF_BLOCK_FAILED |
Fls擦寫(xiě)過(guò)程中發(fā)生了超時(shí),調(diào)用Fee_JobErrorNotification FlsJobResult == MEMIF_BLOCK_FAILED Note: 監(jiān)控擦寫(xiě)任務(wù)執(zhí)行的時(shí)間,超時(shí)就會(huì)報(bào)錯(cuò) |
||
Fls擦除過(guò)程中發(fā)生錯(cuò)誤,調(diào)用Fee_JobErrorNotification FlsJobResult == MEMIF_BLOCK_FAILED Note: 發(fā)生OPER, EVER, SQER |
|||
Fls寫(xiě)數(shù)據(jù)過(guò)程發(fā)生錯(cuò)誤,調(diào)用Fee_JobErrorNotification FlsJobResult == MEMIF_BLOCK_FAILED Note: 發(fā)生OPER, PVER, SQER錯(cuò)誤 |
|||
Fls讀數(shù)據(jù)過(guò)程發(fā)生錯(cuò)誤,調(diào)用Fee_JobErrorNotification FlsJobResult == MEMIF_BLOCK_FAILED Note: 開(kāi)啟了ECC_ERROR檢查,如果發(fā)生了ECC錯(cuò)誤就會(huì)報(bào)錯(cuò) |
|||
NvM調(diào)用NvM Block配置的Callback函數(shù)JobEndCbkExtFunc_pt,傳入的JobResult為NVM_REQ_INTEGRITY_FAILED NvM_CurrentBlockInfo_t.LastResult_t = NVM_REQ_INTEGRITY_FAILED |
Fee在處理Read任務(wù)時(shí)發(fā)現(xiàn)數(shù)據(jù)不一致(比如,Block重來(lái)沒(méi)有被寫(xiě)過(guò))就會(huì)調(diào)用NvM_JobErrorNotification FeeJobResult == MEMIF_BLOCK_INCONSISTENT |
||
NvM調(diào)用NvM Block配置的Callback函數(shù)JobEndCbkExtFunc_pt,傳入的JobResult為NVM_REQ_NV_INVALIDATED NvM_CurrentBlockInfo_t.LastResult_t = NVM_REQ_NV_INVALIDATED |
Fee在處理Read任務(wù)時(shí)發(fā)現(xiàn)數(shù)據(jù)是無(wú)效的就會(huì)調(diào)用NvM_JobErrorNotification FeeJobResult == MEMIF_BLOCK_INVALID |
||
NvM調(diào)用NvM Block配置的Callback函數(shù)JobEndCbkExtFunc_pt,傳入的JobResult為NVM_REQ_NOT_OK NvM_CurrentBlockInfo_t.LastResult_t = NVM_REQ_NOT_OK |
Fee在處理寫(xiě)任務(wù)時(shí)發(fā)現(xiàn)寫(xiě)的次數(shù)已經(jīng)超過(guò)該Block配置的最大寫(xiě)次數(shù)了就會(huì)調(diào)用NvM_JobErrorNotification FeeJobResult == MEMIF_BLOCK_FAILED |
2.數(shù)據(jù)INTEGRITY_FAILED錯(cuò)誤示例
我們把TC3xx芯片的DFlash都擦除掉,然后通過(guò)仿真器執(zhí)行重啟。
Fee在處理Read任務(wù)時(shí)發(fā)現(xiàn)數(shù)據(jù)不一致(Block沒(méi)有被寫(xiě)過(guò)),F(xiàn)ee_MainFunction會(huì)調(diào)用
NvM_JobErrorNotification通知到上層的NvM模塊。
如果對(duì)應(yīng)的NvM Block配置了Callback函數(shù),NvM模塊就會(huì)調(diào)用該Block的Callback函數(shù)通知到NvM_User,這樣NvM User就能知道當(dāng)前NvM Block的狀態(tài)。
3. 總結(jié)
本文自底向上分析了存儲(chǔ)協(xié)議棧的Error流轉(zhuǎn)過(guò)程,通過(guò)本文總結(jié)的Error流轉(zhuǎn)表格,我們可以方便的查找DMU操作出問(wèn)題的可能原因。但是,對(duì)于NvM模塊本身的一些邏輯狀態(tài)上報(bào)的Error,這個(gè)表格沒(méi)有統(tǒng)計(jì),感興趣的朋友可以自己再去研究。
審核編輯:彭菁
-
存儲(chǔ)
+關(guān)注
關(guān)注
13文章
4507瀏覽量
87112 -
軟件
+關(guān)注
關(guān)注
69文章
5124瀏覽量
88973 -
NVM
+關(guān)注
關(guān)注
1文章
42瀏覽量
19359 -
協(xié)議棧
+關(guān)注
關(guān)注
2文章
145瀏覽量
34028
原文標(biāo)題:AUTOSAR架構(gòu)下存儲(chǔ)協(xié)議棧Error問(wèn)題自底向上分析
文章出處:【微信號(hào):汽車電子嵌入式,微信公眾號(hào):汽車電子嵌入式】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
LTE協(xié)議棧軟件分析測(cè)試方法
協(xié)議是什么 協(xié)議棧又是什么
電機(jī)實(shí)際的運(yùn)轉(zhuǎn)過(guò)程是怎樣的?
藍(lán)牙協(xié)議棧實(shí)現(xiàn)模式分析
采用精簡(jiǎn)協(xié)議棧的ZigBee網(wǎng)絡(luò)節(jié)點(diǎn)分析

uIP協(xié)議棧介紹
基于TCN實(shí)時(shí)協(xié)議棧過(guò)程數(shù)據(jù)通信研究

TCP/IP協(xié)議棧之路由器簡(jiǎn)要分析
一文詳解棧存儲(chǔ)的結(jié)構(gòu)
tcpip協(xié)議棧是什么?tcpip協(xié)議棧有哪些協(xié)議?tcpip協(xié)議棧中報(bào)文封裝和解封裝過(guò)程

基于ZigBee協(xié)議棧的無(wú)線傳感網(wǎng)絡(luò)的建立過(guò)程

基于BlueZ協(xié)議棧的藍(lán)牙語(yǔ)音接入系統(tǒng)實(shí)現(xiàn)與性能分析

評(píng)論