汽车LED驱动容错系统设计：基于TPS929120-Q1的故障诊断与处理-平芜编程栈

1. 项目概述与核心价值

在汽车电子设计领域，尤其是关乎行车安全的照明系统，可靠性是压倒一切的首要指标。想象一下，在高速行驶或恶劣天气下，一个转向灯或刹车灯的失效，可能带来的安全隐患是巨大的。因此，一套能够实时诊断故障、并能在故障发生时依然维持基本功能或安全关闭的“容错机制”，就不再是锦上添花，而是现代汽车电子设计的硬性要求。

我最近深度参与了一个基于德州仪器（TI）TPS929120-Q1芯片的动态流水转向灯项目。TPS929120-Q1是一款12通道、40V高压侧汽车LED驱动器，其核心魅力不仅在于强大的驱动能力，更在于它内置了一套极其完善的诊断与保护“工具箱”。这个项目让我深刻体会到，将芯片的数据手册参数转化为一个稳定、可靠的量产系统，中间隔着无数个需要深思熟虑的工程决策。今天，我就结合这个实际案例，拆解一下如何在汽车LED驱动系统中实现从故障检测、精准定位到容错处理的完整闭环。无论是追求“一损他亮”（One-Fails-Others-On）以保证基础功能，还是执行“一损俱损”（One-Fails-All-Fail）以确保绝对安全，其背后的逻辑和实现细节，都值得我们深入探讨。

2. TPS929120-Q1故障诊断体系深度解析

要构建有效的容错机制，首先必须透彻理解芯片能“看见”哪些故障，以及它是如何“报告”这些故障的。TPS929120-Q1的诊断覆盖范围之广，在同类产品中相当突出，我们可以将其分为几个层次来理解。

2.1 故障类型全景图：从电源到LED

TPS929120-Q1的诊断功能贯穿了整个信号链，确保从输入到输出的每个环节都在监控之下。

第一层：电源与温度监控（系统级健康度）这是最基础的保障。芯片持续监控供电电压（SUPPLY）和内部LDO输出。当电压低于欠压锁定（UVLO）阈值时，会触发上电复位（POR），所有寄存器恢复默认值，这是一个硬性保护。此外，它还提供低供电电压预警，阈值可在5V至18V间编程设置，这能在电池电压缓慢下降时提前告警，为系统争取处理时间。温度方面，它集成了结温监测，提供典型135°C的预过热警告和175°C的过温保护（OTSD）。预警告是“提醒”，而OTSD则是“强制行动”——立即关闭所有输出通道。

第二层：参考电压与通信监控（核心功能保障）REF引脚是电流设定的基准，其重要性不言而喻。芯片会同时监测REF引脚电压和流经电流，任何异常（开路或短路）都会被立即标记为参考故障。通信监控则通过看门狗（Watchdog）实现。一旦主控制器（MCU）在设定的看门狗周期内未能与芯片成功通信，芯片会判定通信丢失，自动进入失效安全（Fail-Safe）模式。这是应对MCU死机或总线异常的最后防线。

第三层：LED负载故障诊断（输出级精细化管理）这是最复杂、也最体现价值的部分，主要针对LED串本身。

LED开路故障：芯片通过比较SUPPLY引脚电压与输出引脚OUTx电压的差值来判断。当差值低于设定的开路阈值（V(OPEN_th_rising)），且持续时间超过消抖时间（T(ODPW) + T(OPEN_deg)），同时供电电压高于低电压预警阈值时，即判定为开路。这里有个关键点：诊断仅在PWM开启（ON）阶段且脉宽足够长时才有效，这是为了避免在极短脉冲时误触发。
LED对地短路故障：通过内部比较器直接监测OUTx引脚电压。当电压低于短路阈值（V(SG_th_rising)）并持续超过消抖时间，即判定为短路。
单颗LED短路故障：这是更高级的诊断。当一颗LED内部短路，整串LED的压降会降低。芯片利用内置的ADC，在输出开启时（自动扫描模式）或按需（On-Demand）时，测量OUTx电压，并与预设的单LED短路阈值比较，从而定位问题。这在多颗LED串联的场合非常有用，能区分是整串不亮还是仅亮度异常。

第四层：EEPROM与按需诊断EEPROM CRC错误检查确保了配置数据的完整性。此外，芯片支持在所有输出关闭时进行“隐形诊断”，即输出一个微小电流脉冲来检测开路或短路，这对于上电前的安全检查或待机时的定期巡检非常有价值。

2.2 故障报告机制：ERR引脚与标志位寄存器

诊断是“发现”，报告是“告知”。TPS929120-Q1提供了硬件和软件两套报告机制，互为补充。

硬件报告：ERR引脚这是一个开漏输出引脚，可配置为故障指示总线。其行为模式根据故障类型和芯片工作状态（正常/失效安全）而不同：

正常状态：对于大多数故障（如开路、短路），ERR引脚会下拉一个50µs的脉冲。对于严重故障（如参考故障、过温保护），ERR引脚会持续下拉。这种脉冲/持续的区别，为MCU快速区分故障紧急程度提供了可能。
失效安全状态：一旦检测到故障，ERR引脚会持续下拉，直到故障清除。更重要的是，在此状态下，芯片自身会监控ERR引脚电压。当配置为“一损俱损”模式时，一旦检测到ERR被拉低（可能是自身故障，也可能是总线上的其他芯片故障），所有使能的通道都会关闭，实现了硬件级的连锁保护。

软件报告：标志位（FLAG）寄存器这是更精确的信息源。当任何故障发生时，相应的标志位寄存器（如FLAG_OPENCHx,FLAG_SHORTCHx,FLAG_ERR等）会被置位。MCU通过FlexWire接口读取这些寄存器，可以精确得知是哪个通道、发生了何种故障。FLAG_ERR是一个全局故障标志，可以快速指示是否有任何故障发生，无需轮询所有具体标志位。

故障屏蔽（Fault Masking）机制：这是一个非常实用的功能。它允许用户通过配置掩码寄存器，选择性地“忽略”某些非关键故障的报告（不触发ERR引脚和FLAG_OUT）。例如，在开发调试阶段，你可能不想让某个非关键通道的偶然性开路干扰测试，就可以屏蔽该通道的开路诊断。但请注意，屏蔽并不禁用诊断本身，只是不对外报告，诊断依然在后台运行。

3. 容错策略设计与实现：从理论到代码

理解了诊断能力，接下来就是如何利用它来构建容错系统。我们的项目目标是实现一个动态流水转向灯，共48颗LED（24串，每串2颗），由两片TPS929120-Q1驱动。核心需求是：流水点亮（180ms内顺序点亮24串）、全亮保持（220ms）、全灭（400ms）。任何故障发生时，系统必须能快速识别并执行预设策略。

3.1 正常状态下的故障处理流程

在MCU控制一切的正常状态下，故障处理是一个典型的“检测-判断-执行”软件循环。

3.1.1 精确故障识别流程与时间预算

这是整个容错机制的起点。流程的核心思想是：在点亮每一串LED后，立即检查是否有故障发生；若有，则深入读取具体标志位，定位故障通道和类型。

参考输入材料中的流程图，我将其转化为更贴近实际编程的步骤：

初始化与等待命令：MCU上电初始化后，等待车身控制器（BCM）通过CAN总线发来的转向灯启动命令。
循环点亮与即时检测： a. 清除配置锁和故障标志。 b. 关闭所有LED通道（确保起点状态干净）。 c. 设置CHx = 0，开始循环。 d. 点亮第CHx串LED。 e.关键步骤：立即读取FLAG0寄存器，检查FLAG_ERR位。如果为1，说明有故障发生。 f. 若FLAG_ERR=0，则等待约6ms（满足流水效果的时间间隔），CHx++，继续点亮下一串，直到24串全部点亮。 g. 若FLAG_ERR=1，则进入故障细分诊断流程：依次读取FLAG11至FLAG14（对应各通道的开路、短路标志），确定是CHx通道的开路还是短路故障。

这里有一个至关重要的工程计算：时间开销。在汽车应用中，响应速度直接关系到安全性。我们需要评估从故障发生到识别出具体类型，MCU需要多长时间。根据输入材料中的通信时间表，在200kbps的FlexWire波特率下，与两片芯片通信完成一轮“点亮-读FLAG0-读详细标志位”操作，总时间约为2.3ms。计算过程如下：

清除锁/使能寄存器等初始化操作：约0.7ms + 0.8ms + 0.7ms = 2.2ms（仅在循环开始前执行一次）。
单次循环内关键操作：
- 点亮一串LED（写使能寄存器）：0.8ms
- 读取FLAG0：0.6ms
- 发现故障后读取FLAG11-FLAG14：0.9ms
- 合计（单通道故障识别最大时间）：0.8 + 0.6 + 0.9 = 2.3ms。

这意味着，在最坏情况下，系统能在约2.3毫秒内定位到具体是哪一串LED出了什么问题。这个速度对于汽车照明故障响应来说是完全可以接受的。

实操心得：通信时序优化在实际编程中，为了进一步压缩这2.3ms，我通常会采用“预置命令帧”和“中断驱动”结合的方式。将常用的命令帧（如写使能、读FLAG）提前准备好放在发送缓冲区。同时，将FlexWire的RX中断设置为最高优先级之一，一旦收到芯片回复，立即处理，减少轮询等待时间。此外，如果MCU的UART支持DMA，将大大减轻CPU负担并提高时序确定性。

3.2 “一损他亮”与“一损俱损”的软件实现

识别出故障后，MCU需要根据系统设计需求，执行不同的容错策略。

3.2.1 “一损他亮”策略实现

这种策略的目标是：当某一串LED发生故障时，立即点亮所有其他正常的LED串，保证转向灯模块作为一个整体，依然能提供足够的警示亮度。

软件动作：在故障识别分支后，MCU首先通过CAN总线向BCM报告故障信息（通道号、故障类型）。随后，立即向两片TPS929120-Q1发送命令，将所有24个通道的使能位同时置1。之后，继续维持原有的“全亮400ms -> 全灭400ms”的闪烁周期。
设计考量：这种策略适用于对功能完整性要求极高的场景，如日间行车灯或位置灯。它牺牲了局部的动画效果（流水效果被打断），但保全了核心的警示功能。在代码实现上，需要确保“全部点亮”的命令优先级最高，执行速度最快，避免因故障报告等流程导致点亮延迟。

3.2.2 “一损俱损”策略实现

这种策略的目标是：当检测到任何故障时，立即关闭整个转向灯模块，并向BCM报告严重故障。

软件动作：识别故障后，MCU通过CAN报告故障，随后立即发送命令关闭所有LED通道。此后，MCU进入一个等待状态，不再执行任何点亮操作，直到收到BCM发来的新的明确指令（如“忽略故障，继续运行”或“进入安全模式”）。
设计考量：这通常用于刹车灯等高安全等级的场景。其逻辑是，一个部分失效的灯光可能会传递错误信号（例如，刹车灯一半亮一半不亮），不如完全关闭，并提示驾驶员检查车辆。这要求BCM有相应的策略来处理此类故障，例如激活备用灯光或仪表盘报警。

3.3 失效安全模式下的硬件容错机制

失效安全模式是当MCU与TPS929120-Q1通信丢失（如MCU死机、线路断开）时，芯片自主运行的“保底”模式。此时，容错逻辑由芯片硬件和预配置的EEPROM决定。

3.3.1 失效安全模式的工作原理

芯片通过FS（Fail-Safe）引脚的电平来选择两种预配置的输出状态（FS0和FS1）。这些状态对应两组独立的12位EEPROM寄存器（EEP_FS0CHx和EEP_FS1CHx），分别定义了FS引脚为低或高时，各个通道的使能状态。

进入条件：使能看门狗功能后，若在设定时间内无有效通信，芯片自动进入失效安全模式。
运行逻辑：此时，BCM可以直接通过一个GPIO控制FS引脚的高低电平，从而让所有芯片同步切换LED的全亮/全灭状态，实现最基本的闪烁功能，完全绕开了故障的MCU。

3.3.2 失效安全模式下的容错配置

这才是精髓所在。在失效安全模式下，芯片对故障的自主响应取决于一个关键的EEPROM寄存器：EEP_OFAF。

EEP_OFAF = 0：“一损他亮”模式。在失效安全状态下，如果某个通道发生故障（如开路/短路），芯片会自动关闭该故障通道，但其他正常通道继续工作。ERR引脚被持续拉低以通知BCM。同时，芯片会以10ms为周期，尝试用低电流脉冲去“重试”故障通道，一旦故障排除（如接触恢复），通道自动重新开启，ERR引脚释放。这是我们项目中采用的配置，因为它能在MCU失效的情况下，最大程度保持灯光功能。
EEP_OFAF = 1：“一损俱损”模式。在失效安全状态下，任何通道故障将导致芯片关闭所有使能通道。ERR引脚同样被拉低。这对于需要绝对安全关断的应用是必要的。

硬件连接关键点：为了实现失效安全下的系统级容错，需要将多个TPS929120-Q1的ERR引脚连接在一起，并上拉到VLDO。这样，任意一个芯片检测到故障并拉低ERR引脚，都会将这条“故障总线”拉低。在EEP_OFAF=1模式下，所有芯片检测到ERR总线为低，都会关闭自己的输出，从而实现跨芯片的“一损俱损”。

注意事项：EEPROM烧录EEP_OFAF等配置寄存器需要通过一次性的EEPROM烧录来设置。务必在量产前，通过MCU或编程器完成此操作，并验证烧录结果。一旦烧录，这些配置将在每次上电时自动加载，成为芯片的“本能”。在调试阶段，可以通过配置寄存器临时覆盖EEPROM设置进行测试。

4. 实战配置、调试与问题排查实录

理论清晰后，落地到硬件设计和软件调试，才是真正挑战的开始。下面分享一些从原理图到代码的实战要点。

4.1 硬件设计要点与参数计算

电流设定电阻（R(REF)）：这是决定LED电流的核心。公式为I(LED) = 2000 / R(REF) * I(FS)，其中I(FS)是内部基准电流（典型值）。例如，若需要每通道20mA电流，I(FS)设为典型值19.5uA，则R(REF) = 2000 * 19.5uA / 20mA ≈ 1.95Ω。需选用高精度、低温漂的电阻。
ERR引脚上拉电阻：ERR是开漏输出，必须接上拉电阻。阻值选择需权衡功耗和响应速度。通常使用4.7kΩ至10kΩ。若总线上挂载多个芯片，要考虑多个5mA下拉电流同时作用时，能否将总线电压可靠拉低到逻辑低电平。可以按最坏情况计算：R(pull-up) < (V(LDO) - V(OL)) / (N * I(OL))，其中N是芯片数量，I(OL)是5mA，V(OL)约0.4V。
FS引脚电路：在失效安全模式下，FS信号来自BCM。建议在MCU也正常时，由MCU控制一个MOSFET来切换FS，实现控制权的无缝切换。需加滤波电路防止噪声误触发。
电源与去耦：SUPPLY和VLDO引脚必须就近放置足够容量的陶瓷电容（如10uF）和高频去耦电容（100nF）。汽车电源环境恶劣，抛负载和瞬态电压可能高达40V以上，TPS929120-Q1的40V耐压是重要保障，但前级的TVS管和滤波电路依然必不可少。

4.2 软件驱动层实现与寄存器配置

软件的核心是围绕FlexWire通信协议，对芯片寄存器进行精确操控。

4.2.1 关键寄存器配置序列（上电初始化）

// 伪代码示例，基于典型MCU void TPS929120_Init(void) { // 1. 等待芯片完成POR（上电复位），可通过读取FLAG_POR判断 while(!Is_POR_Done()); // 2. 清除故障标志位，解锁配置寄存器 FlexWire_Write(DEV_ADDR, REG_CLR, CLR_FAULT | CLR_POR); FlexWire_Write(DEV_ADDR, REG_CONF_LOCK, 0x00); // 解锁 // 3. 配置工作参数（若需覆盖EEPROM默认值） FlexWire_Write(DEV_ADDR, REG_CONF_ODPW, ODPW_Value); // 设置诊断脉冲宽度 FlexWire_Write(DEV_ADDR, REG_CONF_ADCLOWSUPTH, LOW_SUP_THRESHOLD); // 低电压预警阈值 FlexWire_Write(DEV_ADDR, REG_CONF_DIAGENCHx, 0xFFF); // 使能所有通道诊断 FlexWire_Write(DEV_ADDR, REG_CONF_AUTOSS, 0x01); // 使能自动单LED短路检测 // 4. 配置看门狗超时时间（用于失效安全模式） FlexWire_Write(DEV_ADDR, REG_CONF_WDT, WATCHDOG_TIMEOUT); // 5. 重新锁定配置寄存器，防止误写 FlexWire_Write(DEV_ADDR, REG_CONF_LOCK, 0x01); }

4.2.2 动态扫描与故障处理线程在主循环或定时器中断中，实现状态机：

void LED_Scan_State_Machine(void) { static uint8_t current_channel = 0; static enum {SCANNING, ALL_ON, ALL_OFF, FAULT_HANDLED} state = ALL_OFF; static uint32_t timer = 0; switch(state) { case SCANNING: if(点亮第current_channel通道()) { if(读取FLAG0发现故障()) { 识别具体故障类型(); 执行容错策略(); // 例如，跳转到ALL_ON或ALL_OFF state = FAULT_HANDLED; 通过CAN上报故障(); } else { current_channel++; if(current_channel >= TOTAL_CHANNELS) { state = ALL_ON; timer = 获取系统滴答数(); } } } break; case ALL_ON: if(系统滴答数() - timer >= 220ms) { 关闭所有通道(); state = ALL_OFF; timer = 获取系统滴答数(); } break; case ALL_OFF: if(系统滴答数() - timer >= 400ms) { current_channel = 0; state = SCANNING; } break; case FAULT_HANDLED: // 根据策略，可能维持全亮/全灭，或等待BCM指令 break; } }

4.3 常见问题排查与调试技巧

在实际调试中，我遇到了不少坑，这里总结几个典型问题及其解决方法。

问题1：误报LED开路故障，尤其是在低温或电源波动时。

现象：系统偶尔，特别是在冷启动时，会误报某个通道开路，但实际LED是好的。
排查：
1. 检查SUPPLY电压是否在诊断期间低于CONF_ADCLOWSUPTH寄存器设置的阈值。TPS929120-Q1在供电电压低于此阈值时会禁用开路和单LED短路诊断，以防误报。如果阈值设置过高，在电池电压较低时可能误触发。
2. 检查PWM开启脉宽是否小于T(ODPW) + T(OPEN_deg)。诊断需要一定时间，如果PWM脉宽太窄，诊断未完成就关闭了，可能读不到稳定结果或误判。解决方案：适当增加PWM最小开启时间，或调整CONF_ODPW寄存器值。
3. 测量实际LED串的导通压降（Vf）。确保在最低工作温度下，SUPPLY电压减去LED的Vf后，仍高于开路故障阈值V(OPEN_th_rising)。需要留足裕量。

问题2：ERR引脚故障总线在多个芯片时行为异常。

现象：两片芯片中一片报故障，但另一片没有进入预期的失效安全响应。
排查：
1. 确认EEP_OFAF值：使用读取命令确认两片芯片的EEP_OFAF寄存器值是否符合设计（0或1）。务必确认EEPROM已正确烧录。
2. 检查ERR引脚硬件连接：确认所有芯片的ERR引脚是否真的连接在了一起，并且上拉电阻的阻值合适。可以用示波器观察故障发生时，ERR总线电压是否被可靠拉低至逻辑0（通常<0.8V）。
3. 检查FS引脚连接：在失效安全模式下，所有芯片的FS引脚也必须连接在一起，由同一信号源控制，才能实现同步闪烁。

问题3：通信不稳定，偶尔丢帧导致看门狗超时，意外进入失效安全模式。

现象：系统偶尔会突然所有LED按失效安全模式闪烁，但MCU程序并未死机。
排查：
1. 检查FlexWire布线：确保TX、RX走线远离电源等噪声源，并做好阻抗控制。过长的走线可能引起信号反射。
2. 调整看门狗超时时间：CONF_WDT寄存器设置的时间是否太短？确保它远大于MCU正常通信的最大间隔时间，并加上足够的余量（例如，正常扫描周期为几毫秒，看门狗可设为100ms）。
3. 增强软件容错：在MCU的通信驱动层增加重试机制。如果一次读写失败，立即重试1-2次。同时，定期（如每10个循环）发送一个“心跳”命令（如读取芯片ID寄存器），以刷新看门狗。

问题4：单LED短路检测不触发或不准。

现象：一颗LED短路，但自动扫描（AutoSS）或按需诊断没有报告。
排查：
1. 确认使能：检查CONF_AUTOSS或CONF_SSSTART是否已正确置1。
2. 检查电压阈值：单LED短路检测的阈值V(ADCSHORTTH)是可编程的。需要根据实际LED串的压降来设定。例如，两串LED正常压降为6V，如果一颗短路，压降可能变为3V。那么阈值应设置在3V到6V之间（如4.5V）。计算和设定必须准确。
3. 确认供电电压：和开路诊断一样，单LED短路检测也要求SUPPLY电压高于低电压预警阈值。

通过以上从理论分析、策略制定到实战调试的完整拆解，我们可以看到，基于TPS929120-Q1构建一个高可靠的汽车LED驱动容错系统，是一个将芯片强大硬件功能与周密系统设计、稳健软件逻辑紧密结合的过程。它不仅仅是配置几个寄存器，更是对汽车电子安全理念的深入实践。每一次故障的精准识别和恰当处理，都是对“功能安全”这一核心目标的一次坚实护航。