CFAR是非常普遍的信号过滤手段，用于提取超过动态阈值的点目标信息。AURIX™ TC3xx单片机的雷达信号处理单元SPU集成了该硬件功能，并且提供两种典型的CFAR算法。（英飞凌技术专家 钱伟喆）

背景介绍

当雷达回波信号功率幅值超过某个阈值时，能被检测到，该阈值不可能是固定的，必须根据周围环境、目标分布反射强弱，杂波噪声干扰等动态变化，而CFAR（constant false alarm rate）就是用于计算动态阈值的典型手段。CFAR直接影响检测概率（probability of detection）【1】，同样的收发机信噪比，较大的CFAR能获得较大的检测概率。

算法实现

由于CFAR使用非常普遍，AURIX™ TC3xx单片机的雷达信号处理单元SPU集成了该硬件功能，并且提供两种典型的CFAR算法，分别是CA-CFAR (cell-averaging CFAR)和GOS-CFAR (generalized order statistic CFAR)。图1是典型CA-CFAR算法结构，摘自Matlab参考文献【1】。SPU还集成了两种算法的子分类，提供更多的检测方法。两种算法各有优缺点，GOS-CFAR在多目标场景性能较优，且其适应性强，参数的微小调整对杂波噪声的滤除影响较小【2】,【3】。

图1. 典型的CA-CFAR（摘自【1】）

为防止带相位信息的各天线信号互相干涉，通常使用不带相位的NCI（non-coherent integer）功率数据进行CFAR处理，这样能准确表征回波信号在各天线上的功率加总。得到的CFAR结果以位(bit)为基本单元，每个位对应NCI矩阵中的一个数据，该数据可能是32位或16位存储格式。NCI矩阵的维度是距离点数乘以多普勒点数。CFAR结果中置一的位，代表该对应NCI的数据被检测出；置零的位(图2中CFAR bit mask未置一的位)，代表该对应NCI的数据未被检测出。

CFAR检测出的结果代表该数据点的功率幅值超过动态阈值，极大可能是来自某目标的反射点。该数据点在每个天线上的信息需要保留，用于下一步的到达角运算。而没超过动态阈值的数据点可能是噪声杂波等，可被删除。CFAR结果可以配合SPU内的Bin rejection单元用于过滤距离-多普勒FFT结果，删除不需要的数据点。图2形象地展示了如何用CFAR 结果过滤距离-多普勒FFT数据。

图2. CFAR结果对距离-多普勒FFT过滤示意图

SPU内的Bin rejection单元可以方便的实现滤波功能。Bin rejection单元可以设定多种灵活的判断条件，比如跟设定的阈值比较，或者设定需要保留的数据向量维度，或者配合CFAR单元设定需要保留的bit mask等等。不满足条件的数据单元可以被清零或删除。

将CFAR结果依次配置到Bin rejection的掩码寄存器中，该寄存器是32位，有64组，总共对应2048（=32x64）个数据。但距离-多普勒FFT数据维度往往较大，而且还要考虑天线维度，所以需要多次配置掩码寄存器，才能过滤全部三维数据。

使用SPU一维CFAR实现二维CFAR

SPU中CFAR硬件实现是一维的，可以沿距离维度，或者多普勒维度，而实际工程应用中往往需要二维CFAR。理论上的二维CFAR实现，是通过被测点与周围一圈点合成计算出的阈值进行比较，计算量较大，尤其使用GOS-CFAR时，因为需要进行排序的运算量是O(n^2)，而一维是O(n)。文献【2】中提出一种分别由距离和多普勒维度CFAR合成的二维CFAR，这种方法有效降低了工程计算量，保持实时性的同时，也能兼顾在噪声环境下的性能。下面将详细介绍如何使用SPU的一维CFAR实现二维CFAR并进行检测。

图3. 二维CFAR、点目标检测和到达角计算流程，以及仿真结果

图3的第一行流程，提供了二维CFAR、点目标检测和到达角计算流程，其中淡蓝色显示的步骤使用SPU实现，而绿色则代表CPU实现的步骤。图3的第二行给出了每个步骤的仿真结果，能直观表现二维CFAR的计算方法。图中前两步是典型的毫米波雷达信号预处理步骤，只是在第一步同时计算了距离维的NCI及GOS-CFAR，等第二步获得多普勒维的CFAR后，就能合成二维结果。

需要注意的是，由于CFAR的存储方式是以一个位元（bit）代表一个数据点，而第二步完成的多普勒结果是距离结果的转置，所以第三步中要实现的位与（bit AND）操作并不简单，需要对两个互为转置的CFAR结果进行位寻址。Tricore™ CPU提供了位操作指令EXTR.U，能够方便地将某个32位字中的某个位元提取出来进行处理【4】。在某些频繁调用，或时间裕量较短的场景，建议使用汇编代码，减少耗时较长的存储器访问次数，使能CPU 指令缓存，并配合编译器的时间优化选项，来降低代码执行时间。举个例子，使用CPU计算512*128维度的二维CFAR，并进行检测提取出128个点目标，同时将提取出的目标数据搬运到连续内存，方便实施第四步骤的角度傅里叶运算，整个图3中第三步骤耗时大约是1ms ，CPU运行主频是300MHz。

总结

CFAR是非常普遍的信号过滤手段，用于提取超过动态阈值的点目标信息。AURIX ™ TC3xx单片机的雷达信号处理单元SPU集成了该硬件功能，并且提供两种典型的CFAR算法。配合SPU中的bin rejection硬件功能，CFAR结果用于过滤距离-多普勒FFT，将可能来自目标的反射点提取出来，进行下一步到达角计算。另外，AURIX™ TC3xx CPU能在较短时间内，将两次SPU的一维CFAR结果，进行位与操作，实现二维CFAR过滤功能，提取目标。

参考文献

【1】 RADAR SYSTEMS ANALYSIS AND DESIGN USING MATLAB’, Bassem R. Mahafza.

【2】Fast Two-Dimensional CFAR Procedure’, Matthias Kronauge, Hermann Rohling, IEEE Trans. on Aerospace and electronic systems Vol. 49, No. 3 July 2013.

【3】Ordered Statistic CFAR Technique – an Overview’, Hermann Rohling, Hamburg University of Technology.

【4】TC1.6_DSP_Optimization_Guide_part1_v1.2’, Infineon Technologies AG.

前言

作者——宋兰中

随着自动化、智能化、网联化的发展及其在汽车中越来越广泛的应用，行业对各个汽车控制单元安全高效的更新数据提出了越来越高的要求。本文作者通过研究汽车领域对ECU更新需求和英飞凌AURIX™ TC3xx系列A/B SWAP功能，以AURIX™ TC3xx千兆以太网为媒介，TC387为载体研究如何实现OTA，并使用英飞凌AURIX™ TC3xx HSM模块有效提高OTA安全，验证了当前热门OTA技术。

什么是OTA

OTA：Over-the-Air Technology，即空中下载技术。

OTA升级：通过OTA方式实现固件或软件的升级。通过无线通信方式实现软件升级，都可以叫OTA升级，比如无线以太网/蓝牙等。

HSM：Hardware Security Module 模块保证刷写的安全可靠。

OTA 系统功能示意如图1所示：

图1 系统功能示意图

几种常见的OTA实现方式比较及优势分析

在进行SOTA更新时，需要把旧的应用程序擦除，把新的应用程序写入。常规的实现方式需要分别开发BootLoader程序和APP程序，MCU上电先运行BootLoader，BootLoader根据情况选择是否跳转到APP和是否进行程序更新。具体来说有以下几种方式：

1、方案一

BootLoader中内置通讯协议栈，更新时，先向MCU发送指令使其跳转到BootLoader，之后先擦除旧APP，在接收新APP的同时直接将其写入Flash的APP运行地址处。该方案的优点是不需要额外的Flash暂存数据，缺点是BootLoader代码更复杂，且如果数据传输发生中断，旧的APP将不能被恢复。该方案更适合Flash容量较小的MCU。

2、方案二

更新程序时，由APP接收更新数据并暂存于Flash，再将APP更新标志位置位；MCU重启时，BootLoader检查更新标志位，如有效，则擦除旧的APP，再将暂存于Flash的新APP数据写入APP运行地址处。该方案的优点是更新数据的接收由APP完成，BootLoader不需要通讯协议栈，代码量更小，且数据传输中断时，原有APP不损坏。缺点是需要额外的Flash空间暂存更新数据。

3、方案三

在Flash中划分出两块相同大小的区域，分为A区和B区，都用来存放APP，但同一时间下只有一个区的APP是有效的，分别设置一个标志位标识其有效性。初始状态下先将APP写入A区，更新的时候，将新的APP写入B区，再把A区的APP擦除，同时更新两个区的有效性标志位状态。BootLoader中判断哪个区的APP有效，就跳转到哪个区运行。这种方法不需要重复拷贝APP数据，但最大的一个缺陷是AB区的APP程序运行地址不同，需要分别编译，从而使得可应用性大大降低。

注释：同时也可以将方案一和方案二相结合，即先采用方案一在BootLoader程序中内置通讯协议栈，更新时，先向MCU发送指令使其跳转到BootLoader。之后接收更新数据的时候，采用方案二的方法，先将数据暂存于Flash，待数据全部接收完成后再擦除旧的APP，写入新的APP。结合方案一和方案二的优点，且能在没有APP或APP损坏的状态下实现程序更新。缺点是BootLoader代码量更大，Flash空间占用更大。

英飞凌AURIX™ TC3xx实现上述SOTA方案拓扑图，如图2 所示：

图2  TC3xx实现SOTA方案常见拓扑图

经过上面的分析，可以看到几种常见方案都有其优缺点。但对于TC3xx这一类的MCU来说，Flash容量通常都很大，足够用，所以通常可以先把APP暂存下来再进行更新，防止数据传输中断导致APP不可用。

同时AURIX™ TC3xx也支持AB SWAP功能。以方案三为例：TC3xx系列如果使能SOTA功能，它的AB Bank Flash物理地址支持两种不同物理地址映射到同一个逻辑地址方式（MCU自动从两种物理地址映射一个虚拟地址），从而使得APP编译时不需要区分AB区，使用相同的逻辑地址即可，从而避免了方案三的硬伤，为我们提供了一种最佳的SOTA方案。接下来，我们将以方案三作为基础，结合实例详细讲解使用英飞凌AURIX™ TC3xx如何实现更优的SOTA。

推荐的OTA实现方式详解

TC3xx的Flash地址映射方式

首先， TC33x和TC33xED不支持AB SWAP功能，其他TC3xx设备都能够通过AB SWAP功能实现SOTA软件更新。

TC3xx 如果使能了AB SWAP功能，Flash大小实际能用的最少减半，TC3xx各系列AB SWAP能力如图3所示。

图3  TC3xx支持AB SWAP功能芯片系列及映射关系

启用SOTA功能时，通过将PFLASH拆分为两A和B两个Bank的能力，其中一组可以读取和执行BANK组，而另一组可以写入新代码。因此虽然单个物理PFLASH Bank中不支持同时读写（RWW）功能，但是通过AB分组支持未使用的BANK组提供安全可靠地对数据执行写入和擦除操作的能力来实现SOTA功能。

举例TC387 AB SWAP特性

为了方便理解英飞凌TC3xx  SOTA 功能，我们以TC387为例进行分析。TC387 PFLASH 10M空间映射关系，使能了AB  SWAP后，实际使用大小为4M，如图4所示：

图4 TC387 PFLASH 映射关系以及可用PFLASH大小

TC387的4M PFlash地址空间无论是A Bank还是B Bank, 对于用户来说，统一为虚拟地址0X80000000-0x803FFFFF 4M地址空间。但是刷写过程中， A bank实际操作物理地址0X80000000-0x803FFFFF 4M空间，B Bank 实际操作物理地址0X8060 0000-0x80AF FFFF 4M空间。

注意，如果使能了AB SWAP功能，TC3xx PFLASH就没有所谓Local PFLASH和Global PFLASH概念，统一理解为Global PFLASH。CPU访问PFLASH由之前的CPUｘ可以通过Local总线访问本PFLASHｘ提高访问速度，变为CPUｘ访问PFLASH只能通过Global总线从而稍微增加了CPU访问PFLASH时间。具体参考图5所示。

图5  SOTA功能使能后只能通过Global总线访问PFLASH

TC3xx的SOTA功能描述

当TC387 SOTA功能激活时，PFLash被划分为两部分A Bank和B Bank，一部分用来存储读取可执行代码（active bank），另一部分可用来写入（inactive bank）即刷写。当APP更新完毕后，两个部分互换，即切换上面两种地址映射方式。在标准模式下使用PF0-1作为active bank，后文称作组A，在Alternate模式下使用PF2-3作为active bank，后文称作组B，就可以实现第二章节所述方案三，且能写入完全相同的APP程序，以相同的地址（逻辑地址）进行运行。

需要注意的是，所有NVM操作都是通过DMU使用PFLASH的物理系统地址执行的，也就是说，NVM操作总是使用标准的地址映射，而不管选择使用哪种地址映射。“NVM操作”是一个术语，用于任何针对FLASH的命令，如程序、擦除等，但不包括读取代码。有关SOTA地址映射的参数在Flash中的UCB（User Configuration Block）中进行配置，在UCB中配置后，只有当下次MCU复位的时候才会更新配置，后文会有详细解释。

TC3xx的SOTA功能实现详解

实现SOTA功能所需关注配置项

英飞凌AURIX™ TC3xx实现SOTA功能主要需要配置如图6所示：

图6 SOTA功能所需关注配置项

1、SOTA模式使能UCB_OTP.PROCONTP.SWAPEN，该参数决定是否开启SOTA模式，在寄存器Tuning Protection Configuration中的SWAPEN进行配置，对应UCB定义如下：

使能AB SWAP功能的UCB定义（UCB32-39是ORIG, 40-47 COPY，建议全部都需要配置，内容可以一样。）如下：

2、配置UCB_SWAP_ORIG/UCB_SWAP_COPY中的UCB_SWAP_ORIG_MARKERLx/UCB_SWAP_COPY_MARKERLx，激活下一次reset需要运行的标准（0x00000055）还是备选（0x000000AA）地址。在寄存器SCU_SWAPCTRL中，可以查看当前激活的是标准还是备选地址。

我们参考下面关于SOTA功能实现的UCB，内容定义：

3、同1描述UCB块，只要使能了SOTA就会自动禁止CPU通过本地总线访问PFLASH功能，红色方框中寄存器值自动为1，即禁止。

SOTA功能实现时SWAP配置及流程

SOTA功能应用时：分系统刚启动时SWAP配置和系统运行时SWAP配置。

系统启动时SWAP配置：

如果SOTA功能使能，那么代码生成的文件至少需要刷进Active Bank。为了信息安全，建议通过UCB_PFLASH设置相应的sectors读写保护。

起始地址需要在UCB_BMHD配置好。

如果当前选择的是标准地址，那么0x00000055H需要写入UCB_SWAP的MARKERL0.SWAP这个域。然后通过把MARKERL0.SWAP的地址写入MARKERH0.ADDR予以确认；同时，将CONFIRMATIONL0.CODE的地址写入CONFIRMATIONH0.ADDR；同时，将57B5327FH写入57B5327FH予以确认。

UCB_ OTP一次性刷写保护以设置所需的OTP、WOP和标定保护。请注意，任何受OTP或WOP保护的扇区都不能使用新映像重新编程。

如果使能了HSM，主核代码和HSM代码需要同时刷入到AB bank的PFLASH S0-S39。

任何受OTP保护的HSM扇区都不能使用新映像重新编程。

最后，由于SWAPEN是在UCB_OTP里面设置的，所以要在下一个重启后SOTA的使能才有效。具体流程，参考图7所示：

图7 系统刚启动时SWAP配置及流程

系统运行时SWAP配置：

下面是程序正在运行时，需要实现软件SWAP到新程序的配置流程。

为了可以正确切换到新程序中，首先新的程序需要刷到对应的非激活的PFLASH Bank，如果非激活的BANK中对应的sectors使能了读写保护，那么刷写之前要先解保护。

切记：由于NVM特性，PFLASH 和DFLASH不能同时操作。因此，在应用程序中运行的EEPROM驱动程序和执行BOOT刷写之间需要进行一些协调。确保要写入的新程序所用的的PFLASH正确无误。例如：如果在PFLASH的SOTA重新编程/擦除期间出现硬故障，可以使用替换逻辑扇区功能（有关更多详细信息，请参阅DMU章节）。此功能允许用户使用“替换逻辑扇区”命令序列将故障逻辑扇区映射到冗余扇区。

由于UCB刷写次数的限制（100次），我们可以通过16 个SWAP配置依次使用来增加SWAP的次数（100*16=1600次）。方式流程如下图8所示：

注意：上一次用过的配置，CONFIRMATIONL(x-1) ) 和CONFIRMATIONH(x-1) 全写为1。

增加SWAP次数，可以通过UCB_SWAP_ORIG/UCB_SWAP_COPY配置如下寄存器：

增加SWAP次数方法流程如图8所示：

图8 增加SWAP次数方法流程

新的配置写好后，选择下一次要激活的程序，等下一次重启即运行新刷写的程序。详细流程如图9所示：

图9 系统运行时SWAP配置

总结

TC3xx  SWAP特性实现OTA功能后，特别注意以下五点：

1. Flash大小实际能用的最少减半，详情参考图3。

2. CPU访问Flash只能通过Global总线从而稍微增加了访问时间，参考图5。详细参数请查相应的数据手册。

3. PFLASH的prefetch功能被禁止，同样会稍微影响整个系统的性能。

4. 功能安全方面：Active Bank 的safety_endinit保护依旧存在，但是Inactive Bank的safety_endinit保护无效。

5. 信息安全方面：Active Bank 和Inactive Bank同样受信息安全相关寄存器的保护。

至此，TC3xx  SWAP特性实现SOTA功能的配置和流程介绍完毕。

关于以太网、HSM为媒介、对SOTA功能研究与实现介绍，请关注后续更新。