认真搞搞汽车MCU

摘要：本文介绍了TC3xx微控制器的外部安全机制(ESM)，重点讲解了FSP(故障信号协议)错误引脚监控机制。文章详细阐述了FSP的三种输出模式选择依据，并通过英飞凌安全方案示例说明模式选择需考虑外部设备需求。以TLF35584电源管理芯片为例，分析了其对ErrorPin的监控设计，包括信号频率检测范围(10-50kHz)和异常处理机制。最后给出了TC3xx SMU寄存器配置伪代码，实现与TLF35584的协同工作。全文为汽车功能安全系统中错误状态监控提供了实用配置指导。

本文介绍了TC3xxSMU芯片中外部看门狗安全机制(ESM)的实现方案。重点阐述了利用TLF35584外部设备实现ESM[HW]:SYS:WATCHDOG_FUNCTION机制的方法，该设备通过窗口型和问答型两类看门狗监测MCU状态：窗口看门狗通过GPIO或SPI喂狗监测时间行为，问答看门狗则通过SPI进行4字节签名验证监测应用逻辑。当喂狗失败超过阈值时，TLF35584会拉低输出信号使系统进入安全状态。这种外部机制有效补充了MCU内部安全机制，为系统级安全提供了保障。

英飞凌针对硬件潜伏故障的自测，提供了四种机制：PBIST、LBIST、MONBIST和MBIST。LBIST和MONBIST我们已经聊过了，今天就快速介绍下MBIST。MBIST，全程Memory Built-in Self Test，用于检测SRAM数据单元的完整性。在26262中，SRAM cell出现错误被认为是潜伏故障，而潜伏故障要求至少一个上电周期要完成一次检测，因此MBIST的使用时机就完全取决于使用者，可以是上电检测、也可以是下电检测、甚至可以在程序运行时检测。

调TC3xx的板子时，最害怕的就是刷UCB，稍不注意板子就上锁。我以为就我这样，结果看好多朋友留言说深有同感，还有一位大神已经锁了4块板子。既然这样，今天就把这些锁芯片的Case汇总，如有不全，欢迎大家补充。

英飞凌TC2xx、TC3xx提供了一种防止寄存器误写入的机制 -- ENDINIT机制。例如，TC3xx SMU里对于各种Alarm行为的配置，一般就是在初始化配置一次，后面就不再动了，ENDINIT机制就可以从硬件层面有些避免寄存器的意外修改。但是如果在运行时要重新配置，就必须先临时解除ENDINIT保护，在有限时间内完成修改。既然是有限时间，自然而然ENDINIT功能的使能和状态就落到了看门狗相关控制寄存器里。最开始接触ENDINIT时确实感觉这个名字取得怪怪的，但理解其作用后，发现还是这个最合适。EN

之前我们已经聊过了ABM和Internal start from Flash，今天就来看看这个Bootstrap Loader具体可以做什么。

总结下来，英飞凌4种硬件BIST机制，我们需要关心的就是LBIST、MBIST、MONBIST，分别关联模块SCU.LBIST、MTU(MBIST)、SMU Core\Standby(MONBIST)，因此搞懂这几个模块的配置关联关系，理清上电启动LBIST、MBIST、MONBIST执行顺序，这样才能做好一颗芯片的功能安全软件。其次，在PBIST状态下、EVR33、EVRC regulator启动之前，VEXT、VEXRSB由次级监控进行检测，一旦发现电压不在范围内，则不会释放CPU。

而从实际alarm输出来看，从上图虚线部分可以看到，例如CPU内部看门狗发生超时，一方面通过ALM_WDTCPUx(x=0~5)进行反映，另一方面会与每个核的对应信号、以及Safety看门狗的超时信号，进行或运算，最终合并为一个ALM_WDTALL。根据文档描述，当出现没有及时喂狗的情况，虽然触发了alarm，但仍需要一段特殊流程来保证MCU行为，特别是在重启前给与软件一小段时间用于保存现场，这是非常关键的。Trap Class Number，作为Trap table的索引，由硬件根据BTV生成。

大家好，我是快乐的肌肉，今天聊聊TC3xx NvM相关硬件细节以及MCAL针对NvM的驱动。

从CPU的视角来看，它始终使用逻辑地址0x80000000（举例）来取指，而芯片硬件根据不同地址映射模式来给物理Bank0、1分配逻辑地址，例如0xAA模式下，分配0x80000000给到PFlash1，这样就能保证运行的是更新后的代码。既然CPU始终是从0x80000000（举例）来取指，那么我们就认为这个地址的Bank为Active的Bank，那么很明显我们要将新的代码放进inactive bank里，在该示例中毫无疑问就应该是0x80300000的逻辑地址。

谈到英飞凌TC3xx的A\B SWAP硬件机制，我们首先要搞懂它的应用场景--OTA。在手机或者电脑上，我们几乎每天都可以收到应用程序的OTA推送，现如今随着智能网联的发展，汽车更像是一台大型的智能移动终端。据统计，当前一台智能网联汽车内部可能部署了多达上百个ECU，代码行数以亿为单位，其复杂程度可想而知。有软件的地方就有bug，那么在汽车这种生命周期长达数十年的终端上，OEM如何去更新和维护汽车里各种ECU的Bug修复、功能迭代和更新？

虽然这个字面意思写的很清楚，但是在链接器实际运行时有什么不一样吗，mau、priority具体表示什么？因此有必要搞一搞其底层原理。编译原理这里就不多谈了，咱们直接从链接器开始走起。

上文TC3xx分析--如何提高系统运行效率(1)-CSDN博客讲解了Tasking中lsl的某些关键定义，简述了Tricore寻址模式，接下来我们继续看，不同memory限定符对于代码的影响。

总共32个通用寄存器，其中16个作为数据寄存器D[0]-D[15]，16个作为地址寄存器A[0]-A[15]， 特别的，A[0]、A[1]、A[8]、A[9]还可以作为系统Global寄存器进行使用，我们再回过头来看看Tasking文件里给的memory限定符，似乎有某种联系，因此接下来我们了解Tricore的寻址模式。再看其他的限定符，分别出现了__a0，__a1等等，很明显讲的是Tricore内核的寻址模式，那么顺着这个思路来捋捋线索，为代码能力和系统优化打基础。那这个__far到底指的是什么呢？

0x80280000重映射到到0xB0040000，定义一个变量在0x80280000，用a去读，开启Overlay功能之后，理论上来说修改0xB0040000的值，a读到的就是新值，结果a读到的还是原来的值，把cache关掉就正常了。开启Overlay后，CPU最开始使用的地址肯定是Flash的地址，例如0x80280000；现在出现DCache数据不一致现象，说明CPU通过DMI去获取数据时，首先取得的是Dache里的数据， 那能不能得出结论，Overlay的地址翻译是在如下位置实现的呢？

上一篇Cache基本原理--以TC3xx为例(1)-CSDN博客，我们聊了Cache基本概念，接下来我们将继续聊Cache映射模式，DCache的数据一致性问题。

为什么要使用Cache？为什么在多核工程里要谨慎使用DCache？Cache里的数据、指令是如何与Memory映射？灵魂三连后，软件工程师应该都会有模糊的回答：大概是为了运行更快，减小系统负载。但是再往下深入思考上面问题，我自己发现对于Cache原理的理解比较欠缺，网上资料纷繁复杂。因此，梳理并总结其原理，为后续系统性能优化打下基础。

限于篇幅，上一篇英飞凌TC3xx 启动逻辑梳理(1)-CSDN博客讲述了SSW里面的一些关键事项，接下来我们来看应用启动代码中的逻辑。

在调TC3xx的板子时，最害怕的就是刷UCB；稍不注意板子就上锁，调试器也连不上了，这里面的逻辑是什么？在设计SafetyLib时，对于芯片启动阶段的功能安全逻辑应该是怎样的？在设计SecurityLib时，对于芯片启动阶段的信息安全应该如何考量？今天就这几个方向来梳理一下TC3xx的启动流程。

上篇TC3xx MTU概述(1)-CSDN博客我们讲解了MTU基本功能和MBIST基本概念，接下来我们继续讲解MTU如何配置NDT算法。

因为在ISO26262中，SRAM的Cell故障被认为是潜伏故障，而在一次驾驶循环内至少得有一次测试用于覆盖潜伏故障，所以使用者有权决定在MCU启动、APP运行和下电这三个阶段任意时刻进行MBIST，因此这种非破坏性测试(NDT)是最为友好。执行MBIST期间，每次发生读访问，SRAM自身的ECC机制会计算此次读出数据的校验码，并检查该校验码是否与存入该数据时计算的校验码一致。值得注意的是，SSH寄存器只能通过MTU->SSH这样的路径进行访问，因此在访问效率上会比直接通过SPB访问寄存器要慢一些。

MCU一般由内核子系统、系统管理子系统、外设子系统、电源子系统等等组成；在设计时每个子系统不可能保证完全没有bug，也不能保证芯片在运行过程中不会出现随机硬件失效（例如ECC，位反转等）；针对系统失效：可以通过持续和严格的过程改进来尽量避免：针对随机硬件失效：可以通过工艺设计预防、引入功能安全机制来探测和缓解；如下：在TC3xx里，每个功能安全机制都会产生一个名叫“SMU alarm”的信号；试想，这么多的alarm如何管理？

在之前文章里，我们简述了TC3xx SMU如何与PMIC TLF35584协同工作，并且主要从datasheet推荐的应用连接分析了功能安全方面的实现机制，如下图：但是仍然遗漏了一个关键点，从ECU级别来看，35584的SS1\2到底可以输出给谁？

上一篇，我们讲了SMU的基本概念，这一节讲TLE35584，并且我们可以通过这颗芯片的设计思路、引脚命名和功能，可以看到，要设计一块好用的车规MCU，光只有MCU还不行，得建好配套，从功能安全、信息安全角度来弥补MCU不能完成的事情。

SMU全称Safety Management Unit，它主要作用是当检测到故障时让MCU进入到一个安全状态，具体来讲，就是MCU内部的硬件安全机制触发报警，该报警统一由SMU处理，并根据软件配置的预定义动作进行响应，从而使MCU进入到安全状态。想要具体了解英飞凌TC3xx的硬件安全机制，可查阅相关《Safety Mannul》。

我们接着上文继续来梳理如何配置LMU的保护机制。

在英飞凌TC3xx中，每个CPU除了有自己的DLMU外，在SRI总线还挂着几块SRAM，这几块SRAM由LMU(Local Memory Unit)进行权限控制。RAM的具体地址(上述9H用于cached访问，Bh用于非cached访问)：LMU除了本身硬件机制(如ecc)外，还提供了16个对SRAM区域的保护功能，这个机制主要是通过Master Tag ID的识别来限制对目标SRAM权限的访问。

要做对标，必然要研究芯片的各种性能，如下是R52和TC3xx的上下文切换性能

当delay timer的计数(ECMnDTMR)和比较寄存器(ECMnDTMCMP)中的值匹配时产生该超时错误输出或ECM reset，因为中断处理中该timer没有停止，这个错误flag对应SSE229，正常情况应该是在比较寄存器中配置的时间内完成中断处理。P1X ECM(Error Control Module)收集从不同的错误源和监控电路发来的错误信号，并通过error pin(ERROROUTZ)对外输出、产生中断并发出ECM reset信号。伪错误注入时的操作与真实错误发生时的操作相同。

在介绍中，对IOM做了概要介绍，下面对IOM FPC PIN脚的输入信号处理、LAM比较原理、ECM event输出原理做一个详细介绍。

顾名思义，就是根据输入信号，通过和给定条件下控制信号进行监测和比较，或与参考信号比较，来检查系统外设输出和外部硬件的是否正确运行。这么说比较抽象，举个例子。可以看到，GTM生成了两路PWM信号，其中一路接到IOM的REF中，另一路接到MON中，二者进行比较，一旦比较出错，发生了某种时间，IOM就会通知SMU，SMU触发相应的behavior进行处理。上述是一个比较简单的IOM实际应用场景。实际上只要是输出的都可以对其进行监控（思考，输入的可以吗？如果可以REF标准从哪里得到）。

通过的简单介绍，我们大概对英飞凌CAN模块的发送接收的message ram、常见的FIFO\Buffer以及中断配置事项有了粗浅认识。接下来我们看看这个模块的其他功能。

1.基本概述英飞凌TC3xx的MCMCAN模块取代了TC2xx系列的MultiCAN；相比于之前的CAN模块，MCMCAN使用的是Bosch提供的M_CAN作为节点，满足ISO 11898-1的要求，支持CAN\CAN FD，最高传输速率可到8Mbit/s；同时还满足ISO 11898-4，基于时间同步事件触发通信方式。

SMU基本概念

IR(Interrupt Router)将外部、内部和软件触发的中断分配给CPU或者DMA

PS：该文要求阅读者具备基本的SMU知识。

英飞凌TC3x sota

简述Overlay和SOTA