1. CRC控制器与DMA协同工作模式深度解析

在嵌入式系统开发，尤其是涉及高可靠性数据存储、通信或固件安全的场景里，数据完整性校验是基石。循环冗余校验（CRC）作为一种高效、可靠的错误检测方法，其硬件实现——CRC控制器，极大地解放了CPU。但仅仅有硬件计算单元还不够，如何让CRC校验过程高效、实时且不阻塞主程序运行，才是工程实践中的核心挑战。这就引出了CRC控制器与直接内存访问（DMA）控制器的协同工作模式，以及与之紧密耦合的中断机制。

简单来说，你可以把CRC控制器想象成一个专业的“数据验算员”，DMA是负责搬运数据的“快递员”，而CPU则是“项目经理”。在理想状态下，项目经理（CPU）只需要下达初始指令（配置好验算规则和搬运路线），之后验算员（CRC）和快递员（DMA）就能自动配合，完成大批量数据的校验工作。只有当出现“货物损坏”（CRC校验失败）、“快递积压”（数据溢出）或“超时未送达”（处理超时）等异常情况时，快递员或验算员才会通过“对讲机”（中断）呼叫项目经理来处理。这种架构将CPU从繁重的数据搬运和循环计算中彻底解脱出来，使其能够专注于更上层的业务逻辑，同时确保了数据校验的实时性和系统响应能力。

德州仪器（TI）等厂商的微控制器中集成的CRC模块，通常支持多种工作模式，以适应不同系统资源（有无DMA）和实时性要求。理解这些模式及其对应的中断触发条件，是设计稳定、高效校验系统的关键。本文将结合实践，深入拆解AUTO、Semi-CPU和Full-CPU三种核心模式的工作流程、中断机制，并分享配置要点与避坑指南。

2. 三种核心工作模式详解

CRC控制器的工作模式决定了数据流如何被送入CRC计算单元，以及校验结果如何被比对和处理。模式的选择直接影响了系统架构、CPU负载和实时性表现。

2.1 AUTO模式：全自动后台校验

AUTO模式是自动化程度最高、对CPU干预需求最低的模式。在此模式下，CRC控制器与DMA深度绑定，形成一个完整的自动化校验流水线。

工作流程与数据流：

1. 初始化配置：CPU需要配置好DMA的两个通道。通常，通道A负责将待校验的源数据（例如Flash的某个扇区）搬运至CRC控制器的PSA签名寄存器；通道B则负责将预存的、正确的CRC期望值搬运至CRC控制器的CRC值寄存器。
2. 启动与计算：配置完成后，一旦使能AUTO模式，CRC控制器会自动向DMA通道B请求第一个期望值。同时，一个外部的硬件事件（如定时器触发）会启动DMA通道A的数据搬运。数据开始源源不断地流入PSA寄存器并进行实时CRC计算。
3. 比对与中断：当一个“扇区”的数据（数量由PATTERN_COUNT定义）计算完成后，CRC控制器会自动将PSA寄存器中计算出的实时签名，与通过DMA通道B预先写入CRC值寄存器的期望签名进行比对。
4. 结果处理：
   • 比对成功：静默进入下一个扇区的计算，CPU无感知。
   • 比对失败（CRC Fail）：CRC控制器立即置位CRC失败状态标志，并产生CRC Fail中断。此时，当前扇区号会被锁存在“当前扇区寄存器”中，直到CPU读取该寄存器并清除失败标志，该寄存器才会解冻并记录新的错误扇区。

核心价值与适用场景：AUTO模式完美实现了“后台静默校验”。CPU仅在系统启动时完成配置，之后便可完全不管校验过程，直到发生错误。这非常适用于对内存进行周期性、后台的完整性扫描（如Flash的ECC/CRC巡检），或对高速通信数据流（如以太网、CAN-FD）进行实时校验。它确保了错误能被第一时间发现，同时CPU开销几乎为零。

注意：在AUTO模式下，确保DMA通道B（负责搬运期望值）的数据源（如存储正确CRC值的数组）与DMA通道A的数据分区严格对应，是正确工作的前提。任何错位都会导致持续的误报。

2.2 Semi-CPU模式：折中的协同校验

Semi-CPU模式是一种分工协作的模式。CRC控制器和DMA负责最繁重的数据搬运和计算工作，而将最终的结果比对任务交给CPU。

工作流程与职责划分：

1. 初始化配置：CPU配置DMA（通常只需一个通道），将待校验数据搬运至CRC控制器的PSA签名寄存器。不需要配置DMA来搬运期望值。
2. 计算与通知：DMA搬运数据，CRC控制器进行计算。当一个扇区的数据计算完成后，CRC控制器会产生一个“压缩完成中断”，并自动将当前扇区的计算结果从PSA寄存器拷贝到专用的“PSA扇区签名寄存器”中。
3. CPU介入比对：CPU响应中断，在中断服务程序（ISR）中读取“PSA扇区签名寄存器”，然后自行与存储在某处的预期签名进行比对，并做出相应处理（如记录日志、触发修复等）。

核心价值与适用场景：Semi-CPU模式适用于那些校验策略更灵活，或期望值存储格式比较特殊的场景。例如，系统可能需要将计算出的CRC签名先存储到另一个非易失性存储器中，构建一个“数据指纹库”，而不是立即比对。或者，CPU需要根据不同的上下文，采用不同的比对策略。此模式将计算和比对解耦，赋予了CPU更大的控制权，同时仍然由DMA承担数据搬运的重负。

实操心得：Semi-CPU模式的关键在于中断响应速度。因为CRC计算是连续的，如果CPU没有及时读取“PSA扇区签名寄存器”，下一个扇区的计算结果就会覆盖它，从而触发Overrun中断。在设计时，需要评估最坏情况下的中断延迟，并确保ISR足够精简。

2.3 Full-CPU模式：完全由CPU主导

Full-CPU模式是最基础的模式，适用于没有DMA控制器或校验数据量极小的低成本系统。

工作流程：CPU完全负责所有工作：从内存读取数据，写入CRC控制器的PSA签名寄存器，并在所有数据计算完成后，读取最终的CRC结果，再与期望值进行比对。

核心价值与适用场景：此模式硬件依赖最小，但效率也最低。它仅适用于极低频、小数据块的校验任务，或者在系统开发初期进行功能验证。对于任何连续或大批量的数据校验，都应避免使用此模式，因为它会长时间占用CPU，导致系统实时性变差。

模式选择决策表：

3. 五大中断机制深度剖析与配置

中断是CRC控制器与CPU通信的生命线。每种中断都对应着一种特定的系统状态或异常，理解其触发条件和处理逻辑至关重要。

3.1 CRC Fail中断：数据完整性告警

这是AUTO模式下最重要的中断，直接宣告数据校验失败。

触发条件： 在AUTO模式下，当一个扇区的数据计算完成，CRC控制器将PSA中的实时签名与CRC值寄存器中的期望签名进行比对，若不一致，则立即触发此中断。

硬件行为：

1. CRC失败状态标志位被置位。
2. 当前扇区寄存器被“冻结”，其内容锁定为发生错误的扇区号。
3. 中断信号产生。

软件处理流程（ISR内必须完成）：

1. 读取错误信息：立即读取“当前扇区寄存器”，获取发生错误的扇区号，进行记录或上报。
2. 清除错误状态：向CRC失败状态标志位写入清零操作（具体方式取决于寄存器设计，通常是写1清零或写0清零）。
3. 解冻寄存器：仅清除状态位可能不够。根据手册，必须读取一次已被冻结的“当前扇区寄存器”，才能使其解冻，准备接收下一个可能的错误扇区号。这是一个关键细节！
4. 错误恢复：根据系统策略，尝试修复该扇区数据、标记坏块、或启动系统安全恢复流程。

避坑指南：CRC Fail中断和Overrun中断有直接关联。如果CPU没有及时处理完一个CRC Fail中断（即未完成上述“读取-清除”流程），而此时另一个扇区又发生了校验失败，那么新的错误扇区号将无法写入仍被冻结的“当前扇区寄存器”。此时，CRC控制器不会产生第二个CRC Fail中断，而是会产生一个Overrun中断，告知CPU发生了错误堆积。因此，CRC Fail的ISR必须设计得高效快速。

3.2 Overrun中断：系统响应能力的“黄牌”

Overrun中断是一个流量控制或系统过载的指示信号，在AUTO和Semi-CPU模式下均可能发生。

在AUTO模式下的触发条件： 如前所述，当CRC Fail中断未被及时处理，导致“当前扇区寄存器”持续被冻结，此时若发生新的校验失败，则触发Overrun中断。

在Semi-CPU模式下的触发条件： 当CRC控制器完成一个扇区计算，将签名拷贝到“PSA扇区签名寄存器”并发出Compression Complete中断后，如果CPU未能及时读取该寄存器，而DMA和CRC控制器已经完成了下一个扇区的计算并准备写入新签名，此时就会发生覆盖，并触发Overrun中断。

处理逻辑：Overrun中断本身不直接指示数据错误，而是指示“通知机制”出现了拥堵。处理此中断时，软件应：

1. 检查CRC Fail状态位，确认是否有未处理的校验错误。
2. 检查“当前扇区寄存器”或“PSA扇区签名寄存器”的状态。
3. 强化错误处理流程，或优化系统设计以降低中断延迟。这可能意味着需要提高CRC Fail中断的优先级，或者优化Semi-CPU模式下的ISR，使其能在下一个扇区计算完成前执行完毕。

3.3 Underrun中断：数据流“断粮”警告

Underrun中断仅发生在AUTO模式，它表示CRC控制器“饿”了。

触发条件： 在AUTO模式下，CRC控制器预期DMA会按照设定的节奏（由PATTERN_COUNT和SECTOR_COUNT定义）送来数据并与期望值同步比对。如果在某个扇区的数据模式计数器减到零时，DMA未能及时将对应的期望值更新到CRC值寄存器，CRC控制器就无法进行签名比对。这种“数据未就绪”的状态会触发Underrun中断。

根本原因与排查： 这通常意味着DMA的配置或触发源出现了问题。例如：

• 负责搬运期望值的DMA通道优先级过低，被其他高优先级传输长时间阻塞。
• 触发DMA的硬件事件（如定时器）意外停止。
• DMA传输链配置错误，导致传输提前结束。 处理Underrun中断需要检查DMA相关配置和状态，确保数据供应流水线的畅通。

3.4 Timeout中断：系统健康的“看门狗”

Timeout中断是保障系统实时性的关键机制。它通过两个独立的超时预加载寄存器CRC_WDTOPLDx（看门狗超时）和CRC_BCTOPLDx（块完成超时）来实现双重监控。

超时计数器工作原理： CRC控制器内部有一个24位递减超时计数器，时钟源为HCLK/64。

1. 第一阶段（看门狗超时）：当使能AUTO或Semi-CPU模式后，计数器首先加载CRC_WDTOPLDx的值并开始递减。此阶段监控“DMA是否及时启动”。如果在计数器减到零之前，没有任何数据模式被传输到PSA寄存器，则触发Timeout中断。这确保了DMA传输能及时开始。
2. 第二阶段（块完成超时）：一旦有第一个数据到来，计数器会立即重新加载CRC_BCTOPLDx的值，并重新开始递减。此阶段监控“一个数据块是否在规定时间内处理完”。如果在计数器再次减到零之前，未能完成一个完整块（PATTERN_COUNT * SECTOR_COUNT）的数据压缩，则触发Timeout中断。一个块完成后，计数器又 reloadCRC_WDTOPLDx值，循环往复。

配置计算示例： 假设系统HCLK = 200 MHz，预分频为64，则超时计数器时钟周期 = 1 / (200MHz / 64) = 0.32 µs。

• 若要求DMA必须在模式使能后10ms内开始传输数据，则：CRC_WDTOPLDx= 10 ms / 0.32 µs ≈31250
• 若要求每个数据块（如128个模式 * 8个扇区）必须在4ms内处理完毕，则：CRC_BCTOPLDx= 4 ms / 0.32 µs ≈12500

处理逻辑：Timeout中断意味着数据处理流程未能满足预设的实时性要求。可能的原因包括：DMA被高优先级任务长时间占用、总线拥塞、甚至系统死锁。处理此中断需要检查系统负载和DMA状态，并可能需要采取恢复措施，如重启DMA传输或上报系统健康度警告。

3.5 Compression Complete中断：Semi-CPU模式的节拍器

此中断仅存在于Semi-CPU模式，是CPU进行结果处理的“发令枪”。

触发条件： 当PATTERN_COUNT计数器递减至零，即一个扇区的数据计算完成时触发。

软件职责： CPU在响应该中断的ISR中，必须完成两件事：

1. 读取结果：从“PSA扇区签名寄存器”中读取刚计算好的CRC签名。
2. 及时响应：必须在下一个扇区计算完成、新签名准备覆盖寄存器之前完成读取，否则会引发Overrun中断。

4. 实战配置：从寄存器到代码

理解了原理，我们通过一个典型的AUTO模式应用场景，来看如何将理论转化为实际的寄存器配置和代码。

场景：我们需要对一片2MB的Flash区域进行后台CRC校验，每1KB（128个64位双字）为一个扇区，共2048个扇区。使用定时器每10ms触发一次DMA传输，要求每个数据块（128*2048？这里通常是一个扇区即一个块，具体看设计）在4ms内完成计算。

4.1 硬件与外设配置

1. DMA通道配置（假设使用两个通道）：

   • 通道1（搬运期望值）：
     • 源地址：存储预计算CRC值的数组首地址。
     • 目的地址：CRC控制器的CRC_REGL1/H1寄存器（通道1的CRC值寄存器）。
     • 传输大小：64位。
     • 源地址模式：递增（每次传输后指向下一个期望值）。
     • 目的地址模式：固定（始终写入同一对寄存器）。
     • 触发源：硬件请求（来自CRC控制器，当需要新期望值时自动触发）。
   • 通道2（搬运待校验数据）：
     • 源地址：待校验Flash区域首地址。
     • 目的地址：CRC控制器的PSA_SIGREGL1/H1寄存器（通道1的PSA签名寄存器）。
     • 传输大小：64位。
     • 元素计数：128（一个扇区的双字数）。
     • 帧/块计数：2048（扇区总数）。
     • 源地址模式��递增。
     • 目的地址模式：固定。
     • 触发源：硬件请求（来自一个通用定时器，配置为每10ms产生一次DMA请求）。

2. 定时器配置：

   • 配置一个通用定时器，使其产生周期为10ms的脉冲输出，该输出连接到DMA通道2的硬件请求线。

4.2 CRC控制器寄存器配置

以下是基于TI TMS570系列等ARM Cortex-R芯片的寄存器配置思路（具体寄存器名称可能因型号而异）：

// 假设 CRC 控制器基地址为 CRC_BASE // 1. 配置模式与控制 (CRC_CTRL0) // 选择通道1，CRC-32多项式，64位数据大小，不进行字节/位交换 uint32_t ctrl0_value = 0; ctrl0_value |= (2 << 3); // CH1_CRC_SEL[1:0] = 0b10, 选择CRC-32 (假设，具体查手册) // CH1_CRC_SEL2 位根据手册与DW_SEL组合，此处假设为0 ctrl0_value |= (0 << 1); // CH1_DW_SEL[1:0] = 0b00, 选择64位数据大小 // CH1_BIT_SWAP和CH1_BYTE_SWAP保持为0 write_reg(CRC_BASE + CRC_CTRL0_OFFSET, ctrl0_value); // 2. 配置模式寄存器，使能AUTO模式 (假设在CRC_CTRL2寄存器中) // 假设 CH1_MODE[1:0] = 0b01 代表 AUTO 模式 uint32_t ctrl2_value = read_reg(CRC_BASE + CRC_CTRL2_OFFSET); ctrl2_value &= ~(0x3 << CH1_MODE_SHIFT); // 先清零模式位 ctrl2_value |= (1 << CH1_MODE_SHIFT); // 设置为AUTO模式 write_reg(CRC_BASE + CRC_CTRL2_OFFSET, ctrl2_value); // 3. 配置数据块大小 write_reg(CRC_BASE + CRC_PCOUNT_REG1_OFFSET, 128 - 1); // 模式计数，通常写入N-1 write_reg(CRC_BASE + CRC_SCOUNT_REG1_OFFSET, 2048 - 1); // 扇区计数，通常写入N-1 // 4. 配置超时 // 计算超时预加载值 (HCLK = 200MHz, 预分频64) uint32_t hclk_period_ns = 5; // 5ns (1/200MHz) uint32_t timeout_clock_period_ns = hclk_period_ns * 64; // 320ns uint32_t wdt_pl_value = 10000000 / timeout_clock_period_ns; // 10ms / 320ns ≈ 31250 uint32_t bct_pl_value = 4000000 / timeout_clock_period_ns; // 4ms / 320ns ≈ 12500 write_reg(CRC_BASE + CRC_WDTOPLD1_OFFSET, wdt_pl_value); write_reg(CRC_BASE + CRC_BCTOPLD1_OFFSET, bct_pl_value); // 5. 使能所需中断 (CRC_INTS 中断使能置位寄存器) uint32_t int_enable = 0; int_enable |= (1 << CRC_FAIL_INT_BIT); // 使能CRC失败中断 int_enable |= (1 << OVERRUN_INT_BIT); // 使能超限中断 int_enable |= (1 << UNDERRUN_INT_BIT); // 使能欠载中断 int_enable |= (1 << TIMEOUT_INT_BIT); // 使能超时中断 write_reg(CRC_BASE + CRC_INTS_OFFSET, int_enable); // 6. 最后，释放可能存在的软件复位，并启动 (假设通过CTRL寄存器某位启动) // 例如，清除CH1_PSA_SWREST位 ctrl0_value = read_reg(CRC_BASE + CRC_CTRL0_OFFSET); ctrl0_value &= ~(1 << CH1_PSA_SWREST_SHIFT); write_reg(CRC_BASE + CRC_CTRL0_OFFSET, ctrl0_value);

4.3 中断服务程序（ISR）实现要点

void CRC_Channel1_ISR(void) { // 1. 读取中断偏移寄存器，确定具体中断源 uint32_t int_offset = read_reg(CRC_BASE + CRC_INT_OFFSET_REG_OFFSET); switch(int_offset) { case OFFSET_CRC_FAIL: // 例如 0x01 handle_crc_fail(); break; case OFFSET_OVERRUN: // 例如 0x11 handle_overrun(); break; case OFFSET_UNDERRUN: // 例如 0x19 handle_underrun(); break; case OFFSET_TIMEOUT: // 例如 0x21 handle_timeout(); break; default: // 处理未知或phantom中断 break; } // 2. 清除CRC模块内部的中断状态标志 (具体操作取决于寄存器设计) // 例如，向中断状态寄存器的对应位写1清零 write_reg(CRC_BASE + CRC_STATUS_REG_OFFSET, (1 << (int_offset >> 1))); // 假设映射关系 // 3. 必要时，清除中断控制器中的中断挂起位 } void handle_crc_fail(void) { // 1. 读取当前错误扇区号 uint32_t bad_sector = read_reg(CRC_BASE + CRC_CURSEC_REG1_OFFSET); LOG_ERROR("CRC Fail at sector: %lu", bad_sector); // 2. 清除CRC失败状态标志 (假设写0到状态寄存器某位) uint32_t status = read_reg(CRC_BASE + CRC_STATUS_REG_OFFSET); status &= ~(1 << CRC_FAIL_STATUS_BIT); write_reg(CRC_BASE + CRC_STATUS_REG_OFFSET, status); // 3. 关键步骤：读取当前扇区寄存器以解冻它 (即使值已读过，再读一次) volatile uint32_t dummy = read_reg(CRC_BASE + CRC_CURSEC_REG1_OFFSET); (void)dummy; // 防止编译器优化 // 4. 执行错误恢复策略，如标记坏扇区、尝试修复、系统降级等 system_error_recovery(bad_sector); }

5. 常见问题排查与调试技巧

在实际项目中，配置CRC和DMA协同工作时，难免会遇到问题。以下是一些常见故障现象和排查思路。

5.1 问题一：无法进入中断

• 现象：配置完成后，数据在传输，但预期的中断（如CRC Fail）从未触发。
• 排查步骤：
  1. 中断使能检查：确认CRC控制器的具体中断使能位（CRC_INTS）已正确设置。
  2. 系统中断控制器配置：确认CPU的中断控制器（如NVIC）中，对应CRC中断的通道已使能，并设置了合适的优先级。
  3. 全局中断开关：确认在启动CRC/DMA前，已打开CPU的全局中断（如Cortex-M的__enable_irq()）。
  4. 硬件信号路径：使用调试器或示波器检查CRC模块的中断输出信号是否确实产生。这可以隔离是模块问题还是系统配置问题。
  5. 仿真模式影响：在连接调试器进行单步调试时，某些芯片的仿真挂起（SUSPEND）信号会冻结超时计数器并可能影响中断产生。尝试全速运行看是否触发。

5.2 问题二：持续触发Overrun中断

• 现象：在Semi-CPU模式下，频繁进入Overrun中断。
• 排查步骤：
  1. ISR执行时间：测量Compression Complete中断服务程序的执行时间。确保它远小于一个扇区数据的计算传输时间。一个扇区的处理时间 ≈ (PATTERN_COUNT* 数据大小) / (DMA传输带宽)。如果ISR中进行了复杂操作（如写Flash、复杂计算），就会导致响应不及时。
  2. 中断优先级：提高CRC中断的优先级，确保它能抢占其他可能长时间关闭中断的代码段。
  3. DMA传输速率：检查DMA的触发频率是否过高。降低定时器触发频率，给CPU留出更长的响应时间窗口。
  4. 模式理解：确认你是否真的需要在Semi-CPU模式下做实时比对。如果不需要，考虑切换到AUTO模式，让硬件自动比对。

5.3 问题三：Timeout中断误报或频繁触发

• 现象：系统看似正常，但频繁进入Timeout中断。
• 排查步骤：
  1. 超时值计算：复核CRC_WDTOPLDx和CRC_BCTOPLDx的计算公式。确认HCLK频率和预分频系数（通常是64）是否正确。
  2. 系统时钟：确认系统时钟配置是否与软件假设一致。有时低功耗模式会切换时钟源，导致HCLK频率变化，从而使超时计算失准。
  3. DMA性能：检查DMA传输是否真的能在预设时间内完成。可能存在总线仲裁延迟、访问慢速存储器（如外部Flash）等情况。使用DMA传输完成中断或状态位来测量实际传输耗时。
  4. 计数器禁用：如果不需要超时功能，确保将两个超时预加载寄存器设置为0，以禁用超时计数器。

5.4 问题四：CRC校验结果始终失败或不确定

• 现象：即使数据确定无误，CRC Fail中断仍持续触发，或计算结果与预期不符。
• 排查步骤：
  1. 多项式与初始值：确认CRC控制器配置的多项式、初始值、输入/输出反转（bit/byte swap）设置是否与生成期望值所用的软件算法完全一致。这是最常见的原因。
  2. 数据对齐与大小：确认DW_SEL（数据字大小选择）设置是否正确（如64位、32位）。检查DMA传输的数据宽度是否与此匹配。不匹配会导致数据被错误地分段或组合。
  3. 字节序问题：检查BYTE_SWAP和BIT_SWAP配置。不同的存储体系（大端/小端）和传输协议可能需要不同的交换设置。
  4. 期望值数据源：在AUTO模式下，确认DMA搬���的期望值数组内容正确，且与内存扇区一一对应，没有错位。
  5. PSA软件复位：在启动一次新的CRC计算序列前，是否通过PSA_SWREST位对PSA签名寄存器进行了复位？残留的上一次计算结果会影响本次计算。

5.5 调试技巧：利用原始数据寄存器

许多CRC控制器提供RAW_DATAREG（原始数据寄存器）。当CRC失败时，该寄存器可能锁存导致失败的那个数据模式。在CRC Fail中断中读取这个寄存器，可以与源内存中的数据进行比较，帮助定位是哪个具体数据出错了，这对于诊断间歇性内存错误或数据传输错误极具价值。

CRC控制器与DMA的协同，是现代嵌入式系统实现高效、可靠数据完整性保护的典范。它不仅仅是一个硬件功能，更是一种系统级的架构思想。成功的应用离不开对三种工作模式的深刻理解，对五种中断机制的精准把握，以及对寄存器配置每个细节的仔细推敲。