1.汽车OTA背景
1.1 汽车为什么需要OTA
谈到英飞凌TC3xx的A\B SWAP硬件机制，我们首先要搞懂它的应用场景--OTA。
在手机或者电脑上，我们几乎每天都可以收到应用程序的OTA推送，现如今随着智能网联的发展，汽车更像是一台大型的智能移动终端。据统计，当前一台智能网联汽车内部可能部署了多达上百个ECU，代码行数以亿为单位，其复杂程度可想而知。
有软件的地方就有bug，那么在汽车这种生命周期长达数十年的终端上，OEM如何去更新和维护汽车里各种ECU的Bug修复、功能迭代和更新？
回想一下，大约在10年以前，汽车还不具备网联功能，手机流量也是贵的可怕，要想使用导航，只能使用车载导航巨头凯立德；而要想升级地图信息只能跑到4S店，还得付费才能更新。
同样，在以前各大车企要升级汽车软件功能或者修复Bug，通常也是要求汽车物理召回，通过线下OBD升级的方式来实现，这样不仅费时费力，还不能保证每台汽车都能升级。
换句话说，在汽车网联化未发展前，OEM将汽车生产并卖出后，基本就失去了售后市场这块价值洼地。
如今，随着网络的飞速发展，OTA被引用到汽车行业。Tesla利用OTA来实现付费升级、软件召回，节省大量成本，在汽车后市场掀起了软件付费的趋势。不难看出，汽车OTA会在今后越来越重要。
1.2 汽车OTA概念
当前汽车一个比较典型的OTA架构如下：
待更新的数据通过OEM OTA云端下发给车端的T-Box，然后经由检验或者透传给网关，网关作为升级主节点来管理控制车内所有的ECU升级，对于具备自更新能力的ECU，它可以直接将数据发送至目标ECU，只需要负责收集反馈更新结果；对于不具备更新能力的ECU，网关还需要充当升级Master阶段，待升级ECU作为Slave，双方通过UDS完成升级。
OTA根据升级内容的不同可以分为SOTA和FOTA：
SOTA(Software over-the-air)多用于座舱系统，例如IVI主题、导航等升级，这部分内容最容易被用户感知
FOTA(Firmware over-the-air)则面向汽车其他ECU的功能升级，包括车身、底盘、智驾等ECU，例如23年汉兰达利用OTA修复了发动机控制器燃油喷射修正程序不完善的问题，这部分升级更为专业，同时涉及到整车网络中多个节点，升级难度也剧增
我们今天主要讨论的就是FOTA。
2. MCU的硬件A\B Swap机制
OEM对于OTA的升级在大方向上有如下需求：
升级时要求无感，即系统在运行时仍可下载程序，零待机时间
针对升级异常处理要求始终有一个可工作的备份程序用于回滚
因此很多芯片厂就从硬件上提供利于OTA升级的机制，例如英飞凌TC3xx A\B SWAP机制，ST SPC58NH92 Hardware flash A/B context swapping机制、NXP S32K3 AB_SWAP机制等等，在该机制下，Flash需要支持RWW(Read While Write)属性，它的空间根据芯片厂的设计分为两个Bank（也有称partitions），这两个物理Bank可以由硬件交替分配一个统一的逻辑地址，在系统运行时，有且只有一个Bank 可以运行代码(称为Actife Bank)，而另一个Bank 则称为inactive Bank，我们就可以在A运行时去刷写新的代码到B Bank上，下次系统重新上电后自动切换到最新的B Bank开始取指运行，从而实现了零待机时间，其原理如下图所示：
上述方案的好处在于我们只需要使用同一个链接文件，编译一个工程即可，这样利于维护。
从上面我们可以知道，芯片硬件A\B SWAP机制通常需要两块相同大小的Flash，所以例如英飞凌TC37x在不使用SWAP机制最高有6MB Flash供大家使用，一旦开启SWAP机制，则容量减半，只能用3MB了，因此在设计时我们需要特别考虑程序大小。
3.TC3xx Swap机制小细节
英飞凌TC3xx提供了硬件SOTA机制，它可以实现代码在一个Flash Bank读取并运行，同时另外一个Bank可以刷写新的代码。以TC37x为例，该系列包含两个PFlash Bank，大小均为3MB，如下图所示：
那么我们来思考如下几个问题：
要使用swap机制，工程编译应该使用什么地址映射方式？
在TC37x系列里，有两个地址映射模式： standard address map和alternate address map，其物理bank和逻辑地址映射关系如下：
而我们在上面提到使用硬件SWAP机制的好处就是只用维护一个工程以及对应链接脚本，因此从逻辑上讲，我们应该就使用standard address map的地址来设计链接文件并编译工程，整体逻辑如下：
从CPU的视角来看，它始终使用逻辑地址0x80000000（举例）来取指，而芯片硬件根据不同地址映射模式来给物理Bank0、1分配逻辑地址，例如0xAA模式下，分配0x80000000给到PFlash1，这样就能保证运行的是更新后的代码。
更新代码应该往哪个地址写数据？
既然CPU始终是从0x80000000（举例）来取指，那么我们就认为这个地址的Bank为Active的Bank，那么很明显我们要将新的代码放进inactive bank里，在该示例中毫无疑问就应该是0x80300000的逻辑地址。
这就出现了问题，一般来说我们通过编译器例如Tasking、Hightec编译出来的文件多数为hex、elf文件，这些文件都是带地址信息的，如下图：
可以看到，第二行记录的起始地址为0x80000020，以此类推。那么我们如果直接用这个hex就覆盖掉了active bank上的内容，这样显然是不行的。
为解决这个问题，Lauterbach、iSystem等等提出了基于调试器级别的方案：
Lauterbach Application Note FLASH Programming TriCore中提到，如果SWAP使能后，Code想要刷进inactive bank，需要使用TRANSlation命令，如下所示：
当然也可以用调试器自带脚本 /demo/tricore/flash/tc3xx-swap.cmmiSystem针对TC3xx的SWAP机制做了优化，用户只需要配置SWAP相应UCB即可完成下载，这个地址偏移等动作对于用户来说是透明的。
Aurix devices have internally more than one program flashes (e.g. PF0, PF1, PF2 flash blocks, etc.). When SOTA is enabled, alternate address mapping is enabled. During download, winIDEA detects which flash memory mapping is selected and it writes data from the download file to correct PFlash block. Download operation is thus transparent to the end user.
那么实际上从整车角度来看，OTA时不能拆盖连接调试器，所以我们只能在Master端进行地址转换，或者我们将待更新文件做成bin文件（不带地址信息），由Master指定刷写的地址。
使能HSM时，代码应该如何部署？
当HSM使能后，TC3xx会给PFlash 0 前40个Sector给到HSM让用户选择，如下图：
既然我们要用A\B SWAP机制，那么inactive bank应该也有相应的镜像，HSM、Host代码部署如下：
图片
同时从手册上描述看，PROCONHSMCX、PROCONHSMCOTP的寄存器设置同样会镜像给到A、B Bank。
除此之外，我们注意到Tricore CPU都有一个直连接口PFI连接到bank，这里用的是逻辑地址，用于加快取指；而当SWAP使能后，逻辑地址没变，物理Bank却变了，所以CPU只能从SRI去取指，这会有一些性能上的损失，如下：
4.小结
上面简单描述了汽车OTA的必要性，引申出了MCU对于OTA的硬件机制实现，分析了关于TC3xx SWAP小细节，后续我们再继续讲解在OTA硬件机制下为什么Flash的RWW属性非常重要，NXP、ST的Flash RWW有哪些区域。 |
楼主
标题置顶
标题高亮
