专栏名称: 汽车MCU软件设计
汽车MCU软件工程师,分享汽车功能安全、网络安全和AutoSAR
目录
相关文章推荐
优酷情报局  ·  《难哄》为现偶扳回一城 ·  2 天前  
光明日报  ·  大腕云集,只为这场盛典 ·  2 天前  
家有好大事  ·  父亲,你的偏心是我一辈子的痛 ·  3 天前  
家有好大事  ·  父亲,你的偏心是我一辈子的痛 ·  3 天前  
51好读  ›  专栏  ›  汽车MCU软件设计

TC3xx Overlay问题分析:使用Cachable地址出现数据不一致

汽车MCU软件设计  · 公众号  ·  · 2024-05-20 19:00

正文

目录

1.Overlay在Cache地址的问题现象

2. TC1.6.2P的Local Memory

2.1 Local Memory分类

2.2 PMI和DMI

3.问题分析

4.小结


1.Overlay在Cache地址的问题现象

最近有朋友在验证英飞凌TC3xx的Overlay功能时,出现了如下问题:
0x80280000重映射到到0xB0040000,定义一个变量在0x80280000,用a去读,开启Overlay功能之后,理论上来说修改0xB0040000的值,a读到的就是新值,结果a读到的还是原来的值,把cache关掉就正常了。
这里首先想到肯定是Cache数据一致性问题,但是直觉告诉我没有这么简单。再仔细阅读题干并结合手册可以发现:
  • 8H开头的PFlash为Cachable的地址
  • B0040000对应Non-Cache的LMU
问题来了,既然Overlay映射到了Non-Cache的LMU0,那CPU为什么不直接到LMU去读数据?反而还是以前Cache里的数据呢?
带着这个问题,我们梳理一下Tricore的Memory模型,理清思路后发现问题很简单,但加深了对Tricore的认识。

2. TC1.6.2P的Local Memory

2.1 Local Memory分类

根据UserMannul里的描述,TC1.6的本地memory模型如下:
其中包含了:
  • PSPR:Program Scratchpad SRAM,为性能需求的代码提供快速、具有确定CPU访问周期的RAM,其特点是存在PSPR的程序是CPU直接取指,不会被Cache;
  • DSPR:Data Scratchpad SRAM,顾名思义,为数据访问提供高速的RAM
  • PCache:Program Cache,2路组相连的程序Cache
  • DCache:Data Cache,2路组相连的数据Cache
  • DLMU:Distributed LMU memory
  • LPB:Local PFlash Bank ,本地CPU与目标Flash的直连接口
以TC39x为例,我们可以通过其框图看到memory层级:
其中,CPU访问PSPR、PCACHE、DSPR、DCACHE的速度最快,其次是DLMU、PFI,最后是LMU。Cycle数据总结如下:
这里临时有个想法,如果把Data放到PSPR里,其性能如何呢?要解决这个问题,先得搞清楚CPU的Memory接口类型。

2.2 PMI和DMI

TC1.6的CPU模型如下:
它由IFU(Instruction Fetch Unit)、EU(Execution Unit)、GRP构造,其中指令访问使用PMI接口、数据访问使用DMI接口。
PMI:Program Memory Interface向CPU提供指令流
其中,比较特别的是PLB,一个256bits Program Line Buffer。当使用Non-Cacheable地址时时,为加快速度,PLB可作为单个Cache Line使用。同时注意,上半部分PMI与SRI Master和LPB(PFI)接口是一个单向只读接口,而对于下半部分PSPR、CPS是一个双向接口。
DMI:Data Memory Interface向CPU提供数据或者存储由CPU发送的数据,其框图如下:
可以看到,在DMI里没有与PSPR的直接接口,因此,回到临时问题:如果把数据放到PSPR里,CPU去访问数据时使用DMI,那么走的路线应该就与SRI总线有关,如下图:

3.问题分析

回到正题,8H(Cacheable)的PFlash 重映射到BH(Non-Cacheable)的LMU区域时,为什么会出现Cache数据一致性问题?
首先明确Overlay全称叫做Data Access Overlay,针对的是数据访问,意味着地址翻译过程应该由DMI这个接口来实现。
正常情况下,我们获取Cacheable PFlash(8H)里的数据,应该走如下路径:
如果Cache命中,就不要到memory去拿数据了,提高了访问速度;
修改Noncache LMU里的数据,走如下紫色路径:
现在出现DCache数据不一致现象,说明CPU通过DMI去获取数据时,首先取得的是Dache里的数据, 那能不能得出结论,Overlay的地址翻译是在如下位置实现的呢?
理由如下:
当我直接修改Non-Cache LMU里数据的值时,走路线1 :
值得注意的是,因为使用的Non-Cache的地址,所以直接写到LMU里,在没有使用DSYNC指令时,数据不会同步到DCache中;
验证Overlay功能时,肯定是使用Flash地址去获取修改后(Ram)的数据(Flash 映射到 RAM),走路线2:

开启Overlay后,CPU最开始使用的地址肯定是Flash的地址,例如0x80280000;由于该地址Cacheable,因此首先到DCache里找数据,一旦Cache Hit,那使用的就是老的数据。至于这个一致性问题是否必现,还得分析自己写的代码的空间局部性和时间局部性。
怎么解决这个问题呢?直接到目标地址去拿数据是最稳妥的。
如下图路线3:
按这种思路,可以有如下解决方案:
1)使用Non-cache地址来实现Overlay;
2)如果必须要求使用Cache地址,也好办。
在OVCCON寄存器里提供了DCache清除机制,如下图:
每次读数据之前清下DMI里的Cache Line,每次写数据时同步一下(Write Back Cache)。

4.小结

由于Cache对软件开发者的透明性,在涉及到这个问题时,最好还是使用Non-Cache地址。如果真要使用Cacheable地址,需要仔细验证手册里提供的各种数据同步机制。

往期回顾:

1.汽车标定精选

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

2.AUTOSAR 精选

AUTOSAR CryptoStack--CSM Job夹带了哪些私货






请到「今天看啥」查看全文