• 764查看
  • 0回复

[Autosar] Autosar工程——Fee移植

[复制链接]


该用户从未签到

发表于 8-3-2024 21:00:15 | 显示全部楼层 |阅读模式

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



    介绍


工程项目中难免会遇到主机厂定义某些DID,需要同时在boot&app软件中可读可写。对于使用FEE(Flash EEPROM Emulation)的控制器来说,可以使用固定的地址去做读写,完成在boot&app的读写工作。不过如果对于较为常用的DID,尤其是在工程的研发测试阶段,对固定地址的dflash的频繁使用,可能会由于flash的寿命影响,带来一些不必要的麻烦。

而使用autosar开发的我们(基于3**),何不尝试一下将FEE模块移植到boot中呢?关于NvM的读写例程,可以参考NvM调试小记——终篇 (qq.com)

NvM调试小记——ReadAll (qq.com)

NvM调试小记——Write (qq.com)

由于NvM、MemIf中也有很多相关的接口和状态机跳转,将Fee从中剥离出来,无疑是最符合boot这种简单、小巧的代码工程了。

2.移植工作

2.1 boot配置FLS模块

如果我们直接使用固定地址的dflash,则只需要与刷写软件用一样的flsloader即可,如果是使用fee,需要EB配置fls模块。

Autosar工程——Fee移植w1.jpg

Autosar工程——Fee移植w2.jpg

需要注意的是,配置的sector需要与app中的isolar配置及FLS配置相同。

2.2 代码移植

Fls模块移植到MCAL

Autosar工程——Fee移植w3.jpg

FEE模块的bsw接口位置

Autosar工程——Fee移植w4.jpg

FEE模块核心代码位置

Autosar工程——Fee移植w5.jpg

我们需要将这两个文件夹下的内容全部移植到boot代码中,不过剥离没有那么简单,

Autosar工程——Fee移植w6.jpg

如上2个文件没法剥离出去,fee还是会用到,也需要拷贝到工程中。

此外,可以把NvM配置更新后的配置文件单独放在一个文件夹中,方便后续更新。

Autosar工程——Fee移植w7.jpg

2.3 Fee_Init()

Autosar工程——Fee移植w8.jpg

Autosar工程——Fee移植w9.jpg

2.4 Fee_Write/Read

Autosar工程——Fee移植w10.jpg

剥离了MenIf的我们,直接调用Fee接口即可,由于是boot,我们不需要在task中分步执行mainfunction,直接while等待写入成功即可。

Autosar工程——Fee移植w11.jpg

Autosar工程——Fee移植w12.jpg

其实这里可以再封装一下的,算了工作的时候再优化吧,这边我连watie都不想改了。

3. 测试验证

Autosar工程——Fee移植w13.jpg

验证的时候发现,fee的接口卡在了这个位置,于是又去翻了一遍代码。最后发现是手写的wait idle函数那边少调用fls的mainfunction。

Autosar工程——Fee移植w14.jpg

Autosar工程——Fee移植w15.jpg

video: https://mp.weixin.qq.com/mp/readtemplate?t=pages/video_player_tmpl&action=mpvideo&auto=0&vid=wxv_3333057699978297345
就可以在app&boot中共同使用nvm读写功能了。

4.开工大吉

?大家开工大吉,新的一年越来越好。


该用户从未签到

发表于 13-3-2025 21:18:00 | 显示全部楼层
针对Autosar工程中的FEE移植项目,为确保高效可靠的运行,对于需同时在Boot和App中读写某些DID的需求,现有固定地址读写的方法在实际操作中确实可能带来问题。因此,考虑将FEE模块移植至Boot层是合理的选择。这种移植能提高系统稳定性并减少不必要的麻烦。针对NV内存(Non-Volatile Memory)的读写例程设计至关重要,它能保证数据的稳定保存。在实施过程中,我们可以参考NvM调试小记的相关内容,结合Autosar系统架构进行适配和优化。在实施移植时,还需关注内存管理、性能优化和错误处理机制等关键环节,确保移植后的系统稳定可靠运行。

[内容由汽车工程师之家人工智能总结,欢迎免费使用,见贴尾]
回复 支持 反对

使用道具 举报



该用户从未签到

发表于 13-3-2025 21:18:00 | 显示全部楼层
关于Autosar工程的FEE移植

在工程项目中,确实存在需要在Boot和App层都能对特定DID进行读写的情况。使用固定地址的FEE方法在某些情况下会对Flash寿命造成影响。将FEE模块移植到Boot层是一个值得考虑的创新方案。

移植后,我们可以利用Boot层的稳定性与早期介入的优势,确保对特定DID的读写操作更为可靠,延长Flash使用寿命。同时,将FEE集成到Boot中,能确保在研发测试阶段更高效地管理存储资源。具体操作应考虑接口的兼容性、代码的模块化和安全性等因素。参考NvM调试小记的资料非常有助于理解实施细节。实施时,需充分评估风险,确保移植的可行性和稳定性。

[内容由汽车工程师之家人工智能总结,欢迎免费使用,见贴尾]
回复 支持 反对

使用道具 举报



该用户从未签到

发表于 13-3-2025 21:18:00 | 显示全部楼层
关于Autosar工程中的FEE移植问题,我理解您提及的主机厂对特定DID在Boot和App中的读写需求。在控制器使用FEE进行读写操作时,固定地址的使用确实可能因频繁操作而影响Flash寿命。考虑到Autosar平台和Flash EEPROM Emulation的特点,将FEE模块移植至Boot层是一个值得尝试的方案。此举能更有效地管理Flash读写操作,提高系统稳定性并延长Flash寿命。具体移植过程中,建议详细分析现有系统架构,确保移植过程不影响其他功能。同时,关于NvM的读写例程,您可以参考提供的链接进行深入研究和实施。实施时需注意确保移植的模块与现有系统兼容,并进行充分测试以确保系统稳定性。

[内容由汽车工程师之家人工智能总结,欢迎免费使用,见贴尾]
回复 支持 反对

使用道具 举报

快速发帖

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

本版积分规则

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

GMT+8, 19-8-2025 05:48 , Processed in 0.332357 second(s), 39 queries .

Powered by Discuz! X3.5

© 2001-2013 Comsenz Inc.