TI TMS470Mx CRC超时中断机制：嵌入式数据校验的时序守护者

1. 项目概述与超时中断的核心价值

在嵌入式系统开发，尤其是涉及高可靠性数据存储或通信的场景里，数据完整性校验是基石。我们常说的CRC（循环冗余校验）就是干这个的，它像一位沉默的“数据审计员”，默默地对流经的数据进行多项式运算，生成一个简短的校验值。这个值本身不携带业务信息，但却是数据在传输或存储过程中是否“完好无损”的铁证。从Flash存储的坏块检测到CAN总线上的报文校验，再到网络协议栈的帧校验序列，CRC无处不在。然而，传统的CRC校验流程往往是一个“事后诸葛亮”的角色——数据传完了，算一下，不对再报错。这在很多实时性要求高的系统里是不够的，比如一个后台运行的、持续校验大块内存区域的场景，如果DMA传输卡住了，或者CRC计算引擎因为某些原因停滞了，系统可能很久之后才发现问题，这对于需要确定性响应的系统来说是致命的。

这就是为什么像TI TMS470Mx这类微控制器中的高级CRC控制器，会引入一个非常关键但容易被忽视的机制：超时中断。它把CRC从一个被动的校验单元，升级成了一个主动的、带有时序监控能力的“安全卫士”。简单来说，超时中断机制为CRC操作设置了两道“时间红线”：第一道，监控DMA是否按时开始传输数据块（看门狗超时）；第二道，监控一个完整的数据块是否在限定时间内完成CRC计算（块完成超时）。一旦超时，立即中断CPU，让你能第一时间介入处理，而不是傻等。这对于构建健壮的、可预测的嵌入式应用至关重要，尤其是在汽车电子、工业控制这些对功能安全有要求的领域。接下来，我们就深入拆解这个机制的运作原理、配置方法，以及如何在工程中用好它。

2. 超时中断机制深度解析：双计时器协同监控

要理解超时中断，不能只看中断本身，必须把它放到CRC控制器与DMA协同工作的完整链条里去看。这个机制的核心是两个独立的、可编程的24位递减计数器，以及它们背后精妙的切换逻辑。

2.1 核心寄存器：CRC_WDTOPLDx 与 CRC_BCTOPLDx

所有时序监控的基准都源于这两个预加载值寄存器。它们是24位的，意味着你可以设置一个非常宽泛的超时范围。但这里有个关键细节：这个超时计数器的时钟源并不是系统主时钟（HCLK）直接驱动的。根据手册描述，它由一个固定的64分频器（Prescaler）提供时钟。也就是说，超时计数器的时钟频率 = HCLK / 64。

为什么要这么设计？我个人的理解是出于功耗和精度的平衡。CRC校验通常是后台、低频次的任务，用高频时钟去驱动一个可能设置到几十毫秒级别的计数器，不仅浪费功耗，还可能导致计数器过快溢出（24位计数器在高速时钟下能计的时间很短）。除以64后，时钟变慢，相同的计数器位数就能覆盖更长的超时时间，同时降低了动态功耗。例如，当HCLK为200MHz时，超时计数器时钟为200MHz / 64 = 3.125MHz，周期为0.32微秒。一个24位计数器（最大值16,777,215）能计时的最大时间约为16.78百万 * 0.32微秒 ≈ 5.37秒。这个范围对于大多数嵌入式场景的块传输监控来说，已经足够用了。

计算超时预载值：这是配置的第一步，也是容易出错的地方。公式很简单，但必须理解：预载值 = 期望的超时时间（秒） / （1 / HCLK频率 * 64）或者更直观地：预载值 = 期望的超时时间（秒） * （HCLK频率 / 64）以手册中的例子为例，HCLK=200MHz，期望超时5ms：预载值 = 0.005秒 * （200,000,000 Hz / 64） = 0.005 * 3,125,000 = 15,625这个15625就是你要写入CRC_BCTOPLDx寄存器的值。务必注意：这个值是写入递减计数器的初始值，计数器从这个值开始向下减到0。所以，你设定的时间就是计数器从预载值减到0所花费的时间。

2.2 双阶段监控流程与状态切换

这是整个机制最精妙的部分，它不是一个简单的倒计时，而是一个在两个预载值之间根据外部事件动态切换的状态机。

1. 阶段一：等待数据传输启动（看门狗超时监控）

   • 触发条件：当CRC通道被设置为AUTO模式或Semi-CPU模式后，超时计数器会立即自动加载CRC_WDTOPLDx（看门狗超时预载值）并开始递减。
   • 监控目标：这个阶段监控的是DMA对CRC控制器数据请求的响应速度。在AUTO模式下，CRC控制器会主动向DMA发出传输请求。这个计时器就是在问：“DMA，我让你送数据过来，你多久能开始送？”
   • 成功条件：在计数器递减到0之前，如果有任何一个数据模式（Pattern）被DMA传输到CRC控制器的PSA签名寄存器，则视为DMA响应及时。
   • 动作：一旦第一个数据到达，计数器立即停止当前递减，并重新加载为CRC_BCTOPLDx（块完成超时预载值），然后从这个新值开始递减。监控阶段进入下一环节。
   • 失败条件：如果直到计数器减到0，都没有任何数据到来，则立即触发超时中断。这通常意味着DMA通道配置错误、优先级太低被其他通道抢占、或者触发源（如定时器）失效。

2. 阶段二：监控数据块压缩完成（块完成超时监控）

   • 触发条件：如上所述，由第一个数据的到达触发，计数器加载CRC_BCTOPLDx值。
   • 监控目标：这个阶段监控的是完整一个数据块（Pattern Count × Sector Count）被CRC引擎计算完成所需的时间。它监控的是CRC计算本身的速度，或者说是数据持续供给的速率是否跟得上。
   • 成功条件：在计数器递减到0之前，CRC控制器完成了当前设定“块大小”（一个Sector）所有数据的压缩计算。
   • 动作：当一个Sector的数据全部压缩完成后，计数器会再次自动加载CRC_WDTOPLDx值，并开始递减，等待下一个数据块的第一个数据的到来。如此循环往复，只要数据流正常，计数器就会在WD预载值和BC预载值之间来回切换。
   • 失败条件：如果在计数器减到0时，当前Sector的数据还未全部压缩完，则触发超时中断。这可能意味着总线带宽不足、CRC计算引擎故障，或者DMA传输中途停顿。

关键理解：CRC_WDTOPLDx监控的是“数据流开始的及时性”，而CRC_BCTOPLDx监控的是“数据流持续的稳定性”。两者共同确保了从“请求”到“完成”整个链条的时效性。

2.3 超时中断的禁用与优先级

这个机制也提供了灵活性。如果你在某些不需要严格时序监控的场景下使用CRC（比如单次、手动的校验），可以将CRC_WDTOPLDx和CRC_BCTOPLDx都设置为0。当预载值为0时，手册明确说明计数器被禁用，不会产生任何超时中断。这让你可以按需启用或关闭此功能。

当超时中断与其他CRC中断（如CRC计算完成、CRC校验失败、上溢/下溢）同时发生时，需要通过**中断偏移寄存器（CRC_INT_OFFSET_REG）**来识别具体的中断源。根据手册提供的映射表，超时中断的优先级是相对较高的（偏移量0x21-0x24），仅次于幻象中断和CRC校验失败中断。在中断服务程序（ISR）中，读取这个寄存器就能快速定位到是哪个通道发生了超时，从而进行针对性的处理。

3. 超时中断的三种典型应用场景与配置实战

手册里给了几个例子，但我们可以结合更实际的工程场景来深化理解。超时中断的配置与CRC控制器的工作模式（AUTO, Semi-CPU, Full-CPU）紧密相关，我们重点看前两种，因为Full-CPU模式由CPU直接搬运数据，超时意义不大。

3.1 场景一：后台内存巡检（AUTO模式 + 定时器触发）

这是最经典的应用，也是手册示例22.4.1描述的场景。想象一个汽车电子的控制单元，需要在后台持续校验Flash中存储的标定数据或程序代码，确保没有因辐射等原因发生位翻转。

• 需求：连续校验2MB内存区域，每1KB（128个64位数据）为一个校验单元，与预存的2048个正确CRC值比对。
• 系统组件：CRC控制器（通道1）、DMA（两个通道）、定时器。
• 超时策略设计：
  • CRC_WDTOPLD1（看门狗超时）：定时器每10ms触发一次DMA传输请求。我们必须确保DMA能在这10ms内开始传输下一个1KB的数据块。因此，这个值应该略小于定时器周期，例如设置为9ms。这为DMA的响应和启动留出了1ms的余量。如果DMA在9ms内都没开始传第一个数据，说明系统可能已严重过载或故障。
  • CRC_BCTOPLD1（块完成超时）：我们希望每个1KB数据块的CRC计算能在5ms内完成。这个时间需要你根据总线带宽和CRC计算速度来估算。假设总线足够快，CRC计算是流水线的，那么主要时间是数据传输。如果64位总线传输128个双字（1KB）的理想时间远小于5ms，那么这个5ms就是一个安全裕度，用于应对偶尔的总线拥塞。
• 配置步骤：
  1. DMA配置：通道2源地址指向待校验内存，目标地址固定为CRC1的PSA寄存器，设置传输计数（元素=128，帧=2048）。通道1源地址指向预存CRC值表，目标地址固定为CRC1的值寄存器。
  2. 定时器配置：产生周期为10ms的DMA请求，链接到DMA通道2。
  3. CRC控制器配置：

     // 假设 HCLK = 200MHz #define HCLK_FREQ_HZ 200000000UL #define PRESCALER_DIV 64UL #define TIMEOUT_CLK_HZ (HCLK_FREQ_HZ / PRESCALER_DIV) // 3.125 MHz // 计算预载值 uint32_t wdt_timeout_ms = 9; // 看门狗超时9ms uint32_t bct_timeout_ms = 5; // 块完成超时5ms CRC_WDTOPLD1 = (uint32_t)((wdt_timeout_ms / 1000.0) * TIMEOUT_CLK_HZ); CRC_BCTOPLD1 = (uint32_t)((bct_timeout_ms / 1000.0) * TIMEOUT_CLK_HZ); // 设置模式、Pattern Count和Sector Count CRC_PCOUNT_REG1 = 128 - 1; // 注意：有些硬件计数值可能需要-1，需查具体手册 CRC_SCOUNT_REG1 = 2048 - 1; // 使能AUTO模式和超时中断 CRC_CTRL2 |= (AUTO_MODE << CH1_MODE_POS); // 设置通道1为AUTO模式 CRC_INTS |= (1 << CH1_TIMEOUTENS); // 使能通道1超时中断

• 运作与中断处理：系统启动后，CRC控制器自动请求DMA通道1获取第一个参考CRC值，同时定时器触发DMA通道2开始传输数据。数据流启动，超时计数器在WD预载值和BC预载值间切换。如果一切正常，CRC控制器自动比对并只在校验失败时中断CPU。一旦发生超时中断，CPU进入ISR，读取中断偏移寄存器确认是通道1超时，然后就需要分析日志：是WD超时（DMA启动问题）还是BC超时（数据传输/计算卡顿）？并可能需要重启DMA和CRC通道。

3.2 场景二：事件触发的数据包校验（AUTO模式 + 软件触发）

这种场景下，没有固定的时间节拍，数据块的传输由特定事件（如收到网络帧、传感器数据就绪）触发。

• 需求：每当一个完整的应用层数据包到达缓冲区（假设为1KB），立即启动CRC校验，并与包内自带的校验和比对。
• 系统组件：CRC控制器、DMA（两个通道）。无定时器。
• 超时策略设计：
  • CRC_WDTOPLDx：由于是事件触发，DMA应在事件发生后“尽快”启动。这个值可以设得比较小，比如1-2ms，用于捕获DMA系统严重异常。
  • CRC_BCTOPLDx：这个值取决于你对单包CRC计算耗时的要求。如果系统实时性要求高，可以设置为一个紧逼的时限（如500μs）。如果只是保证最终正确性，可以设长一些或直接禁用（设为0）。
• 配置差异：DMA通道2配置为单次传输（Frame Count=1），并由CPU在数据包就绪后发起软件请求。CRC控制器仍为AUTO模式。超时中断用于确保即使在高负载下，单次校验任务也不会被无限期挂起。

3.3 场景三：CPU参与的半自动校验（Semi-CPU模式）

在这种模式下，DMA负责搬数据，但CRC计算完成后的签名比对（或处理）工作由CPU完成。

• 需求：CPU需要实时获取每一块数据的CRC结果，用于构建哈希表或实时分析，但又不希望被数据搬运拖累。
• 超时关注点：此时，CRC_BCTOPLDx的超时监控依然有效，确保DMA传输和CRC计算不超时。但更重要的是，CPU需要在下一个Sector的数据覆盖当前结果之前，及时读取PSA_SECSIGREGx（Sector签名寄存器），否则会触发上溢（Overrun）中断。超时中断和上溢中断在这里是互补的：一个监控“算得慢”，一个监控“读得慢”。
• 配置提示：在Semi-CPU模式下，CRC_WDTOPLDx的逻辑与AUTO模式类似。你需要仔细评估CPU中断响应时间和处理时间，合理设置CRC_BCTOPLDx，并确保在压缩完成中断服务程序中，读取签名寄存器的操作足够快。

4. 超时中断相关寄存器详解与编程注意事项

要玩转超时中断，除了两个预载寄存器，还必须熟悉几个关键的控制和状态寄存器。手册里表格很多，我挑最核心的讲。

4.1 控制寄存器：CRC_CTRL2 与 CRC_INTS

• CRC_CTRL2 (通道控制寄存器)：你需要在这里设置通道的工作模式。对于启用超时中断的应用，通常选择01（AUTO模式）或10（Semi-CPU模式）。特别注意：在AUTO模式下，CRC控制器会自动管理DMA请求和签名比对，超时中断是其健康状态监控的一部分。模式位一般在上电初始化时设置一次，运行时不要频繁改动。
• CRC_INTS (中断使能置位寄存器)：这是使能中断的地方。超时中断对应每个通道的CHx_TIMEOUTENS位。重要特性：这是一个“置位使能”寄存器。写1到对应位会使能该中断，写0无效。要禁用中断，需要操作另一个寄存器（通常是CRC_INTR，中断使能清除寄存器，如果提供的话），或者直接向CRC_INTS的对应位写0（根据具体模块设计，需确认）。读取该位返回当前中断使能状态。务必在配置完超时参数、启动DMA之前使能中断。

4.2 状态寄存器：CRC_STATUS 与 CRC_INT_OFFSET_REG

• CRC_STATUS (状态寄存器)：当超时中断发生时，对应通道的CHx_TIMEOUT状态位会被硬件置1。这是一个粘滞位（Sticky Bit），即使中断条件消失，它也会保持为1，直到软件明确写入1来清除它。在中断服务程序中，除了处理超时事件，必须记得清除这个状态位，否则退出中断后会立即再次进入。

  void CRC_Timeout_ISR(void) { uint32_t int_offset = CRC_INT_OFFSET_REG & 0xFF; // 读取中断源 if(int_offset == CH1_TIMEOUT_OFFSET) { // 假设通道1超时偏移量为0x21 // 1. 处理超时：记录日志、重启通道、置错误标志等 handle_timeout_error(CHANNEL_1); // 2. 清除中断状态位 (通常写1清0，具体看手册) CRC_STATUS |= (1 << CH1_TIMEOUT_POS); // 假设写1清除 // 3. 可选：清除中断标志位（如果有独立的中断标志寄存器） // 4. 重启CRC通道（参考手册22.3.10.7 Error Handling步骤） restart_crc_channel(CHANNEL_1); } // ... 处理其他通道中断 }

• CRC_INT_OFFSET_REG (中断偏移寄存器)：如前所述，这是多中断源共享一个中断线时的“侦探”。在ISR中首先读取它，就能知道当前最高优先级的中断是什么。超时中断的偏移值固定（如通道1是0x21），查表即可。

4.3 超时中断的使能与禁用流程

这是一个标准的操作序列，混乱的顺序可能导致中断丢失或误触发：

1. 初始化阶段（禁用中断）：

   • 配置CRC_WDTOPLDx和CRC_BCTOPLDx。
   • 配置CRC_PCOUNT_REGx和CRC_SCOUNT_REGx。
   • 配置CRC_CTRL2选择模式（如AUTO）。
   • 此时，确保CRC_INTS中的超时中断位是0（禁用）。

2. 启动前准备：

   • 配置好DMA和触发源（如定时器）。
   • 如果需要，为CRC通道设置种子值（通过Data Capture模式写入PSA寄存器后，再切回AUTO模式）。

3. 启动与使能中断：

   • 使能DMA通道。
   • 使能定时器等触发源。
   • 最后，写1到CRC_INTS寄存器的CHx_TIMEOUTENS位，使能超时中断。这个顺序很重要，避免设备一启动，计数器就开始跑，而你的系统还没准备好，导致立即误触发超时。

4. 关闭与复位：

   • 要停止监控，先向CRC_INTS对应位写0（或使用清除寄存器）禁用中断。
   • 然后停止DMA和触发源。
   • 如果需要复位CRC通道，按照手册22.3.10.7的步骤操作（写软件复位位、切模式、再切回、释放复位）。

5. 工程实践中的常见问题与调试技巧

超时中断用好了是利器，用不好就是烦恼之源。下面是我在实际项目中踩过的一些坑和总结的经验。

5.1 超时值计算不准与系统时钟变更

• 问题：超时时间设得太短，在正常负载下也频繁误报；设得太长，失去了监控意义。更隐蔽的是，产品在不同工作模式（如低功耗模式）下，HCLK频率可能会变化，导致基于固定频率计算的超时值实际时间严重偏离。
• 对策：
  1. 理论估算与实测结合：先用理论公式计算。对于CRC_BCTOPLDx，估算时间应 > (数据量 × 传输周期) + CRC计算延迟 + 系统调度余量。然后在实际系统负载下进行测试，用逻辑分析仪或高端定时器测量实际的数据块传输与计算时间，根据实测结果调整。
  2. 动态配置：如果系统存在多种时钟频率，在切换时钟后，必须重新计算并配置CRC_WDTOPLDx和CRC_BCTOPLDx的值。最好将超时配置作为时钟配置函数的一部分。
  3. 留足裕量：对于CRC_WDTOPLDx（看门狗超时），其值应显著小于DMA请求的周期。例如，定时器10ms触发一次，看门狗超时可设为8ms。这确保了是DMA响应慢，而不是等下一个周期。

5.2 中断服务程序（ISR）处理不当

• 问题1：未清除状态位。这是最常见的问题，导致中断连续触发，系统卡死在ISR中。
• 问题2：ISR处理时间过长。超时中断是紧急事件，ISR内应只做最必要的处理：记录错误码、置位全局标志、可能的话复位通道。复杂的恢复逻辑（如重试、切换备份）应放到主循环或低优先级任务中。
• 问题3：未区分超时类型。在ISR中，除了读偏移寄存器，还应检查CRC_STATUS确认是哪个通道，并通过分析计数器状态或上下文，判断是WD超时还是BC超时。两者的处理策略可能不同：WD超时可能需检查DMA配置和触发源；BC超时可能需检查总线负载或内存访问速度。
• 建议的ISR模板：

  volatile uint8_t g_crc_ch1_timeout_flag = 0; // 全局标志 volatile uint32_t g_crc_last_timeout_type = 0; // 可记录超时类型 void CRC_IRQHandler(void) { uint32_t int_src = CRC_INT_OFFSET_REG; uint32_t status = CRC_STATUS; switch(int_src) { case CH1_TIMEOUT_OFFSET: // 判断超时类型（需结合业务逻辑，例如检查DMA传输计数） if(/* 条件：DMA传输未启动 */) { g_crc_last_timeout_type = TIMEOUT_TYPE_WATCHDOG; } else { g_crc_last_timeout_type = TIMEOUT_TYPE_BLOCK_COMPLETE; } g_crc_ch1_timeout_flag = 1; // 通知主循环 CRC_STATUS |= (1 << CH1_TIMEOUT_POS); // 清除状态位 // 可选：立即重启通道或等待主循环处理 // restart_crc_channel(CHANNEL_1); break; case CH1_CRCFAIL_OFFSET: // 处理CRC校验失败 handle_crc_fail(); CRC_STATUS |= (1 << CH1_CRCFAIL_POS); break; // ... 其他中断 default: break; } // 清除模块级中断标志（如果有） }

5.3 与DMA、定时器的协同故障

超时中断常常指向的是DMA或定时器的问题。

• DMA优先级：在复杂的系统中，多个DMA通道可能竞争总线。如果CRC相关的DMA通道优先级设置过低，可能会被持续抢占，导致传输缓慢，触发BC超时。检查并适当提高该DMA通道的优先级。
• 定时器配置错误：如果使用定时器触发，确保定时器的周期和CRC_WDTOPLDx匹配，并且定时器确实在运行并产生DMA请求。用示波器测量定时器输出或DMA请求信号是直接的验证方法。
• 内存访问冲突：如果DMA源/目标地址指向的内存区域（如Flash）访问有特殊等待周期，或被其他总线主控（如另一个CPU核）占用，会极大拖慢传输速度，导致BC超时。确保内存访问路径畅通。

5.4 调试方法与工具使用

当超时中断频繁触发时，系统化的调试很重要：

1. 隔离测试：首先，尝试将CRC_BCTOPLDx设置为一个非常大的值（或0禁用），只测试CRC_WDTOPLDx。如果还超时，问题很可能在DMA启动环节。然后单独测试BC超时。
2. 使用调试器监控寄存器：在调试器中实时观察CRC_CURSEC_REGx（当前Sector计数）和PSA_SIGREGx的变化。如果发生BC超时，看CRC_CURSEC_REGx是否卡住不动，这可能是DMA传输停了。如果还在变化但很慢，可能是总线带宽问题。
3. 逻辑分析仪/系统跟踪：这是最强大的工具。抓取DMA请求、DMA应答、总线访问、CRC计算完成等信号的时间线。你可以清晰地看到数据流在哪里出现了大的间隙，从而定位瓶颈。
4. 软件模拟与日志：在超时ISR中，记录下发生超时时的系统tick、DMA剩余传输计数、CPU负载等信息。积累多次超时的日志，有助于发现规律（是否在特定任务运行时发生）。

超时中断机制是嵌入式系统迈向高可靠性的一个具体体现。它要求开发者不仅关注功能正确，还要关注时序正确。理解其双计时器状态机的工作模式，精心计算和配置超时参数，并妥善处理中断，就能让这个机制从“麻烦的报错器”变成“可靠的守护者”，为你的数据完整性校验任务保驾护航。在实际项目中，我建议在开发早期就集成超时监控，并将其超时事件纳入系统的统一错误管理和恢复框架中，这样在后期集成测试和现场问题排查时，你会感谢自己当初多做的这一步。