• 99查看
  • 0回复

[Autosar] AUTOSAR MCAL分析(2):Memory Driver

[复制链接]
匿名  发表于 18-4-2024 22:00:55 |阅读模式

汽车零部件采购、销售通信录       填写你的培训需求,我们帮你找      招募汽车专业培训老师


目录

1. AUTOSAR Memory Driver模块概述

2. Flash Driver

3. EEPROM Driver

4. Flash Test

5. RAM Test

6. 小结


1. AUTOSAR Memory Driver模块概述

之前聊过存储栈,主要是针对NvM以及Fee的讨论,对于Memory Driver里面各模块基本没有介绍。但在我们在讨论功能安全的时候,RAM和Flash的测试是不可能绕开的话题;而恰巧Memory Driver提供这样的功能,如下图所示:
AUTOSAR MCAL分析(2):Memory Driverw1.jpg
Memory Driver包括Flash Driver、Internal EEPROM Driver、RAM Test、Flash Test四个大功能模块,那么今天就简单介绍Flash Driver、Internal EEPROM Driver的功能,重点分析RAM Test和Flash Test的用法。 2. Flash Driver

Flash Driver是能够直接访问到硬件存储器的模块,主要提供存储的读写擦功能,以及对应的读写擦保护功能;但值得注意的是,AUTOSAR定义的Flash Driver只针对数据存储区(DFlash),因此大家在配置NvM的时候都会把FlashDriver挂到目标Fee模块下。而要想实现代码的刷写,那就是另一个范畴了。这也是解释了英飞凌的MCAL里为什么有FlashLoader和Fls_Dmu;突然回想起才参加工作做标定的时候,老板让我用FlsLoader接口,我还比较纳闷,现在回想起来,可能是不想跟我多说,怕我迷糊了。关于Driver其实可讲的不多,主要功能读、写、擦、比较等,这属于纯纯的API调用;Flash Write的调用时序如下:
AUTOSAR MCAL分析(2):Memory Driverw2.jpg
3. EEPROM Driver

那如果MCU里本身就带EEPROM,好办了,不需要用Flash去模拟了,因此EEPROM Driver主要是为EEPROM硬件的读写擦提供接口,其时序如下:
AUTOSAR MCAL分析(2):Memory Driverw3.jpg
可以看到,基本上写和擦都是异步操作,所以JobEndNotifaction就显得格外重要,这也是我们调试NvM的重要手段。4. Flash Test

灵魂一问,为什么需要Flash Test?当程序进行更新后,如何确认程序下到板子里了?很明显,每一家主机厂都有一个刷新完整性、有效性、相关性的检查,那么可不可以沿用到NvM的管理中呢?我想是可以的。因此,Flash Test主要是用于测试下载到板子里的hex是否被篡改或者Flash Cell被破坏。常见的Flash Test的算法有CRC8\16\32、Checksum、ECC等,不过CRC8有几率发生不同数据生成相同的值,目前主机厂多选CRC16。那么Flash Test一般在什么情况下使用呢?根据AUTOSAR SRS描述,可以在MCU初始化后任意时刻使用,那就意味着,这种测试手段可以作为一个周期任务进行调度,因此就有了background mode和foreground mode。

    Background Mode:(FlsTst_MainFunction)周期调用,可以被打断,因此一个测试周期可以被切成多次周期任务;
    AUTOSAR MCAL分析(2):Memory Driverw4.jpg
    Foreground Mode:使用者主动调用API:FlsTst_StartFgnd,不能被打断
5. RAM Test

与Flash Test类似,区别在于RAM Test主要是保证RAM的Cell的寿命,不测RAM内容。它同样分为background test和foreground test。

    Foreground test:由测试环境同步调用Background test:由调度器周期调度
由于RAM的测试分为破坏性和非破坏性测试,用户通常不会去考虑具体实现,只想通过某个寄存器触发某种测试算法,因此大家熟悉又陌生的MTU出现了。它为我们提供了各种各样的RAM测试算法,包括:棋盘算法(Checkboard)、March算法、Galpat/Transparent galpat、Walk path等等;这样用户就只需要去触发、获取结果即可,大大减少了集成难度。值得一提的是,在ISO26262 Part5中以RAM的双点故障为例,列举了不同ASIL等级下的对潜伏故障的诊断覆盖率要求,如下:

AUTOSAR MCAL分析(2):Memory Driverw5.jpg
因此个人认为,在ECU的安全分析里必须包含对于RAM Test的诊断覆盖率的考虑。6.小结

Memory Driver这一章节确实可聊的内容有效,具体主要在实操上,比如CRC8的抗碰撞性较弱导致NvM管理问题,FLash的ECC导致MCU进异常等等,这些处理方式后面再和大伙讨论吧,就酱!周末愉快!

往期回顾:

1.汽车标定精选
汽车标定技术--标定概念详解
汽车标定技术--Bypass的前世今生
万字长文:汽车标定技术--XCP概述

2.AUTOSAR精选
AUTOSAR CryptoStack--CSM Job夹带了哪些私货
AUTOSAR 诊断栈分析(一)
AUTOSAR OS概述(一)

3.汽车网络安全精选
汽车信息安全--MCU启动常用密码算法
汽车网络安全方案需求分析
汽车信息安全--常见车规MCU安全启动方案
车载信息安全场景概述

4.汽车功能安全精选

5.汽车虚拟化精选

    汽车ECU虚拟化技术初探(一)

    汽车ECU虚拟化技术(二)--U2A虚拟化功能

6.杂七杂八

    Flash模拟EEPROM原理浅析

    征途漫漫:汽车MCU的国产替代往事

    车规MCU应用场景及国产替代进展

快速发帖

您需要登录后才可以回帖 登录 | 注册

本版积分规则

QQ|手机版|小黑屋|Archiver|汽车工程师之家 ( 渝ICP备18012993号-1 )

GMT+8, 2-5-2024 03:31 , Processed in 0.242084 second(s), 27 queries .

Powered by Discuz! X3.5

© 2001-2013 Comsenz Inc.