1. 项目概述与核心价值

在汽车电池管理系统（BMS）或任何高可靠性嵌入式电源监控场景里，故障管理从来都不是一个“可有可无”的附加功能，而是系统安全运行的“生命线”。想象一下，一辆电动汽车正在高速行驶，其BMS如果无法准确、及时地识别并处理电池组的过压、欠压或通信中断故障，后果将不堪设想。这正是像TI BQ7961x-Q1这类车规级电池监控芯片存在的核心价值——它们不仅负责高精度的电压和温度采样，更构建了一套从检测、上报、屏蔽到诊断的完整故障管理体系，以满足ASIL-D（汽车安全完整性等级D级）的严苛要求。

这套机制的精妙之处在于，它并非简单地“一有异常就报警”。在实际工程中，过于敏感或混乱的故障上报反而会干扰系统主控（Host）的判断，甚至引发不必要的系统停机。因此，一个成熟的故障管理框架必须兼顾实时性、准确性和可管理性。BQ7961x-Q1芯片通过硬件寄存器与通信协议的精巧配合，实现了这一目标。它允许工程师灵活地屏蔽（Mask）非关键或已知的故障，只关注真正影响安全的异常；它提供了多种故障状态传递路径，无论是在全速运行的ACTIVE模式还是低功耗的SLEEP模式，都能确保主机及时获知链路上任意设备的故障；更重要的是，它集成了如OTP ECC、电源BIST等内置自检功能，实现了对监控系统自身健康度的“元监控”。

本文将深入拆解BQ7961x-Q1的故障管理与诊断机制。我们将从最基本的故障屏蔽与复位逻辑讲起，剖析故障状态是如何在菊花链通信中“流淌”并最终触发NFAULT引脚告警的。接着，我们会深入SLEEP模式下的心跳与故障音调机制，这是保证系统在“休眠”时依然具备安全监护能力的关键。最后，我们将探讨其高级诊断功能，包括OTP存储器的错误检查与纠正（ECC）原理，以及电源内置自检（BIST）的工作流程。无论你是正在评估该芯片的硬件工程师，还是负责编写底层驱动和故障处理逻辑的软件工程师，理解这些细节都将帮助你构建出更稳健、更安全的电池管理系统。

2. 故障管理核心机制深度解析

BQ7961x-Q1的故障管理是一个分层、立体的体系。最底层是遍布芯片各模块的硬件比较器和状态机，它们实时监测电压、温度、通信完整性等数十个参数。一旦检测到异常，相应的低级故障状态寄存器（如FAULT_OV,FAULT_UT,FAULT_COMM等）的对应位会被置位。这些低级状态会汇总到顶层的FAULT_SUMMARY寄存器，并最终可能触发NFAULT硬件引脚拉低，向主机MCU发出中断信号。然而，从检测到最终上报，中间经过了“屏蔽”、“复位”和“信号传递”三个关键环节的精细控制。

2.1 故障屏蔽：精准过滤，避免误报

故障屏蔽是故障管理的第一道“过滤器”。它的核心目的是防止某些已知的、非紧急的或预期内的异常状态触发系统级报警，避免主机被无效中断淹没。

2.1.1 屏蔽机制的工作原理

芯片提供了FAULT_MSK1和FAULT_MSK2两个故障屏蔽寄存器。每个可屏蔽的故障在低级状态寄存器中都有一个对应的状态位，同时在FAULT_MSK寄存器中有一个同名的屏蔽位。例如，过温（OT）和欠温（UT）故障共同影响FAULT_SUMMARY[FAULT_OTUT]位，而它们分别由FAULT_MSK1[MSK_OT]和[MSK_UT]控制。

当我们将某个屏蔽位置1时，会发生两件事：

1. 即使对应的低级故障条件发生，FAULT_SUMMARY寄存器中的汇总位也不会被置位。
2. 该故障将不会导致NFAULT引脚被断言（拉低）。

注意：屏蔽操作作用于故障的“上报路径”，而非“检测路径”。即使故障被屏蔽，芯片内部的硬件检测电路依然在工作，相应的低级故障状态寄存器（如FAULT_OT）仍然会被更新。你可以通过直接读取这些寄存器来了解系统状态，只是它不会向上汇总和触发硬件中断。这对于调试和状态监控非常有用。

2.1.2 屏蔽策略与实操要点

在实际项目中，屏蔽策略需要谨慎制定。通常，以下情况会考虑屏蔽：

• 初始化或校准期间：系统上电时，电源可能未完全稳定，电压采样值可能短暂超出阈值。可以临时屏蔽OV/UV故障，待稳定后再解除。
• 功能安全机制：某些故障被设计为冗余监控路径。例如，如果已有独立的硬件保护电路处理严重过压，那么芯片的软件OV故障报警可以作为次要路径，必要时可屏蔽以避免冲突。
• 已知无害的瞬态干扰：通信线上偶发的毛刺可能触发通信故障，如果确认是环境噪声且系统有重试机制，可以屏蔽此类故障。

一个常见的操作示例是屏蔽OT和UT故障：

// 假设通过SPI或UART对设备寄存器进行写操作 // 设置FAULT_MSK1寄存器的MSK_OT和MSK_UT位为1 write_register(DEVICE_ADDR, FAULT_MSK1, (1 << MSK_OT) | (1 << MSK_UT));

完成此操作后，无论电池温度如何变化，FAULT_SUMMARY[FAULT_OTUT]位都将保持为0，且不会触发NFAULT。

2.1.3 寄存器映射与关联关系

理解屏蔽位与故障状态的对应关系至关重要。下表整理了关键屏蔽位及其影响：

2.2 故障复位：清除状态，但需治本

故障状态一旦被锁存，就会持续存在，直到被明确复位。复位操作通过FAULT_RST1和FAULT_RST2寄存器进行，其位结构与FAULT_MSK寄存器一一对应。

2.2.1 复位机制的关键逻辑

向某个故障复位位写1，会尝试清除其关联的所有低级故障寄存器以及相关的DEBUG_*寄存器。仅当所有关联的低级寄存器都被清除后，FAULT_SUMMARY中对应的汇总位才会被清除。

这里有一个至关重要的限制：复位操作只能清除故障状态标志，不能消除故障本身。如果底层的故障条件仍然存在（例如，电池电压仍然过压），那么即使主机发送了复位命令，相应的故障状态位也会在下一个检测周期立即再次被置位。这防止了软件通过简单地“清标志”来掩盖真实的硬件问题。

2.2.2 复位操作流程与注意事项

正确的故障处理流程应该是：

1. 识别故障：主机通过NFAULT中断或轮询FAULT_SUMMARY发现故障。
2. 定位根源：读取具体的低级故障寄存器（如FAULT_OV，FAULT_COMM3）确定故障类型和来源。
3. 消除故障：采取硬件或软件措施解决根本问题（例如，停止充电以消除过压，检查通信线路连接）。
4. 执行复位：确认故障条件已消除后，向对应的FAULT_RST位写1，清除状态锁存。
5. 验证清除：再次读取FAULT_SUMMARY和相关低级寄存器，确认状态已归零。

例如，要复位一个通信超时故障：

// 1. 读取并确认是COMM3故障 uint16_t fault_comm3 = read_register(DEVICE_ADDR, FAULT_COMM3); if (fault_comm3 & (1 << FCOMM_DET)) { // 2. 检查物理链路，解决通信问题... // 3. 故障条件解决后，执行复位 write_register(DEVICE_ADDR, FAULT_RST2, (1 << RST_COMM3_FCOMM)); // 4. 短暂延时后验证 delay_ms(1); fault_comm3 = read_register(DEVICE_ADDR, FAULT_COMM3); if ((fault_comm3 & (1 << FCOMM_DET)) == 0) { // 复位成功 } }

2.3 故障信号传递：从芯片到主机的路径

故障状态如何从菊花链中某个从设备传递到基设备，并最终通知主机？BQ7961x-Q1提供了两种主要模式：ACTIVE模式下的嵌入式状态位传递和SLEEP模式下的音调传递。

2.3.1 ACTIVE模式：嵌入式状态位传递

在ACTIVE（主动）模式下，当设备使能了故障通信功能（DEV_CONF[FCOMM_EN] = 1），故障状态会通过重写UART响应帧中的特定比特位来传递。

具体来说，在正常的响应帧中，设备地址字节和寄存器地址字节（高、低字节）都有一个起始帧（SOF）位。当FCOMM_EN=1时，这三个SOF位被重新用作“故障状态位”。每个设备在转发响应帧时，会将自己的故障状态“或”（OR）到这些比特位上。

• 设备无故障：用0b000进行OR操作。
• 设备有故障：用0b111进行OR操作。

因此，如果菊花链中任何设备存在故障，当响应帧传递到基设备时，这三个故障状态位最终都会变成0b111。基设备检测到至少有两个位为1时，就会断言（拉低）NFAULT引脚，并向主机发出中断。

这个过程是高效的，因为它利用了已有的通信流量来“捎带”故障信息，无需额外的通信开销。主机在收到NFAULT中断后，可以发起一次广播读取（Broadcast Read）命令，查询链路上所有设备的FAULT_SUMMARY寄存器，快速定位故障设备。

2.3.2 一个故障传递的典型场景

假设一个三从设备（S1, S2, S3）加一个基设备（B0）的菊花链，S2发生了故障。

1. 主机向顶端的S3发送一个单设备读命令。
2. S3（无故障）生成响应帧，其三个故障状态位初始为0b000，并向下传递给S2。
3. S2（有故障）收到帧后，将自己的故障状态0b111OR到帧上，结果变为0b111，继续向下传。
4. S1（无故障）收到0b111的帧，用0b000OR，结果保持0b111，继续下传。同时，S1检测到经过的帧中故障位被置起，会设置自己的FAULT_COMM3[FCOMM_DET] = 1（如果该故障未被屏蔽，S1自身也会进入故障状态）。
5. B0（基设备）收到0b111的响应帧，检测到故障状态，随即拉低NFAULT引脚通知主机。B0也会设置自己的FCOMM_DET标志。
6. 主机检测到NFAULT中断，发起广播读命令，遍历所有设备的FAULT_SUMMARY，迅速发现S2的寄存器值非零，从而定位故障源。

3. 低功耗SLEEP模式下的故障监控

在SLEEP模式下，芯片的大部分电路关闭以节省功耗，但关键的安全监控必须持续。此时，常规的UART通信已不可用。BQ7961x-Q1采用了“心跳（Heartbeat）”和“故障音调（Fault Tone）”机制来实现休眠期的状态监控。

3.1 心跳与故障音调的工作原理

心跳和故障音调本质上是两种不同模式的周期性通信脉冲（Tone），通过COMH/COML差分线传输。它们的物理波形与通信Tone类似，都是由一系列“耦合对”（Couplet）组成，但发送周期和耦合对数量不同。

• 心跳音调：设备处于无故障状态时，周期性发送的信号。向系统宣告“我还活着，且一切正常”。
• 故障音调：设备处于故障状态时，周期性发送的信号。用于在休眠期报警。

3.1.1 使能与配置

通过设置DEV_CONF[HB_EN]和[FTONE_EN]来分别使能心跳和故障音调的发送器。需要注意的是，接收器在SLEEP模式下是始终启用的。音调的传输方向由CONTROL1[DIR_SEL]配置决定，为了能让音调信号最终传回基设备（B0）以触发NFAULT，必须使用环形（Ring）菊花链拓扑，而不能是线形（Line）拓扑。

3.1.2 信号传递与故障检测

在SLEEP模式下，以下故障检测依然有效：

• 客户和工厂OTP影子寄存器的CRC校验
• 器件热警告
• 电源过压（OV）、欠压（UV）和振荡检测
• 如果使能了OV/UV保护器，则包括电芯OV/UV检测
• 如果使能了OT/UT保护器，则包括热敏电阻OT/UT检测

当链路上某个设备发生故障，它会开始发送故障音调。这个音调会沿着环形链路传播。基设备（B0）的接收器检测到故障音调后，就会断言NFAULT引脚，将主机从休眠中唤醒。主机被唤醒后，可以将系统切换到ACTIVE模式，再通过UART通信详细查询具体的故障寄存器，以确定故障类型和位置。

3.1.3 避免误报：屏蔽通信故障

由于心跳和故障音调本身是一种通信，其传输过程也可能受到干扰。为了避免因短暂的音调丢失或畸变误触发系统故障，芯片提供了专门的屏蔽位：

• FAULT_MSK2[MSK_COMM3_HB]：屏蔽心跳音调故障。
• FAULT_MSK2[MSK_COMM3_FTONE]：屏蔽故障音调故障。

在系统设计初期进行噪声测试时，可以暂时屏蔽这些位，待确认物理链路可靠性后，再根据安全需求决定是否开启。

3.2 SLEEP模式监控设计要点

1. 拓扑限制：务必使用环形菊花链连接，确保音调信号能闭环传递。
2. 功耗权衡：音调是周期性发送的，其频率和周期会影响系统平均功耗。需要根据故障响应时间要求来配置合理的音调周期。
3. 唤醒策略：主机收到NFAULT唤醒后，应有一套清晰的流程：切换至ACTIVE模式 -> 广播读取FAULT_SUMMARY-> 定位故障设备 -> 读取详细故障寄存器 -> 执行处理逻辑。
4. 故障恢复：对于某些可恢复的故障（如瞬态干扰），在SLEEP模式下，故障条件消失后，设备会自动停止发送故障音调，恢复为心跳音调。但故障状态位仍然被锁存，需要主机在唤醒后主动清除。

4. 高级诊断功能：BIST与存储器完整性

为了满足ASIL-D对系统内建诊断覆盖率的要求，BQ7961x-Q1集成了强大的自检和存储器保护功能，确保监控系统自身的可靠性。

4.1 电源内置自检

电源内置自检（Power Supply BIST）是一种“对检查器进行检查”的机制。它的目的是验证芯片内部各个电源轨（如AVDD, DVDD, CVDD, TSREF等）的故障检测路径（如OV、UV、振荡检测）是否功能正常。

4.1.1 BIST执行流程

1. 前期准备：

   • 确保TSREF电源已使能（如果BIST需要测试其诊断路径）。
   • 建议通过FAULT_MSK寄存器屏蔽所有与电源无关的故障，避免BIST测试过程中触发无关的NFAULT。
   • 确认当前无真实的电源故障存在。

2. 启动BIST：向DIAG_PWR_CTRL[PWR_BIST_GO]位写1。

3. BIST引擎工作：对于每一个待测的电源诊断路径（例如AVDD OV检测）：

   • BIST内部逻辑会强制在该路径的 comparator（比较器）输入端注入一个故障条件（例如，模拟一个过压信号）。
   • 随后，BIST检查对应的故障寄存器位（如FAULT_PWR1[AVDD_OV]）是否被正确置位，以及NFAULT信号是否��正确断言。
   • 检查完毕后，BIST引擎会复位该故障标志和NFAULT信号。
   • 接着对下一个诊断路径重复此过程。

4. 结果判定：BIST运行结束后，结果体现在FAULT_PWR2[PWRBIST_FAIL]标志位。

   • 0：所有被测试的诊断路径功���正常。
   • 1：至少有一条诊断路径无法在注入故障时正确触发。

重要提示：在BIST运行期间，NFAULT引脚会因测试而被反复触发（拉低再释放）。主机应忽略此期间的NFAULT状态，或提前通过设置DEV_CONF[NFAULT_EN] = 0来禁用NFAULT输出。

4.1.2 故障路径精确定位

如果BIST报告失败（PWRBIST_FAIL=1），如何定位具体是哪条路径出了问题？芯片提供了DIAG_PWR_CTRL[BIST_NO_RST]位。将该位置1后再次运行BIST，BIST引擎在测试每个路径后将不会自动复位故障寄存器。测试完成后，主机可以读取FAULT_PWR1和FAULT_PWR2寄存器。那些仍然为0的标志位，就对应着失效的诊断路径。例如，如果测试完成后FAULT_PWR1[AVDD_OV]仍为0，说明AVDD过压检测电路可能失效。

4.2 OTP与ECC：数据完整性的堡垒

一次性可编程存储器（OTP）用于存储芯片的关键配置参数。其数据的完整性至关重要。BQ7961x-Q1采用了多层保护机制：CRC校验和ECC纠错。

4.2.1 OTP的加载与CRC校验

芯片上电或复位时，会将OTP中的内容加载到对应的“影子寄存器”中运行。此过程包含两级校验：

1. CRC校验：针对客户和工厂OTP空间，芯片会计算其CRC值，并与OTP中预先存储的CRC值进行比较。如果不匹配，则设置FAULT_OTP[CUST_CRC]或[FACT_CRC]故障位。CRC错误通常意味着存储的数据被破坏，不可恢复。
2. ECC加载：对于地址0x0000至0x002F的关键寄存器区域，OTP数据以64位为一块，每块附加8位ECC校验码。加载时，ECC引擎会执行单错误纠正/双错误检测。

4.2.2 ECC机制详解

ECC（Error Checking and Correction）采用标准的（72, 64）汉明码。

• 单比特错误纠正：如果某个64位数据块中仅有1个比特在存储或加载过程中发生翻转，ECC引擎能够自动检测并纠正该错误。纠正后，数据被正确加载到影子寄存器，同时FAULT_OTP[SEC_DET]位被置1，并且错误发生的块位置会记录在DEBUG_OTP_SEC_BLK寄存器中。出现SEC并不意味着器件立即失效，但它是一个早期预警，提示存储单元可能开始出现老化。
• 双比特错误检测：如果同一个64位块中有2个比特出错，ECC只能检测而无法纠正。此时，该块数据不会被加载，芯片将使用该寄存器的硬件默认值。FAULT_OTP[DED_DET]位被置1，错误块位置记录在DEBUG_OTP_DED_BLK中。出现DED通常意味着该OTP区域已不可信，器件应被视为故障，不建议继续在安全关键应用中使用。

4.2.3 OTP编程与状态管理

芯片提供两个客户OTP页（Page1和Page2）用于存储用户配置。编程OTP是一个需要谨慎操作的过程，一旦写入便无法更改。编程前，必须确保影子寄存器中的配置值是正确的，并通过OTP_CUST*_STAT寄存器确认目标页是可编程状态（[TRY]=0且[FMTERR]=0）。

编程步骤高度结构化，必须严格遵循数据手册中的序列：

1. 解锁序列：分两次向OTP_PROG_UNLOCK1A~1D和OTP_PROG_UNLOCK2A~2D写入特定的密钥数据。必须连续写入，中间不能有任何其他读写操作，否则序列失效需重来。
2. 确认解锁：读取OTP_PROG_STAT[UNLOCK]确认是否为1。
3. 启动编程：向OTP_PROG_CTRL寄存器写入，选择页面（Page1或Page2）并置位[PROG_GO]。
4. 等待完成：等待至少tPROG（典型值100ms），期间禁止任何数据通信。
5. 验证状态：编程完成后，检查OTP_PROG_STAT[DONE]=1，并确认目标页状态寄存器的[PROGOK],[TRY],[OVOK],[UVOK]等位均为1。
6. 复位生效：发送软件复位命令（CONTROL1[SOFT_RESET]=1），使新的OTP配置加载到影子寄存器。

实操心得：OTP编程失败最常见的原因有两个：一是解锁序列被中断；二是编程期间发生了通信。务必使用单条写命令完成整个解锁序列的四个寄存器写入。在发起[PROG_GO]后，MCU应进入阻塞等待，并关闭所有对该芯片的通信任务，直到超时或检测到[DONE]标志。

5. 系统级故障处理策略与常见问题

将芯片级的故障管理机制整合到完整的BMS应用中，需要一套清晰的系统级策略。

5.1 故障处理状态机设计建议

一个健壮的故障处理流程可以抽象为一个状态机：

1. 空闲监控态：系统正常运行，周期性轮询FAULT_SUMMARY或等待NFAULT中断。
2. 故障触发态：检测到FAULT_SUMMARY != 0或 NFAULT被断言。
3. 故障定位态：
   • 如果是NFAULT触发，先发起广播读，快速定位哪个设备的FAULT_SUMMARY非零。
   • 读取故障设备的详细低级故障寄存器（FAULT_OV,FAULT_COMM等），精确识别故障类型。
   • 读取DEBUG_*寄存器（如果可用）获取更多上下文信息。
4. 故障评估与行动态：
   • 可恢复故障：如通信超时（FCOMM_DET）。尝试复位通信接口或检查链路。若恢复，则清除故障标志。
   • 不可恢复/安全关键故障：如电芯严重过压（OV）、OTP双比特错误（DED_DET）。立即触发安全保护动作（如断开接触器），并记录不可恢复故障码，可能需要维护干预。
   • 预警类故障：如温度警告（TWARN）。执行降额或通知用户，但无需立即停机。
5. 复位与恢复态：确认底层故障条件已消除后，向对应的FAULT_RST位写1。验证故障标志已清除，系统返回空闲监控态。

5.2 常见问题与排查实录

问题1：NFAULT引脚频繁误触发，但读取所有FAULT_SUMMARY均为0。

• 可能原因：使能了故障通信（FCOMM_EN=1），但未正确屏蔽通信故障。当链路受到噪声干扰，导致响应帧中的故障状态位出现毛刺时，即使设备无真实故障，基设备也可能因检测到0b111而触发NFAULT。
• 排查步骤：
  1. 检查FAULT_COMM3[FCOMM_DET]是否被置位。
  2. 检查FAULT_MSK2[MSK_COMM3_FCOMM]是否已置1以屏蔽该故障。
  3. 检查菊花链布线，确保差分对走线等长、远离噪声源，并考虑在COMH/COML线上增加共模扼流圈。

问题2：OTP编程总是失败，OTP_PROG_STAT显示错误。

• 可能原因A：解锁序列不正确。
  • 解决：确保使用单次块写（Block Write）命令，一次性写入四个解锁寄存器，中间无任何其他操作。检查写入的密钥值是否正确。
• 可能原因B：编程电压不稳定。
  • 解决：检查为芯片LDOIN引脚供电的电源质量，并确保其去耦电容（典型值0.1μF）焊接良好。编程期间电压需稳定。
  • 查看：检查OTP_CUST*_STAT[UVOK]和[OVOK]位，以及OTP_PROG_STAT中的[UVERR],[OVERR]等位，确认是否为电压问题。
• 可能原因C：芯片温度过高。
  • 解决：数据手册明确规定，OTP编程不能在55°C以上进行。编程前测量芯片温度。

问题3：系统从SLEEP模式被NFAULT唤醒，但查不到任何故障。

• 可能原因：SLEEP模式下的故障音调被误触发，或心跳音调丢失导致基设备误认为故障。
• 排查步骤：
  1. 确认是否使用了环形拓扑。线形拓扑在SLEEP模式下无法将音调传回基设备。
  2. 检查FAULT_COMM3[HB_FAIL]或[FTONE_DET]是否被置位。
  3. 考虑在SLEEP模式下临时屏蔽[MSK_COMM3_HB]和[MSK_COMM3_FTONE]，观察是否还有误唤醒。如果是，则问题可能出在通信链路噪声或设备配置上。
  4. 调整心跳/故障音调的周期或检测阈值（如果配置可用），增强抗干扰能力。

问题4：电源BIST测试通过，但实际发生电���故障时，相应标志位并未置位。

• 可能原因：BIST测试的是故障检测路径的逻辑功能，但实际的故障比较器或采样电路可能已损坏。BIST无法覆盖模拟前端本身的失效。
• 行动：BIST是必要的，但不是充分的诊断。系统仍需依赖其他冗余监控或定期进行功能测试（如注入测试电压）来验证整个模拟检测链路的完整性。这是满足ASIL-D高诊断覆盖率要求时需要仔细设计的安全机制的一部分。

通过对BQ7961x-Q1故障管理机制的深入理解和系统化应用，工程师能够构建出响应迅速、诊断精准、符合功能安全最高等级要求的电池管理系统。这套机制的精髓在于硬件提供的丰富状态与灵活控制，结合软件层面的智能策略，共同守护着系统的安全底线。