1. 项目概述与TESOC核心价值在汽车电子和工业控制这类对可靠性要求极高的领域芯片的长期稳定运行不是“锦上添花”而是“生死攸关”。想象一下一辆正在高速公路上行驶的自动驾驶汽车其核心的视觉处理单元如TDA3xx SoC中的EVE或DSP内部逻辑或存储器因为长期运行、温度变化或宇宙射线等软错误Soft Error而悄然失效后果不堪设想。传统的解决方案比如在产线进行一次性测试或者依赖外部复杂的ATE自动测试设备进行周期性诊断在系统部署到现场后往往变得不切实际或成本高昂。这就是TDA3xx芯片内置测试器Tester On Chip, TESOC存在的根本意义。它不是一块独立的芯片而是深度集成在TDA3xx SoC内部的一个安全关键硬件模块。简单来说TESOC就是给SoC里的关键“器官”如IPU、DSP、EVE等处理器核心及其存储器配备了一个“随身医生”。这个“医生”手里有一套出厂时就固化在ROM里的“体检手册”预编程的测试向量可以在系统启动、运行间隙或关机时随时对指定的“器官”进行一次全面的“健康检查”结构性测试而完全不影响其他“器官”的正常工作。其工程价值的核心锚点在于ISO 26262功能安全标准。为了达到ASIL-B汽车安全完整性等级B及以上的要求系统必须具备足够高的诊断覆盖率以检测随机硬件故障。TESOC提供的逻辑测试LBIST和存储器测试MBIST能力正是满足这一强制性要求的关键技术手段。它使得在汽车ADAS摄像头、雷达控制器等产品中开发者能够实现符合功能安全标准的现场自诊断无需增加外部复杂电路也无需中断核心业务功能在精心设计的时间窗口内从而在可靠性、成本和实时性之间取得了绝佳的平衡。2. TESOC架构与工作原理深度解析要玩转TESOC不能只停留在调用API的层面必须理解其硬件架构和运作机制这样才能在遇到问题时知道从何下手。2.1 逻辑域Logical Domains隔离设计TESOC设计中最精妙的一点就是逻辑域的划分。TDA3xx SoC内部并非铁板一块TESOC将需要测试的模块按电源域和功能关联性划分成了几个独立的逻辑域逻辑域目标IP电压域电源域包含模块DOMAIN0IPUVD_COREPD_IPUIPU, MCASP1, TIMER5-8等DOMAIN1EVEVD_DSPEVEPD_EVE嵌入式视觉引擎 (EVE)DOMAIN2DSP1VD_DSPEVEPD_DSP1数字信号处理器1 (DSP1)DOMAIN3DSP2VD_DSPEVEPD_DSP2数字信号处理器2 (DSP2)DOMAIN4ISS/DSS/VIPVD_COREPD_ISS/PD_DSS/PD_CAM图像子系统、显示子系统、视频输入端口为什么这么设计核心思想是隔离与可控。当需要对DOMAIN1EVE进行测试时软件通过PRCM电源复位时钟管理模块仅将EVE所在的电源域PD_EVE置于掉电Power Down状态。此时EVE与SoC其他部分的交互被硬件自动隔离输出被钳位TESOC便可以安全地“接管”EVE注入测试向量而不干扰正在运行的IPU或DSP。这就像医院里的隔离手术室医生可以对一个器官进行手术而不影响病人的其他生命体征。关键经验启动TESOC测试前必须确保目标域已通过软件正确下电。TESOC硬件会检查该域的所有模块是否都已进入低功耗状态如果检测到有模块未下电测试将不会启动。但这里有个坑硬件不会明确返回“下电失败”的错误。如果测试没启动你首先应该排查PRCM的配置序列确认目标域是否真的进入了OFF或RET状态。我曾在一个项目中因为忽略了某外设模块的时钟门控依赖导致DSP域无法彻底下电TESOC测试始终无法触发排查了半天才发现是电源管理序列不完整。2.2 测试向量与切片Slices机制TESOC的“体检手册”存储在片内ROM中内容是经过压缩的测试描述语言TDL向量。这些向量并非一整块而是被分成了多个切片Slice。每个逻辑域如IPU、EVE的LBIST和MBIST都有对应的、独立的切片集合。查看技术文档中的默认切片配置表例如IPU的LBIST切片配置为0x003FFFF8这实际上是一个位图bitmap。每一位代表一个特定的测试切片。0x003FFFF8这个值换算成二进制后对应了19个置位的比特意味着IPU LBIST默认启用19个测试切片。切片机制带来的灵活性是巨大的时间可控每个切片执行时间是固定的查表可知IPU LBIST切片约199μs一个。如果你的系统只在极短的时间窗口例如30μs内有空闲你可以只配置运行少数几个切片而不是运行全部19个。这实现了可伸缩的测试时间适应严苛的实时性要求。进度可恢复理论上如果测试被中止你可以记录已完成到第几个切片下次从中断的切片继续。不过需要注意LBIST/MBIST是破坏性的上下文无法保存所以“继续”通常意味着重新开始但切片机制至少让你知道上次完成了多少工作量。诊断切片每个LBIST域还包含一个特殊的诊断切片Diagnostic Slice。这个切片会故意注入一个错误然后验证TESOC是否能正确捕获并报告失败。这个切片预期结果是“失败”。如果它通过了反而说明TESOC的故障检测机制可能出了问题。这是验证TESOC自身功能是否完好的重要手段。2.3 三种操作模式与选用策略TESOC支持在三个不同的系统阶段触发测试各有其应用场景和优缺点启动时测试Start-up Field Test时机设备上电启动过程中在应用程序完全加载运行之前。优点复杂度最低最推荐。此时系统状态干净没有复杂的应用上下文需要保存/恢复。SBL二级引导程序天然适合做这个工作。缺点会增加系统启动时间Boot Time。对于要求快速启动的应用如车载CAN网络节点需要精心安排测试顺序可能只测最关键的IPU而将DSP/EVE的测试推迟。实践场景ADAS控制器的冷启动。SBL先进行最小化系统初始化然后依次对IPU、DSP、EVE运行TESOC测试全部通过后再加载并跳转到主应用程序。运行时测试Runtime Field Test时机系统正常运行期间当检测到某个核心如DSP处于空闲状态时。优点可以实现近乎连续的在线诊断最大化诊断覆盖率。缺点软件复杂度极高。因为LBIST/MBIST是破坏性的测试后核心所有寄存器和存储器内容都会丢失。这意味着在触发测试前软件必须将该核心的完整上下文所有寄存器状态、缓存数据、任务状态保存到共享内存如DDR测试完成后再恢复。这对于有多任务、实时操作系统的环境挑战巨大。实践建议TI的VSDK默认不支持运行时测试。除非你有极强的软件团队和严格的安全需求否则不建议轻易尝试。如果必须做可以考虑在时间触发的静态调度框架中为每个核心预留固定的“维护窗口”。关机时测试Shutdown Field Test时机系统正常关机或进入低功耗休眠状态前。优点不占用正运行时和启动时的时间。测试结果可以存入非易失存储器NVM下次启动时读取并采取相应措施如标记核心故障降级运行。缺点依赖电池或电容在关机后维持供电一段时间以完成测试。需要额外的电源设计和测试结果存储管理逻辑。实践场景车辆熄火后利用车载电池的余电对关键处理器执行一次全面的关机诊断并将结果写入EEPROM。对于大多数ADAS应用我的经验是优先采用“启动时测试”并根据启动时间要求进行优化延迟测试。例如在TI的SBL参考流程中先快速启动IPU并运行其自检然后加载CAN驱动确保通信之后再在后台对DSP和EVE进行测试最后再启动主要的视觉算法任务。3. TESOC实战编程指南与SBL集成理解了原理我们进入实战环节。这里以最常用、也最复杂的IPU自测试Start-up Test为例拆解其完整流程和背后的“为什么”。3.1 IPU自测试的完整流程与快速启动优化IPU自测试的特殊性在于IPU是TDA3xx的主控核心是启动过程的执行者。当IPU对自己发起测试时测试完成后它自身会被复位。这就引出了一个关键问题如何避免设备像首次上电一样重新经历漫长的完整启动过程解决方案是快速启动Fast Boot机制其核心是三个控制模块寄存器TESOC_LAST_RESET_INDICATOR[27:24]这是一个软件写的“标志寄存器”。在触发IPU自测试前软件向其中写入0xA。当TESOC完成测试并复位IPU后硬件会将该字段修改为0x5。Boot ROMRBL在启动时会检查这个寄存器。如果看到0x5它就明白“哦这次复位是TESOC测试完成的复位不是真正的电源上电复位PORz”。ROM_CPU0_BRANCH和ROM_CPU1_BRANCH在触发测试前软件需要把测试完成后希望CPU0和CPU1跳转执行的地址写入这两个寄存器。当RBL检测到是TESOC复位后就不会再走完整的初始化流程如重新初始化DDR、外设等而是直接跳到这两个地址继续执行。完整的IPU自测试代码流程基于PDK CSL API如下/* 1. 配置TESOC外部时钟 (TESOC_EXT_CLK) */ /* 强烈建议配置为48MHz这是保证TESOC稳定工作的基础 */ PMConfigureTesocExtClk(48U); // 使用PDK PM API /* 2. 设置快速启动标志和跳转地址 */ HW_WR_FIELD32(SOC_CONTROL_MODULE_BASE TESOC_LAST_RESET_INDICATOR, TESOC_LAST_RESET_INDICATOR_RESET_TYPE, 0xA); // 写入0xA表明即将开始TESOC测试 HW_WR_REG32(SOC_CONTROL_MODULE_BASE ROM_CPU0_BRANCH, (uint32_t)postTesocEntry); HW_WR_REG32(SOC_CONTROL_MODULE_BASE ROM_CPU1_BRANCH, (uint32_t)postTesocEntry); /* 3. 清理TESOC上次运行的状态 */ TESOCClearPrevState(SOC_TESOC_BASE, TESOC_DOMAIN_IPU); /* 4. 配置中断和交叉开关(IRQ XBAR) */ TESOCIntrEnable(SOC_TESOC_BASE, TESOC_INT_TEST_DONE); /* 将TESOC完成中断映射到IPU的某个中断线例如44 */ IRQXBARConnect(SOC_IRQ_DMARQ_CROSSBAR_REGISTERS_BASE, CPU_IPU1, 44U, // 中断线号 TESOC_IRQ_DONE); /* 将该中断配置为IPU的唤醒事件(Wake-up Event) */ IPU_WUGEN_Enable(44U); /* 5. 配置TESOC测试参数并启动 */ tesocTestCfg_t ipuTestCfg; TESOCGetDefaultSliceInfo(SOC_TESOC_BASE, ipuTestCfg); // 获取IPU默认切片配置 ipuTestCfg.domainLabel TESOC_DOMAIN_IPU; // 可以在此修改 ipuTestCfg.sliceConfig[] 以选择部分切片运行 TESOCConfigAndStart(SOC_TESOC_BASE, ipuTestCfg); /* 6. 通过PRCM将IPU域下电 */ /* 这是一个复杂的序列涉及关闭时钟、解除静态依赖、设置电源状态等 */ PRCMPowerDownIpDomain(); // 简化表示实际调用一系列PRCM API /* 7. 执行WFI/WFE指令等待断电。此后IPU停止运行。 */ /* TESOC硬件检测到IPU断电后自动开始测试。 */ /* 8. TESOC测试完成产生中断触发IPU PRCM将IPU唤醒复位。 */ /* 系统从复位中恢复RBL执行快速启动跳转到 postTesocEntry 函数。 */ /* 9. 在 postTesocEntry 函数中 */ void postTesocEntry(void) { /* 检查复位原因是否为TESOC */ if (HW_RD_FIELD32(SOC_CONTROL_MODULE_BASE TESOC_LAST_RESET_INDICATOR, TESOC_LAST_RESET_INDICATOR_RESET_TYPE) 0x5) { /* 10. 清除TESOC中断状态 */ TESOCIntrClear(SOC_TESOC_BASE, TESOC_INT_TEST_DONE); /* 11. 读取并检查测试结果 */ tesocAdvanceResult_t result; TESOCGetAdvanceResult(SOC_TESOC_BASE, ipuTestCfg, result); if (result.overallResult TESOC_TEST_PASS) { // 测试通过继续后续启动流程 } else { // 测试失败进入安全处理程序如点亮故障灯记录错误码 } } else { // 正常上电复位走完整的启动流程 } }关键陷阱与技巧中断映射的坑确保TESOC_IRQ_DONE正确映射到了IPU的中断控制器并且该中断被配置为唤醒事件而非普通中断。普通中断服务程序ISR在IPU被断电后是无法执行的只有唤醒事件才能触发PRCM重新上电并复位IPU。DSP下电的必要性在启动任何TESOC测试之前务必先确保所有DSPDSP1/DSP2已下电。这是因为在芯片刚启动时DSP内核处于未初始化状态其输出引脚状态不定。这些不确定的信号可能会被TESOC在测试其他模块如EVE或IPU时捕获导致虚假的MBIST测试失败。这是TDA3xx芯片的一个勘误点Errata务必遵守。TI的SBL代码里已经处理了这一点。结果读取顺序读取测试结果时必须结合切片状态寄存器SLICE_STATUS和切片结果寄存器SLICE_RESULT一起判断。因为结果寄存器的默认值是全1表示通过。如果某个切片被配置但未执行例如因测试中途失败而退出它的结果位可能仍是1。正确的做法是逐位检查只有那些在状态寄存器中标记为“已完成”且结果位为1的切片才算真正通过。3.2 利用SBL库简化启动测试对于标准的启动时测试TI提供的Secondary Bootloader (SBL)库已经做了大量封装极大地简化了流程。SBL将启动过程分为“TESOC前”和“TESOC后”两个阶段以避免IPU自测试导致的重置后重复初始化整个SoC。SBL中启用TESOC测试的典型流程配置CORE和PER域的DPLL锁相环。运行IPU TESOC自测试LBISTMBIST。完成后IPU复位SBL利用快速启动机制恢复。配置DSPEVE域的AVS自适应电压调节电压值至OPP_NOM级别。将DSPEVE域的时钟配置为OPP_NOM频率。这是关键一步MBIST测试要求被测模块运行在额定的标称频率下否则结果不可靠。依次执行DSP1、DSP2、EVE以及DSS/ISS/VIP的TESOC测试。将DSPEVE域的时钟重新配置为应用所需的工作频率如OPP_OD或OPP_HIGH。继续正常的应用程序引导。使用SBL库函数上述过程可以简化为#include sbl_lib.h #include sbl_lib_config_tda3xx.h // 在SBL初始化代码中确保未定义 SBL_CONFIG_DISABLE_SAFETY_FEATURES // 或者显式启用 TESOC #define SBL_LIB_CONFIG_ENABLE_TESOC // 定义测配置结构体 tesocTestCfg_t tesocConfig; // 运行IPU自测试 SBLLibRunTesocTest(TESOC_TEST_ID_IPU, tesocConfig); // 检查结果 int32_t result SBLLibCheckTesocTestResult(tesocConfig); if (result ! 0) { // 处理测试失败 } // 类似地运行其他域的测试... SBLLibRunTesocTest(TESOC_TEST_ID_DSP1, tesocConfig); // ... 检查结果SBL配置选项解析SBL_LIB_CONFIG_ENABLE_TESOC总开关启用TESOC功能。SBL_LIB_CONFIG_ENABLE_IPU_TESOC_ROM_CRC在运行IPU TESOC测试前先计算TESOC ROM的CRC校验值并与预存的有效签名0x6F10A976和0x731BA4C1比对。如果CRC校验失败说明ROM内容可能因电磁干扰EMI等因素损坏SBL将中止启动。这是一个重要的安全机制除非调试需要否则不建议禁用。4. 高级主题故障诊断、时钟考量与性能权衡4.1 TESOC测试失败的根因分析与诊断当TESOC测试报告失败时不要急于下结论是芯片硬件故障。应遵循以下诊断流程确认TESOC自身功能是否正常运行诊断切片Diagnostic Slice。调用TESOCRunTesoCDiagnosticAPI对目标域运行诊断测试。这个测试预期应该失败。如果它通过了说明TESOC模块自身的错误检测电路可能有问题其报告的其他失败结果也不可信。如果它如预期般失败则证明TESOC功能基本正常。确认被测域功能重复测试在相同的电源、时钟和温度条件下多次重复运行失败的测试。如果失败是持续性的Permanent Failure则很可能是芯片硬件缺陷。如果是偶发的Intermittent Failure则可能与电源噪声、时钟抖动或温度有关。检查配置仔细核对PRCM下电序列、时钟配置尤其是MBIST要求OPP_NOM频率、TESOC切片配置是否正确。一个常见的错误是MBIST测试时模块时钟未切换到额定频率。查阅勘误表查看TDA3xx的芯片勘误Errata文档确认是否有与你遇到的问题相关的已知限制或软件规避措施。收集诊断日志如果测试失败TESOC会将详细的错误信息如失败的测试向量、失效的内存地址等存入诊断日志寄存器。使用TESOCReadDiagnosticLogAPI可以读取这16条错误日志。这些信息对于TI技术支持分析问题至关重要。uint32_t diagLog[16]; TESOCReadDiagnosticLog(SOC_TESOC_BASE, diagLog); // 将 diagLog 数组内容保存到非易失性存储器或通过调试接口输出隔离测试如果可能尝试在最小系统仅核心供电和时钟下进行测试排除外围电路干扰。同时确保供电电源的纹波和稳定性符合数据手册要求。4.2 时钟配置的细节与陷阱时钟是TESOC正常工作的生命线配置不当会导致测试结果不可预测或直接失败。TESOC_EXT_CLK这是TESOC模块自身的工作时钟需要通过控制模块寄存器配置。推荐值为48MHz。务必在初始化TESOC前通过PDK的PM API如PMConfigureTesocExtClk将其正确使能并配置到稳定频率。被测模块时钟针对MBIST这是最容易出错的地方。TESOC的MBIST测试逻辑依赖于被测存储器本身的工作时钟。因此在启动某个域的MBIST测试前必须确保该域如DSPEVE域的时钟已经配置到数据手册中规定的额定频率OPP_NOM。例如DSP的MBIST必须在DSP运行于OPP_NOM频率下进行。如果你为了省电将DSP降频到OPP_LOW然后运行MBIST测试结果将是无效的。SBL中的时钟切换注意到SBL流程中在执行DSP/EVE测试前会先将时钟切换到OPP_NOM测试完成后再切回应用所需频率。这是一个标准且必要的操作。4.3 测试时间、覆盖率和系统设计的权衡TESOC测试需要时间而时间在实时系统中是宝贵资源。下表汇总了关键数据核心/模块逻辑测试(LBIST)覆盖率存储器测试(MBIST)覆盖率总测试时间(ms)LBIST切片数/时间(μs)MBIST切片数/时间(μs)IPU85.00%100%~3.9519 / 3781.253 / 169.00DSP1/290.10%100%~13.912 / 2812.5057 / 11500.00EVE92.80%100%~3.59 / 1750.0010 / 2125.00VIPN/A100%~0.8N/AN/ADSSN/A100%~0.4N/AN/AISSN/A100%~3.1N/AN/A系统设计启示启动时间预算如果你的系统要求2秒内完成启动并投入工作那么13.9ms的DSP测试时间是可以接受的。但如果你需要极速启动如100ms则可能需要重新考虑测试策略例如只进行IPU测试或者将DSP/EVE测试推迟到运行时在空闲窗口进行如果软件能支持上下文保存/恢复。切片化测试的价值假设DSP的MBIST总时间为11.5ms但系统只提供了5ms的空闲窗口。你可以通过配置切片只运行大约一半的MBIST切片对应约50%的存储器覆盖率在下一个空闲窗口运行另一半。这提供了灵活性但需要软件记录测试进度。覆盖率与测试时间的平衡LBIST覆盖率并非100%IPU为85%这是生产测试ATE与现场测试BIST的典型折衷。需要结合系统安全目标ASIL等级来判断是否足够或者是否需要额外的软件自检如定期CRC来补充诊断覆盖率。5. 常见问题排查与实战心得在实际项目中集成TESOC总会遇到一些文档里没细说的坑。这里分享几个我踩过的雷和解决方法。问题一TESOC测试根本启动不了TESOCWaitUntilNotBusy超时。排查思路时钟第一确认TESOC_EXT_CLK是否已正确配置并输出用示波器量一下。电源域状态确认目标模块是否真的下电了检查PRCM配置序列确保所有该域的模块都进入了OFF状态。特别留意那些有“静态依赖Static Dependency”的模块必须全部解除。DSP下电如果你测试的不是DSP而是IPU或EVE也请确保DSP1和DSP2已下电。这是前面提到的勘误要求。寄存器锁定是否忘记了在配置完成后“锁定”TESOC寄存器配置流程的最后一步是向TESOC_LOCK寄存器写入0x5。切片配置检查tesocTestCfg_t结构体中的sliceConfig数组确保你为目标域配置了有效的切片非零值。可以先用TESOCGetDefaultSliceInfo获取默认配置。问题二IPU自测试后系统没有快速启动而是从头开始执行Boot ROM。排查思路复位标志检查在触发测试前是否成功向TESOC_LAST_RESET_INDICATOR[27:24]写入了0xA写入的地址是否正确控制模块基址偏移跳转地址检查写入ROM_CPU0_BRANCH的地址是否有效该地址必须在IPU可以访问的地址空间内如OCMC RAM并且该处已经存放了有效的可执行代码你的postTesocEntry函数。唤醒事件确认TESOC完成中断是否成功配置为IPU的唤醒事件WUGEN中断线映射是否正确可以检查IPU_WUGEN_MEVT1寄存器的对应位是否被置位。问题三测试结果时好时坏尤其是MBIST测试。排查思路电源完整性这是MBIST失败最常见的原因之一。MBIST测试会对存储器进行高频、大规模的读写操作瞬时电流很大。确保电源网络尤其是VD_ DSPEVE的去耦电容设计合理电源纹波在规格范围内。在测试期间用探头测量一下电源波形。时钟稳定性确认被测模块在MBIST测试时是否运行在稳定的OPP_NOM频率。检查DPLL是否已锁定时钟有无抖动。温度高温可能导致时序违例。检查芯片结温是否在正常范围内。运行诊断切片先运行诊断切片确认TESOC自身报告失败正常以排除TESOC硬件问题。问题四如何在我的应用代码中而不只是在SBL里调用TESOC测试方法PDK CSL APItesoc.h,tesoc.c是独立于SBL的。你完全可以在应用程序中链接PDK库直接调用TESOCConfigAndStart,TESOCCheckTestResult等函数。关键点在于你需要自行管理目标模块的上下文保存与恢复对于运行时测试。你需要确保在测试期间没有其他主设备Master访问被测模块的内存空间否则会导致总线错误或数据损坏。对于IPU自测试你仍然需要处理好快速启动的流程。最后一点心得TESOC是一个强大的安全特性但把它用对、用稳需要开发者对TDA3xx的电源、时钟、复位架构有深入的理解。它不是一个简单的“点一下就开始”的功能。建议在项目早期就规划好测试策略何时测、测什么、测多久并留出充足的调试和验证时间。最好的方式是先基于TI的SBL示例代码搭建测试框架确保基本功能通再逐步移植和适配到自己的应用环境中。当你看到TESOC测试全部通过系统稳定启动时你会觉得这些深入细节的钻研都是值得的——因为这意味着一块符合功能安全要求的硬件基石已经筑牢。