简介针对TI AWR2243毫米波雷达传感器的PROCESSOR_SDK代码修改包面向基于这款77GHz雷达芯片做汽车安全、工业自动化与智能交通开发的嵌入式工程师解决了SDK默认参数难以发挥芯片最佳性能以及设备联网时无法固定IP地址的配置难题。整个资源非常精简共5个文件压缩后约21KB包含3个C源码文件、1个cfg网络配置文件和1个txt说明文档典型源码配置文档结构便于快速查阅和直接比对。当前已有1368人学习下载。改动内容围绕雷达工作参数发射频率、采样率、探测范围、分辨率等的适配以及RTOS静态IP地址支持的实现展开通过对照C代码与NDK配置可清晰理解每一项修改的作用与具体操作方法配套的Readme也给出了背景和注意事项。对于希望基于AWR2243做二次开发或需要掌握TI毫米波雷达SDK网络配置的工程师而言这份小体积代码包具有较强的参考与复用价值。 干过TI毫米波雷达开发的朋友应该都有体会官方给的PROCESSOR_SDK_RADAR后面我统一叫它PSDKRA确实很完整里面帮你把AWR2243的驱动、数据通路、甚至是处理链路的Demo都搭好了烧进去就能看到点云或者原始ADC数据。但真正开始做自己的产品时这套默认工程反而成了最大的黑盒——你想改一下chirp配置、想少挂两颗芯片、想换一块自定义底板立刻就会撞到一堆编译不过、链接报错、启动卡死的问题。这篇文章就是记录我怎么在PSDKRA框架下为AWR2243做代码级适配的完整思路以及源码到底藏在哪里、哪几个修改点逃不掉、编译烧写的正确顺序是什么。内容适合正在用TDA4x搭配AWR2243做雷达开发、并且已经跑通官方demo、正准备往自定义方向改代码的嵌入式工程师。1. 为什么默认工程跑不起来AWR2243适配的三个死结1.1 默认SDK是冻结的工程不是教学代码很多朋友拿到SDK的第一反应是去源码里找雷达处理链路的实现结果翻了一圈发现核心的FFT、CFAR模块全是编译好的lib你能看到的只有调用它们的接口。这是TI故意做的产品化封装保证交付稳定但对想改功能的开发者来说就是一道墙。我的经验是先把能改什么和不能改什么分清楚。PSDKRA里大概分三层第一层是ASDK应用SDK里面是可直接修改的应用源码第二层是PSDKLA/PSDKRA自带的驱动和框架源码比如rl_device、radar_link、vision_apps里的link框架源码基本都开放第三层才是那些处理算法库和部分编解码核改动空间最小。AWR2243相关的适配工作绝大多数集中在前两层。1.2 死结一板卡EEPROM检测绕不过去官方EVM板子上有一颗EEPROM里面烧了板卡类型、硬件版本这类信息。TI的启动代码在初始化雷达驱动前会去读这颗EEPROM用来确认我是不是跑在官方评估板上。如果你用的是自己画的底板I2C总线布局都未必一样大概率读不到合法ID于是整个初始化流程直接断掉。我最初在这个问题上浪费了两天表面现象是串口打印报Error: Invalid Board ID然后MSS核就停在那不动了。一开始以为是SPI或者电源出了问题排查了半天才发现是EEPROM检测在作怪。解决办法有两种一是把检测函数直接注释掉二是伪造返回一个合法的板卡ID。具体修改位置我放到后面第三部分讲这里先提醒各位这是第一个必经修改点。1.3 死结二CSI2数据通道拓扑是写死的AWR2243是通过CSI2接口把ADC原始数据送到TDA4x的官方级联板是四颗AWR2243分别接到TDA4x的CSIRX0/1/2/3上代码里也默认按四通道去配置Lane、虚拟通道和带宽。如果你要做单芯片雷达或者两颗、三颗的级联组合就必须改数据路由的配置参数。这个不光是改一个数字那么简单CSI2的Lane映射、数据包解析、DSS的UDMA通道分配全都要跟着调。TI的代码在vision_apps里把这条链路拆成了多个link每个link都有自己的上下文结构体参数是结构体里嵌套着传的不动源码很难改透。1.4 死结三chirp配置和固件下载路径写死在代码里AWR2243本身运行的是TI的毫米波固件TDA4x通过SPI把固件和配置参数下发给它。配置参数里包括chirp起始频率、斜率、ADC采样率、发射天线组合这些它们看起来像是可以通过运行时的cfg文件去改但实际在PSDKRA里cfg文件只影响一小部分引擎参数真正决定雷达工作模式的rlSetConfig结构体内容经常是直接写死在C代码里的。比如你要把默认的距离分辨率从0.04m改成0.1m只改启动脚本是无效的必须找到代码里初始化rlDevice配置的那个结构体把带宽、斜率这些值改了重新编译固件侧的代码整条链路才会生效。这个改代码才能换参数的机制就是标题里说的修改代码的本质需求。2. 源码地图PSDKRA里AWR2243相关代码到底藏在哪2.1 从根目录出发先认清四个关键目录拿到PSDKRA安装包解压之后第一件事不是着急写代码而是先摸清目录结构。我常用的几个路径如下目录作用我为什么关注它/ti/vision_apps/Link框架、应用启动逻辑、多核通信数据通路改动的核心区域/ti/tiovx/OpenVX框架实现AWR2243相关kernel注册修改数据解析和预处理时用得上/ti/drv/dss/显示子系统、CSI2接收驱动CSI2 Lane和虚拟通道改动会涉及/ti/rl_device/毫米波雷达链路设备驱动rlSetConfig、rlDeviceInit这些重要调用的源头2.2 OVERRIDE机制TI留给开发者的官方卡槽PSDKRA里有个不那么显眼但非常好用的机制就是OVERRIDE。它的思路是不去破坏厂商SDK原有文件而是把你想修改的文件放在一个新的目录里编译时通过头文件搜索路径覆盖原来的同名文件。这样做的最大好处是方便管理修改点升级SDK版本时不会被覆盖掉。我在vision_apps/ti/下建了一个override目录把需要修改的雷达相关源文件拷贝进去然后在makefile里把INCLUDE_PATH或者VISION_APPS_DEPTH_READ_PATH指向这个目录优先搜索。实测下来这个方案很稳既保留了原始SDK的完整性也方便用diff工具随时查看自己到底改了什么。有一点要提醒OVERRIDE虽然好用但只对编译期源文件有效如果TI把某些关键路径编译成库了那OVERRIDE也覆盖不了。我目前遇到的AWR2243适配场景大部分源文件都还是开放的所以这个机制基本够用。2.3 AWR2243相关的源文件清单在PSDKRA里真正需要关心的AWR2243相关文件并不多整理一份我从初始适配到最后稳定运行的修改清单供各位参考vision_apps/apps/demos/radar_mmw/demo入口和应用初始化代码修改传感器启动流程常来这里。ti/tiovx/kernels/radar_link/雷达link的kernel实现包含数据发送接收的绑定逻辑。ti/rl_device/AWR2243设备驱动初始化、rlSetConfig参数组装。ti/drv/csi2/CSI2接收驱动修改Lane映射、数据类型的关键。platform/板级支持包I2C、GPIO、EEPROM这类板上资源初始化逻辑所在。vision_apps/rtos/RTOS侧各核运行的文件MSS/DSS的入口都在这里。表面上看文件很多但真正要动的也就十几个重点是搞清楚每个文件负责哪一段不要一上来就到处撒网。我的做法是先用grep -rn AWR2243把涉及AWR2243的所有文件列出来再按启动时序排序逐个看调用关系。3. 动手改第一刀关掉板卡检测让驱动在自定义板卡上活着3.1 定位板卡检测代码的准确位置前面说的EEPROM检测归根结底卡在I2C读板卡ID那一步。我自己用的方法很笨但有效在启动日志里打开调试开关定位到打印Invalid Board ID的具体文件然后往上追调用链。通常是在vision_apps里某个*_app.c的初始化函数中会先调用一个类似于boardDetect的函数再决定是否继续跑雷达初始化。找到这个函数后不要急着注释先看清楚它的返回值是怎么用的。我见过有的工程是直接safe_check(bootResult)这种形式你要是直接返回成功后续的板卡名称、天线校准表就可能缺失容易留下隐患。我建议把返回值置成合法板卡ID的同时把后续依赖这个ID的查询函数也一起处理掉。这是我修改的典型示意以boardDetect为例具体函数名随SDK版本略有差异/* 原始代码里会严格校验EEPROM里的板卡ID */ status Board_verifyEepromInfo(boardInfo); if (status ! SYSTEM_SUCCESS) { System_printf(Error: Invalid Board ID\n); return status; } /* 修改为自定义底板无EEPROM时直接使用默认配置 */ #if defined(CUSTOM_BOARD_NO_EEPROM) memcpy(boardInfo, defaultBoardInfo, sizeof(boardInfo)); #else status Board_verifyEepromInfo(boardInfo); #endif这样修改之后SPI初始化、固件下载这些流程可以正常往下走。实测下来在DRA829TDA4x平台上改动后启动日志里就不再报板卡错误了功耗和时钟配置也正常。3.2 固件下载路径别在细节上栽跟头AWR2243需要加载毫米波固件通常是xwr2243.bin这类的文件。PSDKRA的默认路径是放在SD卡或emmc的文件系统里通过文件路径字符串去读取。改板卡后或者你换了SDK版本路径名不一致就会出现固件加载失败。排查时先看串口有没有Loading Radar Firmware之类的日志然后确认加载的是不是你期望的那份固件。有个小技巧把open()失败时的错误码打出来我遇到过一次是ENOENT一看就是路径不对另一次是EACCES是文件系统挂载权限的问题。3.3 编译验证第一步确保驱动能正常加载改完板卡检测和固件路径之后先不要接着改别的编译一次并烧写验证确保AWR2243驱动能成功加载。这一步很重要因为如果SPI或者固件下载本身有问题后面改了chirp也白搭。编译命令示例不同SDK版本有差异这是我自己用的方式make -C vision_apps/ \ SOCj721e \ BOARDevm \ TARGET_MCUipu1_0 \ TARGET_CPUipu1_0 \ BUILD_OSrtos \ clean make -C vision_apps/ \ SOCj721e \ BOARDevm \ TARGET_MCUipu1_0 \ TARGET_CPUipu1_0 \ BUILD_OSrtos \ apps_radar如果驱动侧一切正常你会在串口看到类似Radar Device Init Done的日志。走到这一步说明AWR2243和TDA4x之间的基础通联已经没问题了接下来才能放心的去调chirp和数据通路。4. 改chirp与数据通路从雷达方程倒推寄存器值到DPC直出4.1 先算清楚你要的参数再动代码很多人改chirp配置是拍脑袋改改完发现数据一片乱。我的习惯是先从雷达方程反推确定目标指标再倒推出每个寄存器值。三个最常用的关系式距离分辨率 ΔR c / (2B)B是chirp带宽。想提高分辨率就增加带宽。最大不模糊距离 Rmax c × fs / (2S)fs是ADC采样率S是chirp斜率。想看得远采样率要够高斜率要够小。最大不模糊速度 Vmax λ / (4Tc)λ是雷达波长Tc是单个chirp周期含idle time。高速目标需要更短的chirp周期。举个例子假设要做一个近距离高分辨率场景目标距离10m以内距离分辨率0.05m那么按照 ΔR c / (2B)需要的带宽约3GHz。AWR2243在77GHz频段可用带宽约4GHz这意味着我们可以选择chirp起始频率为77GHz带宽3GHz斜率设为某个合理值比如60MHz/μs然后根据采样率和最大距离再校验。我把这一层思考写成了一张参数映射表修改代码时对着填就行目标指标决定参数影响关系距离分辨率带宽B越大越好最大距离ADC采样率、斜率采样率越高越好斜率越低越好最大速度chirp周期周期越短越好速度分辨率帧内chirp数越多越好角度精度收发天线布局硬件决定代码只能选组合4.2 在代码里的真实修改点PSDKRA里AWR2243的chirp配置一般在rlDeviceCfg_t或者类似的配置结构体里组装代码形态通常是chirpCfg[0].startFreqGHz 77.0f; chirpCfg[0].slopeMHzPerUs 60.0f; chirpCfg[0].idleTimeUs 10.0f; chirpCfg[0].adcStartTimeUs 6.0f; chirpCfg[0].adcSamples 512; chirpCfg[0].sampleRateMsps 10.0f; chirpCfg[0].txEnable 0x1; /* 只开TX1 */ chirpCfg[0].rxEnable 0x3; /* 只开RX1、RX2 */要注意的是adcSamples和sampleRateMsps得满足一个约束ADC采样时间不能超过chirp有效时间再减掉adcStartTime。否则配置下去固件会直接报错或者数据出现混叠。别问我怎么知道的我第一版把采样点数改到1024、采样率又调高结果AWR2243直接拒绝下发配置日志里一串RL_RET_CODE_ILLEGAL_CR。4.3 数据通路裁剪从四片级联改成单芯片改完chirp配置还只是第一步数据能不能按预期读出来才是关键。官方demo默认是四片AWR2243级联如果你要改成单芯片必须对数据通路做一次瘦身。这一步的核心在于理解数据流AWR2243出ADC数据CSI2传进TDA4x经过DSS的CSI2接收驱动后进入UDMA搬到DDR再由DPU数据处理单元或者DSP做距离FFT、多普勒FFT最后输出点云。想裁掉多余的芯片需要在代码里改这几个地方CSI2 Lane配置默认四芯片时每颗只用两条Lane如果你改成单芯片可以把Lane数合并成一棵4-Lane的接收树也可以继续用2-Lane关键要看你的底板走线怎么接。我这边做的是单芯片2-Lane改动最少。数据解析层AWR2243上报的数据包里带有虚拟通道号四芯片级联时四颗芯片分别在虚拟通道0、1、2、3上。改成单芯片后解析回调里的通道判断要跟着改否则数据会被当成错误包丢弃。DPC链路PSDKRA里的雷达处理链路是按节点组织的比如Capture节点、Range FFT节点、Doppler FFT节点、CFAR节点。默认链路里有级联合并的节点单芯片模式下可以把那个节点跳过或者取消绑定。修改之后最好在PC端先验证一下原始ADC数据是否正常再去看算法结果。我在DDR里导出过一段ADC原始数据用Python做了个简单的周期判断确认数据包结构正确后才继续上层调试。对应热词提到的awr2243雷达数据读取实际操作就是在代码里加一个导出函数把DDR里收到的原始数据存成二进制文件再拿到PC端分析。代码示意只说明思路/* 在收到CSI2数据包的callback里把原始数据导出来做验证 */ void RadarCaptureCallback(RadarFrame_t *frame) { memcpy(exportBuf, frame-imageData, frame-dataSize); write(exportFd, exportBuf, frame-dataSize); /* 后续再做FFT/CFAR处理 */ DpuDevice_process(frame); }4.4 代码修改运行逻辑控制流始终要先配置后启动在代码里反复调整AWR2243的配置时有一个运行逻辑顺序千万别搞错必须先完成rlSetConfig下发再调用rlSensorStart启动传感最后才是数据读取和算法处理。很多人改着改着觉得某个参数也要跟着变就直接在运行中断里改结果要么配置下发超时要么传感器状态机卡死。我在工程里习惯加一个状态机变量改成这样switch (radarState) { case RADAR_STATE_CONFIG: RadarLink_sendConfig(gRadarConfig); radarState RADAR_STATE_START; break; case RADAR_STATE_START: RadarLink_startSensor(); radarState RADAR_STATE_RUNNING; break; case RADAR_STATE_RUNNING: RadarLink_processFrame(); break; }这样的好处是逻辑清晰出问题时能根据状态值快速定位是配置阶段还是启动阶段出错比一锅粥的流程式代码好调试得多。5. 编译烧写与联调排障现场最常翻车的三个环节5.1 编译顺序不要盲目全量编译PSDKRA的工程涉及多个核R5F主核、DSP、A核编译顺序错了会浪费大量的时间。我的习惯是先编译驱动和依赖库再编译应用层。推荐的顺序是make tiovx先编OpenVX框架因为后续很多kernel都依赖它。make apps_radar只编雷达demo应用。如果改了rl_device则要先单独编rl_device库再编上层应用。不要一上来就make all全量编译一次要二十多分钟而增量编译通常几分钟就能完成。我日常调试基本只编自己改动的模块只有确认代码有改动才触发依赖模块重建。5.2 烧写验证SD卡是最快的验证载体开发阶段我强烈建议用SD卡启动修改完编译出的镜像拷贝到SD卡指定分区插上板子直接就能跑。PSDKRA的启动方式一般是SPL加载U-BootU-Boot从SD卡的rootfs读取主镜像。烧写命令大概长这样具体取决于你的SDK版本sudo dd iftiboot3.bin of/dev/sdX bs512 seek1 convfsync sudo dd iftispl.bin of/dev/sdX bs512 seek1 convfsync sudo dd ifu-boot.img of/dev/sdX bs512 seek1 convfsync然后把rootfs镜像解压到SD卡第二个分区最后把uEnv.txt里的boot参数改成指向SD根目录。我第一次烧写时漏了uEnv.txt导致U-Boot起来后找不到根文件系统卡在Waiting for root device排查了好一会儿才发现是boot参数的问题。5.3 三个现场问题的排查链路现象一SPI握手失败MSS启动卡死排查链路我一般这么走先看AWR2243的供电时序是否满足要求很多自定义底板电源轨多了顺序不对芯片就不响应。再用示波器看SPI的CS拉低时间和SCLK频率确认TDA4x侧主动发出的数据确实到达了AWR2243侧。最后用SPI回环模式测试链路完整性把MOSI和MISO短接看能不能收到自己发的数据。有一次我在这里查了很久发现是IO电平不匹配——AWR2243的电源域是1.8V而底板上的SPI上拉电阻接的是3.3V导致信号根本没被正确识别。换成1.8V电平转换之后立刻就好了。现象二CSI2有数据但DSS侧的接收配置不对如果SPI和固件都正常了但RadarCaptureCallback始终收不到数据大概率是CSI2的Lane映射或虚拟通道配置不对。先查AWR2243的数据手册中的Lane分配对比代码里csirxInit的Lane配置确认两者一致。再把CSI2接收侧的debug模式打开看硬件层的Lane状态寄存器确认有没有进入LaneFIFO的状态。现象三主核偶尔跑飞出现死循环这个最折磨人。我遇到过一次是改了chirp配置后DSS侧的UDMA传输长度和实际数据量不匹配导致DDR写越界把隔壁内存区域的代码踩掉了。排查的方法是开MMU检查或者用调试器监控PC指针的位置发现跑飞地址固定落在某个数据缓冲区附近才定位到是UDMA传输配置的问题。所以提醒大家改了ADC采样点数之后传输描述符里的buffer size一定要同步更新这类隐蔽问题最耗时间。写在最后的一点体会回头来看AWR2243的代码适配工作其实不复杂难的是信息分散——相关代码散落在驱动库、应用框架、板级配置里又没有一份文档告诉你改动一个参数会影响哪几条链路。我个人的建议是每次只改一个变量编译、烧写、看现象跑通了再改下一个千万别一口气把chirp、数据通路、DDI配置全改了出了问题你根本不知道是哪一环引起的。我自己改数据通路裁剪时就是因为同时改了CSI2 Lane和DPC链路结果单芯片就是不工作回退到只改一个地方后问题立刻明朗。这个习惯帮我节省了至少一个星期的调试时间各位如果卡在某个玄学问题上不妨先检查是不是自己同时动了太多处。本文还有配套的精品资源点击获取
AWR2243毫米波雷达PSDKRA代码级适配：从板卡检测到数据通路裁剪
简介针对TI AWR2243毫米波雷达传感器的PROCESSOR_SDK代码修改包面向基于这款77GHz雷达芯片做汽车安全、工业自动化与智能交通开发的嵌入式工程师解决了SDK默认参数难以发挥芯片最佳性能以及设备联网时无法固定IP地址的配置难题。整个资源非常精简共5个文件压缩后约21KB包含3个C源码文件、1个cfg网络配置文件和1个txt说明文档典型源码配置文档结构便于快速查阅和直接比对。当前已有1368人学习下载。改动内容围绕雷达工作参数发射频率、采样率、探测范围、分辨率等的适配以及RTOS静态IP地址支持的实现展开通过对照C代码与NDK配置可清晰理解每一项修改的作用与具体操作方法配套的Readme也给出了背景和注意事项。对于希望基于AWR2243做二次开发或需要掌握TI毫米波雷达SDK网络配置的工程师而言这份小体积代码包具有较强的参考与复用价值。 干过TI毫米波雷达开发的朋友应该都有体会官方给的PROCESSOR_SDK_RADAR后面我统一叫它PSDKRA确实很完整里面帮你把AWR2243的驱动、数据通路、甚至是处理链路的Demo都搭好了烧进去就能看到点云或者原始ADC数据。但真正开始做自己的产品时这套默认工程反而成了最大的黑盒——你想改一下chirp配置、想少挂两颗芯片、想换一块自定义底板立刻就会撞到一堆编译不过、链接报错、启动卡死的问题。这篇文章就是记录我怎么在PSDKRA框架下为AWR2243做代码级适配的完整思路以及源码到底藏在哪里、哪几个修改点逃不掉、编译烧写的正确顺序是什么。内容适合正在用TDA4x搭配AWR2243做雷达开发、并且已经跑通官方demo、正准备往自定义方向改代码的嵌入式工程师。1. 为什么默认工程跑不起来AWR2243适配的三个死结1.1 默认SDK是冻结的工程不是教学代码很多朋友拿到SDK的第一反应是去源码里找雷达处理链路的实现结果翻了一圈发现核心的FFT、CFAR模块全是编译好的lib你能看到的只有调用它们的接口。这是TI故意做的产品化封装保证交付稳定但对想改功能的开发者来说就是一道墙。我的经验是先把能改什么和不能改什么分清楚。PSDKRA里大概分三层第一层是ASDK应用SDK里面是可直接修改的应用源码第二层是PSDKLA/PSDKRA自带的驱动和框架源码比如rl_device、radar_link、vision_apps里的link框架源码基本都开放第三层才是那些处理算法库和部分编解码核改动空间最小。AWR2243相关的适配工作绝大多数集中在前两层。1.2 死结一板卡EEPROM检测绕不过去官方EVM板子上有一颗EEPROM里面烧了板卡类型、硬件版本这类信息。TI的启动代码在初始化雷达驱动前会去读这颗EEPROM用来确认我是不是跑在官方评估板上。如果你用的是自己画的底板I2C总线布局都未必一样大概率读不到合法ID于是整个初始化流程直接断掉。我最初在这个问题上浪费了两天表面现象是串口打印报Error: Invalid Board ID然后MSS核就停在那不动了。一开始以为是SPI或者电源出了问题排查了半天才发现是EEPROM检测在作怪。解决办法有两种一是把检测函数直接注释掉二是伪造返回一个合法的板卡ID。具体修改位置我放到后面第三部分讲这里先提醒各位这是第一个必经修改点。1.3 死结二CSI2数据通道拓扑是写死的AWR2243是通过CSI2接口把ADC原始数据送到TDA4x的官方级联板是四颗AWR2243分别接到TDA4x的CSIRX0/1/2/3上代码里也默认按四通道去配置Lane、虚拟通道和带宽。如果你要做单芯片雷达或者两颗、三颗的级联组合就必须改数据路由的配置参数。这个不光是改一个数字那么简单CSI2的Lane映射、数据包解析、DSS的UDMA通道分配全都要跟着调。TI的代码在vision_apps里把这条链路拆成了多个link每个link都有自己的上下文结构体参数是结构体里嵌套着传的不动源码很难改透。1.4 死结三chirp配置和固件下载路径写死在代码里AWR2243本身运行的是TI的毫米波固件TDA4x通过SPI把固件和配置参数下发给它。配置参数里包括chirp起始频率、斜率、ADC采样率、发射天线组合这些它们看起来像是可以通过运行时的cfg文件去改但实际在PSDKRA里cfg文件只影响一小部分引擎参数真正决定雷达工作模式的rlSetConfig结构体内容经常是直接写死在C代码里的。比如你要把默认的距离分辨率从0.04m改成0.1m只改启动脚本是无效的必须找到代码里初始化rlDevice配置的那个结构体把带宽、斜率这些值改了重新编译固件侧的代码整条链路才会生效。这个改代码才能换参数的机制就是标题里说的修改代码的本质需求。2. 源码地图PSDKRA里AWR2243相关代码到底藏在哪2.1 从根目录出发先认清四个关键目录拿到PSDKRA安装包解压之后第一件事不是着急写代码而是先摸清目录结构。我常用的几个路径如下目录作用我为什么关注它/ti/vision_apps/Link框架、应用启动逻辑、多核通信数据通路改动的核心区域/ti/tiovx/OpenVX框架实现AWR2243相关kernel注册修改数据解析和预处理时用得上/ti/drv/dss/显示子系统、CSI2接收驱动CSI2 Lane和虚拟通道改动会涉及/ti/rl_device/毫米波雷达链路设备驱动rlSetConfig、rlDeviceInit这些重要调用的源头2.2 OVERRIDE机制TI留给开发者的官方卡槽PSDKRA里有个不那么显眼但非常好用的机制就是OVERRIDE。它的思路是不去破坏厂商SDK原有文件而是把你想修改的文件放在一个新的目录里编译时通过头文件搜索路径覆盖原来的同名文件。这样做的最大好处是方便管理修改点升级SDK版本时不会被覆盖掉。我在vision_apps/ti/下建了一个override目录把需要修改的雷达相关源文件拷贝进去然后在makefile里把INCLUDE_PATH或者VISION_APPS_DEPTH_READ_PATH指向这个目录优先搜索。实测下来这个方案很稳既保留了原始SDK的完整性也方便用diff工具随时查看自己到底改了什么。有一点要提醒OVERRIDE虽然好用但只对编译期源文件有效如果TI把某些关键路径编译成库了那OVERRIDE也覆盖不了。我目前遇到的AWR2243适配场景大部分源文件都还是开放的所以这个机制基本够用。2.3 AWR2243相关的源文件清单在PSDKRA里真正需要关心的AWR2243相关文件并不多整理一份我从初始适配到最后稳定运行的修改清单供各位参考vision_apps/apps/demos/radar_mmw/demo入口和应用初始化代码修改传感器启动流程常来这里。ti/tiovx/kernels/radar_link/雷达link的kernel实现包含数据发送接收的绑定逻辑。ti/rl_device/AWR2243设备驱动初始化、rlSetConfig参数组装。ti/drv/csi2/CSI2接收驱动修改Lane映射、数据类型的关键。platform/板级支持包I2C、GPIO、EEPROM这类板上资源初始化逻辑所在。vision_apps/rtos/RTOS侧各核运行的文件MSS/DSS的入口都在这里。表面上看文件很多但真正要动的也就十几个重点是搞清楚每个文件负责哪一段不要一上来就到处撒网。我的做法是先用grep -rn AWR2243把涉及AWR2243的所有文件列出来再按启动时序排序逐个看调用关系。3. 动手改第一刀关掉板卡检测让驱动在自定义板卡上活着3.1 定位板卡检测代码的准确位置前面说的EEPROM检测归根结底卡在I2C读板卡ID那一步。我自己用的方法很笨但有效在启动日志里打开调试开关定位到打印Invalid Board ID的具体文件然后往上追调用链。通常是在vision_apps里某个*_app.c的初始化函数中会先调用一个类似于boardDetect的函数再决定是否继续跑雷达初始化。找到这个函数后不要急着注释先看清楚它的返回值是怎么用的。我见过有的工程是直接safe_check(bootResult)这种形式你要是直接返回成功后续的板卡名称、天线校准表就可能缺失容易留下隐患。我建议把返回值置成合法板卡ID的同时把后续依赖这个ID的查询函数也一起处理掉。这是我修改的典型示意以boardDetect为例具体函数名随SDK版本略有差异/* 原始代码里会严格校验EEPROM里的板卡ID */ status Board_verifyEepromInfo(boardInfo); if (status ! SYSTEM_SUCCESS) { System_printf(Error: Invalid Board ID\n); return status; } /* 修改为自定义底板无EEPROM时直接使用默认配置 */ #if defined(CUSTOM_BOARD_NO_EEPROM) memcpy(boardInfo, defaultBoardInfo, sizeof(boardInfo)); #else status Board_verifyEepromInfo(boardInfo); #endif这样修改之后SPI初始化、固件下载这些流程可以正常往下走。实测下来在DRA829TDA4x平台上改动后启动日志里就不再报板卡错误了功耗和时钟配置也正常。3.2 固件下载路径别在细节上栽跟头AWR2243需要加载毫米波固件通常是xwr2243.bin这类的文件。PSDKRA的默认路径是放在SD卡或emmc的文件系统里通过文件路径字符串去读取。改板卡后或者你换了SDK版本路径名不一致就会出现固件加载失败。排查时先看串口有没有Loading Radar Firmware之类的日志然后确认加载的是不是你期望的那份固件。有个小技巧把open()失败时的错误码打出来我遇到过一次是ENOENT一看就是路径不对另一次是EACCES是文件系统挂载权限的问题。3.3 编译验证第一步确保驱动能正常加载改完板卡检测和固件路径之后先不要接着改别的编译一次并烧写验证确保AWR2243驱动能成功加载。这一步很重要因为如果SPI或者固件下载本身有问题后面改了chirp也白搭。编译命令示例不同SDK版本有差异这是我自己用的方式make -C vision_apps/ \ SOCj721e \ BOARDevm \ TARGET_MCUipu1_0 \ TARGET_CPUipu1_0 \ BUILD_OSrtos \ clean make -C vision_apps/ \ SOCj721e \ BOARDevm \ TARGET_MCUipu1_0 \ TARGET_CPUipu1_0 \ BUILD_OSrtos \ apps_radar如果驱动侧一切正常你会在串口看到类似Radar Device Init Done的日志。走到这一步说明AWR2243和TDA4x之间的基础通联已经没问题了接下来才能放心的去调chirp和数据通路。4. 改chirp与数据通路从雷达方程倒推寄存器值到DPC直出4.1 先算清楚你要的参数再动代码很多人改chirp配置是拍脑袋改改完发现数据一片乱。我的习惯是先从雷达方程反推确定目标指标再倒推出每个寄存器值。三个最常用的关系式距离分辨率 ΔR c / (2B)B是chirp带宽。想提高分辨率就增加带宽。最大不模糊距离 Rmax c × fs / (2S)fs是ADC采样率S是chirp斜率。想看得远采样率要够高斜率要够小。最大不模糊速度 Vmax λ / (4Tc)λ是雷达波长Tc是单个chirp周期含idle time。高速目标需要更短的chirp周期。举个例子假设要做一个近距离高分辨率场景目标距离10m以内距离分辨率0.05m那么按照 ΔR c / (2B)需要的带宽约3GHz。AWR2243在77GHz频段可用带宽约4GHz这意味着我们可以选择chirp起始频率为77GHz带宽3GHz斜率设为某个合理值比如60MHz/μs然后根据采样率和最大距离再校验。我把这一层思考写成了一张参数映射表修改代码时对着填就行目标指标决定参数影响关系距离分辨率带宽B越大越好最大距离ADC采样率、斜率采样率越高越好斜率越低越好最大速度chirp周期周期越短越好速度分辨率帧内chirp数越多越好角度精度收发天线布局硬件决定代码只能选组合4.2 在代码里的真实修改点PSDKRA里AWR2243的chirp配置一般在rlDeviceCfg_t或者类似的配置结构体里组装代码形态通常是chirpCfg[0].startFreqGHz 77.0f; chirpCfg[0].slopeMHzPerUs 60.0f; chirpCfg[0].idleTimeUs 10.0f; chirpCfg[0].adcStartTimeUs 6.0f; chirpCfg[0].adcSamples 512; chirpCfg[0].sampleRateMsps 10.0f; chirpCfg[0].txEnable 0x1; /* 只开TX1 */ chirpCfg[0].rxEnable 0x3; /* 只开RX1、RX2 */要注意的是adcSamples和sampleRateMsps得满足一个约束ADC采样时间不能超过chirp有效时间再减掉adcStartTime。否则配置下去固件会直接报错或者数据出现混叠。别问我怎么知道的我第一版把采样点数改到1024、采样率又调高结果AWR2243直接拒绝下发配置日志里一串RL_RET_CODE_ILLEGAL_CR。4.3 数据通路裁剪从四片级联改成单芯片改完chirp配置还只是第一步数据能不能按预期读出来才是关键。官方demo默认是四片AWR2243级联如果你要改成单芯片必须对数据通路做一次瘦身。这一步的核心在于理解数据流AWR2243出ADC数据CSI2传进TDA4x经过DSS的CSI2接收驱动后进入UDMA搬到DDR再由DPU数据处理单元或者DSP做距离FFT、多普勒FFT最后输出点云。想裁掉多余的芯片需要在代码里改这几个地方CSI2 Lane配置默认四芯片时每颗只用两条Lane如果你改成单芯片可以把Lane数合并成一棵4-Lane的接收树也可以继续用2-Lane关键要看你的底板走线怎么接。我这边做的是单芯片2-Lane改动最少。数据解析层AWR2243上报的数据包里带有虚拟通道号四芯片级联时四颗芯片分别在虚拟通道0、1、2、3上。改成单芯片后解析回调里的通道判断要跟着改否则数据会被当成错误包丢弃。DPC链路PSDKRA里的雷达处理链路是按节点组织的比如Capture节点、Range FFT节点、Doppler FFT节点、CFAR节点。默认链路里有级联合并的节点单芯片模式下可以把那个节点跳过或者取消绑定。修改之后最好在PC端先验证一下原始ADC数据是否正常再去看算法结果。我在DDR里导出过一段ADC原始数据用Python做了个简单的周期判断确认数据包结构正确后才继续上层调试。对应热词提到的awr2243雷达数据读取实际操作就是在代码里加一个导出函数把DDR里收到的原始数据存成二进制文件再拿到PC端分析。代码示意只说明思路/* 在收到CSI2数据包的callback里把原始数据导出来做验证 */ void RadarCaptureCallback(RadarFrame_t *frame) { memcpy(exportBuf, frame-imageData, frame-dataSize); write(exportFd, exportBuf, frame-dataSize); /* 后续再做FFT/CFAR处理 */ DpuDevice_process(frame); }4.4 代码修改运行逻辑控制流始终要先配置后启动在代码里反复调整AWR2243的配置时有一个运行逻辑顺序千万别搞错必须先完成rlSetConfig下发再调用rlSensorStart启动传感最后才是数据读取和算法处理。很多人改着改着觉得某个参数也要跟着变就直接在运行中断里改结果要么配置下发超时要么传感器状态机卡死。我在工程里习惯加一个状态机变量改成这样switch (radarState) { case RADAR_STATE_CONFIG: RadarLink_sendConfig(gRadarConfig); radarState RADAR_STATE_START; break; case RADAR_STATE_START: RadarLink_startSensor(); radarState RADAR_STATE_RUNNING; break; case RADAR_STATE_RUNNING: RadarLink_processFrame(); break; }这样的好处是逻辑清晰出问题时能根据状态值快速定位是配置阶段还是启动阶段出错比一锅粥的流程式代码好调试得多。5. 编译烧写与联调排障现场最常翻车的三个环节5.1 编译顺序不要盲目全量编译PSDKRA的工程涉及多个核R5F主核、DSP、A核编译顺序错了会浪费大量的时间。我的习惯是先编译驱动和依赖库再编译应用层。推荐的顺序是make tiovx先编OpenVX框架因为后续很多kernel都依赖它。make apps_radar只编雷达demo应用。如果改了rl_device则要先单独编rl_device库再编上层应用。不要一上来就make all全量编译一次要二十多分钟而增量编译通常几分钟就能完成。我日常调试基本只编自己改动的模块只有确认代码有改动才触发依赖模块重建。5.2 烧写验证SD卡是最快的验证载体开发阶段我强烈建议用SD卡启动修改完编译出的镜像拷贝到SD卡指定分区插上板子直接就能跑。PSDKRA的启动方式一般是SPL加载U-BootU-Boot从SD卡的rootfs读取主镜像。烧写命令大概长这样具体取决于你的SDK版本sudo dd iftiboot3.bin of/dev/sdX bs512 seek1 convfsync sudo dd iftispl.bin of/dev/sdX bs512 seek1 convfsync sudo dd ifu-boot.img of/dev/sdX bs512 seek1 convfsync然后把rootfs镜像解压到SD卡第二个分区最后把uEnv.txt里的boot参数改成指向SD根目录。我第一次烧写时漏了uEnv.txt导致U-Boot起来后找不到根文件系统卡在Waiting for root device排查了好一会儿才发现是boot参数的问题。5.3 三个现场问题的排查链路现象一SPI握手失败MSS启动卡死排查链路我一般这么走先看AWR2243的供电时序是否满足要求很多自定义底板电源轨多了顺序不对芯片就不响应。再用示波器看SPI的CS拉低时间和SCLK频率确认TDA4x侧主动发出的数据确实到达了AWR2243侧。最后用SPI回环模式测试链路完整性把MOSI和MISO短接看能不能收到自己发的数据。有一次我在这里查了很久发现是IO电平不匹配——AWR2243的电源域是1.8V而底板上的SPI上拉电阻接的是3.3V导致信号根本没被正确识别。换成1.8V电平转换之后立刻就好了。现象二CSI2有数据但DSS侧的接收配置不对如果SPI和固件都正常了但RadarCaptureCallback始终收不到数据大概率是CSI2的Lane映射或虚拟通道配置不对。先查AWR2243的数据手册中的Lane分配对比代码里csirxInit的Lane配置确认两者一致。再把CSI2接收侧的debug模式打开看硬件层的Lane状态寄存器确认有没有进入LaneFIFO的状态。现象三主核偶尔跑飞出现死循环这个最折磨人。我遇到过一次是改了chirp配置后DSS侧的UDMA传输长度和实际数据量不匹配导致DDR写越界把隔壁内存区域的代码踩掉了。排查的方法是开MMU检查或者用调试器监控PC指针的位置发现跑飞地址固定落在某个数据缓冲区附近才定位到是UDMA传输配置的问题。所以提醒大家改了ADC采样点数之后传输描述符里的buffer size一定要同步更新这类隐蔽问题最耗时间。写在最后的一点体会回头来看AWR2243的代码适配工作其实不复杂难的是信息分散——相关代码散落在驱动库、应用框架、板级配置里又没有一份文档告诉你改动一个参数会影响哪几条链路。我个人的建议是每次只改一个变量编译、烧写、看现象跑通了再改下一个千万别一口气把chirp、数据通路、DDI配置全改了出了问题你根本不知道是哪一环引起的。我自己改数据通路裁剪时就是因为同时改了CSI2 Lane和DPC链路结果单芯片就是不工作回退到只改一个地方后问题立刻明朗。这个习惯帮我节省了至少一个星期的调试时间各位如果卡在某个玄学问题上不妨先检查是不是自己同时动了太多处。本文还有配套的精品资源点击获取
