[AutoSar]BSW_Memory_Stack_003 NVM与APP的显式和隐式同步

老灰╮(╯-╰)╭

已于 2024-04-10 13:13:17 修改

阅读量1.4k

点赞数 31

分类专栏： CP_Autosar 文章标签： Autosar BSW NVM FEE EEPROM

于 2024-04-04 17:03:11 首次发布

本文链接：https://blog.csdn.net/weixin_42447823/article/details/137374081

版权

CP_Autosar 专栏收录该内容

104 篇文章 236 订阅

订阅专栏

本文详细比较了嵌入式系统中NVM（非易失性存储器）与应用程序的两种数据同步方式：隐式同步（共用RAMblock）和显式同步（通过镜像操作）。讨论了各自的写入和读取流程，以及如何避免数据冲突和一致性问题。

摘要由CSDN通过智能技术生成

关键词

嵌入式、C语言、autosar、OS、BSW

平台说明

项目	Value
OS	autosar OS
autosar厂商	vector ， EB
芯片厂商	TI 英飞凌
编程语言	C，C++
编译器	HighTec (GCC)
autosar版本	4.3.1

在这里插入图片描述

>>>>>>>>>>>>>>>>>>>>>>>>>回到总目录<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

缩写	描述
EEPROM	Electrically Erasable Programmable read only memory
NVM	NVRAM Manager
MEMIF	Memory Abstraction Interface
EA	EEPROM Abstraction
EEP	internal/external EEPROM DRIVER
FEE	Flash EEPROM Emulation
FLS	internal/external Flash Driver
FCFS	First come first served

背景

NVM与APP之间的data有implicit和explicit两种同步方式，本文描述了两种方式之间的区别和实现方式。

一、implicit synchronization

如NVM模块介绍和使用说明1.1所描述的，不论什么类型的NVRAM BLOCK 都至少有一个NV block, 一个RAM block and 一个 Administrative block。
在这里插入图片描述 implicit synchronization 的意思就是APP 与NVRAM block 共用一个 RAM block。如下图所示：

在这里插入图片描述

不建议多个APP 访问同一个RAM block，一是因为在写入期间 RAM 的值不允许改动，二是因为多个APP 的读写容易造成冲突和越界。

1.1 Write requests 流程 (NvM_WriteBlock)

1. APP 数据写入RAM 中
1. APP发出the NvM_WriteBlock请求，此后这个RAM block 的控制权移交给NVM模块。
1. 从现在开始，APP不允许修改RAM block，直到通过异步轮询（预留链接位置，后面更新详情）发出请求成功或者失败的返回。这个时候可以读取RAM block。
1. APP可以用轮询的方式周期性检查NvM写入操作是否完成，NvM也可以用回调函数的方式来通知APP操作完成。
1. 当NvM操作完成后，APP才可以重新更改RAM Block中的值。

1.2 Read requests 流程 (NvM_ReadBlock)

1. APP 端提供一个RAM 用于被 NVM 端的RAM block 填充data。
1. APP 发出NvM_ReadBlock 请求，此后这个RAM block 的控制权移交给NVM模块。
1. 从这一步开始，APP不允许读取也不允许写入这个RAM，直到通过异步轮询发出请求成功或者失败的返回。
1. APP可以用轮询的方式周期性检查NvM写入操作是否完成，NvM也可以用回调函数的方式来通知APP操作完成。
1. 当NvM操作完成后，APP才可以重新读取和使用RAM Block中的值。

1.3 Restore default requests 流程 (NvM_RestoreBlockDefaults)

1. APP 端提供一个RAM 用于被 NVM 端的ROM block 填充data。
1. APP 发出NvM_RestoreBlockDefaults请求，此后这个RAM block 的控制权移交给NVM模块。
1. 从这一步开始，APP不允许读取也不允许写入这个RAM，直到通过异步轮询发出请求成功或者失败的返回。
- 1. APP可以用轮询的方式周期性检查NvM写入操作是否完成，NvM也可以用回调函数的方式来通知APP操作完成。
1. 当NvM操作完成后，APP才可以重新读取和使用RAM Block中被ROM提供的值。

1.4 Multi block read requests 流程 (NvM_ReadAll)

EcuM Fixed 状态机在启动的时候调用，用于读取填充所有permanent block。

1. ECU状态管理器可以使用轮询来获取请求的状态，也可以通过回调函数得到通知。
1. 在NvM_ReadAll期间，将在完全处理完NVRAM块后调用单个块回调(如果配置了)。这些回调使RTE能够单独启动每个SW-C。

1.5 Multi block write requests 流程 (NvM_WriteAll)

此请求必须仅在系统关闭时由ECU状态管理器触发。这个请求将所有修改过的永久RAM块的内容写入NV内存。通过仅在ECU关闭期间调用此请求，ECU状态管理器可以确保在操作结束之前，没有SW组件能够修改RAM块中的数据。

1. ECU状态管理器发出NvM_WriteAll请求，该请求将控制权转移给NvM模块。
1. ECU状态管理器可以使用轮询来获取请求的状态，也可以通过回调函数得到通知。

二、explicit synchronization

开启explicit sync 配置
在这里插入图片描述

NvMReadRamBlockFromNvCallback：回调，读取RAM mirror 数据到 RAM block。
NvMWriteRamBlockToNvCallback：回调，将RAM block 数据写到 RAM mirror。
NvMrepeatmirrorOperations:上述两个回调失败时重新执行次数。

如下图所示，explicit 与implicit synchronization 相比，多了一个mirro RAM ，

在这里插入图片描述

显式同步与隐式同步最根本的区别就是，显式同步APP是知道NvM使用RAM Block的起始时间点和结束时间点的，而且这两个时间点是APP自己来控制的，即两个回调函数中的复制操作起始和结束的时间点。APP不需要通过读取NvM的操作状态来判断当前是否可以使用RAM Block。
通过一个互斥量设计，可以让多个APP同时共享一个RAM BLOCK。

注意： 如果在一个APP 请求没有执行完的时候APP2又来一个请求，NVM会合并两个请求，NVM只会处理一次。

2.1 Write requests 流程 (NvM_WriteBlock)

1. APP 数据写入RAM 中。
1. APP发出the NvM_WriteBlock请求。
1. APP可以修改RAM block，直到NvM模块调用NvMWriteRamBlockToNvM 回调。
1. NvM模块调用NvMWriteRamBlockToNvM回调的时候，将RAM block 数据写到 RAM mirror。如果返回E_NOT_OK则表示数据不一致，重新执行直到NvMRepeatMirrorOperations次数。
1. 成功执行NvMWriteRamBlockToNvM后，APP才能重新读写RAM block。
1. APP可以用轮询的方式获取NvM的操作结果，NvM也可以用回调函数的方式通知APP操作结果。

2.2Read requests 流程 (NvM_ReadBlock)

1. APP 端提供一个RAM 用于被 NVM 端的RAM block 填充data。
1. APP发出NvM_ReadBlock请求。
1. APP可以修改RAM block，直到NvM模块调用NvMReadRamBlockFromNvM回调。
1. NvM模块调用NvMReadRamBlockFromNvM 回调的时候，将RAM mirror 数据写到 RAM block 。如果返回E_NOT_OK则表示数据不一致，重新执行直到NvMRepeatMirrorOperations次数。
1. 成功执行NvMReadRamBlockFromNvM 后，APP才能重新使用RAM block 的数据。
1. APP可以用轮询的方式获取NvM的操作结果，NvM也可以用回调函数的方式通知APP操作结果。