当前位置：首页 > news >正文

TI Tiva C系列MCU SHA/MD5硬件加速器实战：HMAC优化与DMA配置

news 2026/7/22 11:00:00

1. 项目概述与核心价值

在嵌入式系统，尤其是那些对数据完整性和真实性有严苛要求的物联网终端、支付设备或安全启动模块中，哈希算法（Hash）和基于哈希的消息认证码（HMAC）是构建安全防线的基石。然而，在资源受限的MCU上，用纯软件实现SHA-1、SHA-256或MD5算法来处理大量数据，往往会成为系统性能的瓶颈，严重拖累响应速度和能效。这正是硬件加密加速器存在的意义——它将复杂的循环移位、逻辑运算和模加操作固化在硅片中，以远高于软件的速度完成计算，把CPU从繁重的密码学运算中解放出来。

我最近在基于TI Tiva C系列MCU的一个安全通信项目里，深度调用了其内置的SHA/MD5硬件加速器（SHAM）。官方手册虽然详尽，但超过百页的寄存器描述和时序图，对于快速上手和避坑而言，信息过于分散。特别是HMAC的密钥处理流程、多轮哈希的上下文保存与恢复，以及如何高效利用DMA进行数据搬运，这些实战中的关键细节，往往需要反复试验才能摸清门道。本文将结合我的实际调试经验，为你拆解这个硬件加速器的核心工作机制，重点聚焦于HMAC密钥的硬件预处理、哈希过程的灵活控制，以及轮询、中断、DMA三种操作模式的实战配置。无论你是正在评估该模块，还是已经使用但遇到了性能或稳定性问题，相信这些从寄存器位操作到系统级集成的细节，都能提供直接的参考。

2. 硬件加速器核心机制与寄存器精解

要驾驭这个硬件模块，不能只停留在调用API的层面，必须理解其内部的数据流和控制逻辑。整个SHA/MD5加速器的核心可以看作一个高度可配置的“计算管道”，我们通过一组特定的寄存器向这个管道注入数据（消息或密钥）、下达指令（算法、模式），并取出结果（摘要）。

2.1 核心寄存器组：数据与状态的容器

模块的寄存器大致分为四类：数据输入寄存器、摘要/密钥寄存器、控制与状态寄存器，以及系统配置寄存器。其中，最需要深入理解的是摘要/密钥寄存器组，它们在哈希和HMAC操作中扮演着多重角色。

SHA_DATA_n_IN (n=0~15): 这是16个32位寄存器组成的64字节数据输入FIFO。无论你要计算哈希的消息是什么，都必须以64字节（512位）为一块，按顺序填充到这组寄存器中。数据写入必须遵循小端（Little-Endian）格式，即消息的第一个字节放在SHA_DATA_0_IN的[7:0]位。

SHA_IDIGEST_A 至 SHA_IDIGEST_H 与 SHA_ODIGEST_A 至 SHA_ODIGEST_H: 这16个寄存器是模块的“心脏”，功能随操作模式动态变化，理解其角色映射是正确编程的关键。

在普通哈希（HMAC_KEY_PROC=0）且非初始常量（ALGO_CONSTANT=0）时：它们用作中间上下文寄存器。当你进行一个多轮（多次写入64字节数据块）的哈希计算时，前一轮计算产生的中间摘要值就存储在这里。在下一轮开始前，你需要将这些值作为“初始摘要”写回对应的寄存器，哈希才能继续。例如，对于SHA-256，你需要操作A到H共8个寄存器。
在HMAC密钥处理（HMAC_KEY_PROC=1）时：这组寄存器变身为HMAC密钥输入寄存器。你需要将完整的HMAC密钥（或填充后的密钥）按小端格式写入SHA_IDIGEST_A至SHA_IDIGEST_H（高256位）和SHA_ODIGEST_A至SHA_ODIGEST_H（低256位）。这里有一个极易出错的细节：如果密钥长度不是512位，硬件不会自动填充！你必须手动用零将剩余的密钥寄存器位补足至512位。对于长度超过512位的密钥，你需要先用哈希算法（如SHA-256）对原始密钥计算一次哈希，然后将这个哈希结果（必然是256位或更短）用零填充到512位，再写入寄存器。
在读取最终结果时：操作完成后，最终的哈希摘要或HMAC结果将从SHA_ODIGEST_A开始的寄存器中读出。对于MD5，读取A到D；SHA-1读取A到E；SHA-224/256则读取A到H。

实操心得：寄存器的“人格分裂”刚开始接触时，很容易混淆这些寄存器在何时是何角色。我的记忆方法是：IDIGEST（Inner Digest）通常关联“内部”状态或输入（如HMAC密钥的高位、哈希中间上下文），ODIGEST（Outer Digest）通常关联“外部”输出或输入的低位部分。在代码中，为不同的操作阶段定义清晰的寄存器访问宏或函数，能极大减少错误。

2.2 控制寄存器：SHA_MODE 的位魔法

SHA_MODE寄存器是整个模块的指挥中枢，几个关键位决定了完全不同的操作行为：

ALGO[2:0]: 算法选择。000对应MD5，001保留，010对应SHA-1，100对应SHA-224，110对应SHA-256。务必注意，某些值（如011,101,111）是保留的，误写可能导致不可预料的行为。
ALGO_CONSTANT: 这是开始一次全新哈希的开关。当此位置1时，硬件会自动用对应哈希算法的标准初始常量（如SHA-256的0x6a09e667,0xbb67ae85等）填充SHA_IDIGEST_x寄存器，并将SHA_DIGEST_COUNT清零。如果你是在继续一个已有的哈希（多轮计算）或进行HMAC操作，此位必须设为0，并手动载入正确的中间上下文或密钥。
CLOSE_HASH: 消息结束标志。当处理最后一块数据（可能不足64字节）时，必须将此位置1，硬件会自动按照FIPS 180-4等标准添加填充位（一个0x80字节、长度信息等）。如果此位为0，则意味着哈希尚未结束，你传入的数据块必须是严格的64字节，否则填充逻辑错乱会导致摘要错误。
HMAC_KEY_PROC: HMAC密钥处理使能。这是实现HMAC性能优化的关键。置1后，硬件会将之前写入SHA_IDIGEST_x/SHA_ODIGEST_x的512位数据视为HMAC密钥，并执行ipad和opad的异或及预哈希计算，结果（即内/外摘要预计算值）存回原寄存器。此位在操作完成后会自动清零。
HMAC_OUTER_HASH: 外哈希使能。在HMAC操作中，当内哈希（对key ^ ipad || message的哈希）计算完成后，需要紧接着计算外哈希（对key ^ opad || inner_hash的哈希）。通常，在单次操作中，我们在启动时同时设置CLOSE_HASH和HMAC_OUTER_HASH，让硬件一气呵成。如果是分步操作，则需在内哈希完成后，确保数据输入为空，再设置此位并触发一次零长度的计算来启动外哈希。

2.3 长度与计数寄存器：流程控制的关键

SHA_LENGTH: 写入本次操作要处理的数据总字节数。注意，这个长度是针对整个消息（或当前阶段消息）的，而不是单个块。写入此寄存器是触发硬件开始计算的最终动作。在CLOSE_HASH=0的中间轮次，长度必须是64的倍数。在最后轮次（CLOSE_HASH=1），长度是剩余数据的实际字节数。
SHA_DIGEST_COUNT: 这是一个双向寄存器。在启动一个需要载入上下文的操作时（ALGO_CONSTANT=0且HMAC_KEY_PROC=0），你需要向它写入之前已处理的数据总字节数（低6位必须为0）。操作完成后，从中读取的值是“已处理字节数 + 本次处理长度”，可用于保存上下文。在HMAC密钥处理或全新哈希时，硬件会自动处理它，通常无需手动写入。

3. HMAC密钥处理：从原理到性能优化实践

HMAC（Hash-based Message Authentication Code）结合了密钥和哈希算法，用于验证消息的完整性和真实性。其公式为：HMAC(K, m) = H((K ^ opad) || H((K ^ ipad) || m))。其中H是哈希函数，K是密钥，opad和ipad是固定的填充常量。

软件实现��要多次哈希调用，而硬件加速器的价值在于，它能将(K ^ ipad)和(K ^ opad)的预哈希计算（即内/外摘要预计算）固化到硬件流水线中，对于需要反复使用同一密钥认证大量消息的场景，性能提升是颠覆性的。

3.1 标准HMAC单次认证流程

假设我们要用SHA-256和密钥K对消息m进行一次HMAC计算，流程如下：

密钥准备与填充：如果K长度不等于SHA-256的块长度（64字节），则需要填充或哈希。例如，一个32字节的密钥，我们需要将其后填充32字节的零，组成64字节，然后按小端格式写入SHA_IDIGEST_A-H和SHA_ODIGEST_A-H。
启动密钥处理：配置SHA_MODE寄存器，ALGO=110(SHA-256)，HMAC_KEY_PROC=1，ALGO_CONSTANT=0（因为我们已经手动写了密钥）。写入SHA_LENGTH=64（密钥块长度）。硬件开始工作，完成K ^ ipad和K ^ opad的哈希预计算，结果存回摘要寄存器。此时HMAC_KEY_PROC位自动清零。
处理消息（内哈希）：现在摘要寄存器里存的是H(K ^ ipad)。我们需要将其作为“初始摘要”继续计算H((K ^ ipad) || m)。因此，保持ALGO_CONSTANT=0，HMAC_KEY_PROC=0，将SHA_DIGEST_COUNT写为64（因为已处理了一个64字节的密钥块）。然后，将消息m分块写入SHA_DATA_n_IN，并在最后一块设置CLOSE_HASH=1和HMAC_OUTER_HASH=1。写入消息总长度到SHA_LENGTH触发计算。
获取结果：硬件会连续完成内哈希和外哈希。计算完成后，最终的HMAC结果就在SHA_ODIGEST_A-H寄存器中。

3.2 核心性能优化：密钥预计算与复用

官方手册和我的项目经验都强烈指出：HMAC密钥不会被硬件保留。这意味着，如果你需要对不同消息但使用相同密钥进行多次HMAC认证，每次都需要重复上述步骤1和2，即重新加载密钥并执行密钥处理。这相当于为每个消息额外付出了两个哈希块（密钥的ipad和opad处理）的计算时间。

优化策略是：将步骤2的“密钥处理”作为一个独立的前置操作。

执行一次仅密钥处理的操作（HMAC_KEY_PROC=1,CLOSE_HASH=0，HMAC_OUTER_HASH=0，LENGTH=64）。
操作完成后，立即将SHA_IDIGEST_x和SHA_ODIGEST_x寄存器中的值（即内/外摘要预计算值）保存到内存中。
在后续所有使用同一密钥的HMAC计算中，跳过密钥处理步骤。直接将这些保存的预计算值作为“初始上下文”加载到SHA_IDIGEST_x寄存器（对于内哈希），如果需要，SHA_ODIGEST_x也可以加载（但通常外摘要在内哈希完成后由硬件自动使用，除非分步操作）。然后从步骤3（处理消息）开始。

这样，对于同一密钥的第二次及以后的认证，你节省了两次哈希计算（约130个时钟周期，见性能表）。在需要高频认证的场景下，这种优化带来的吞吐量提升非常可观。

避坑指南：上下文保存与恢复的陷阱在多任务或中断可能打断哈希过程的系统中，你可能需要保存和恢复哈希的中间状态。需要保存的上下文包括：
SHA_IDIGEST_x寄存器组（当前中间摘要）。
SHA_DIGEST_COUNT寄存器（已处理的字节总数）。
SHA_LENGTH寄存器（剩余待处理的字节数？不，LENGTH是本次操作的总长度，通常不需要保存。需要保存的是消息的“剩余部分”）。实际上，更安全的做法是保存原始消息和已处理的偏移量。恢复时，将SHA_DIGEST_COUNT设置为已处理的字节数，重新加载SHA_IDIGEST_x，然后继续传入剩余的消息数据。务必确保恢复操作时ALGO_CONSTANT=0。

4. 哈希操作流程详解与模式选择

理解了寄存器，我们来看完整的哈希操作流程，它分为“启动新哈希”、“继续哈希”和“结束哈希”。

4.1 启动一个新哈希（例如MD5）

配置算法与初始化：向SHA_MODE写入，ALGO=000（MD5），ALGO_CONSTANT=1（使用初始常量），CLOSE_HASH=0（非最后块）。此操作会自动用MD5的初始常量填充摘要寄存器并清零计数器。
设置长度：向SHA_LENGTH寄存器写入本次要处理的数据块字节数。如果这不是最后一块，长度必须是64。写入此寄存器即触发硬件开始等待数据。
写入数据：将64字节的明文数据按小端格式写入SHA_DATA_0_IN到SHA_DATA_15_IN。
等待与轮询：硬件将数据移入内部缓冲区开始计算，此时INPUT_READY（SHA_IRQSTATUS[1]）会变低。计算完成后，OUTPUT_READY（SHA_IRQSTATUS[0]）变高，表示摘要就绪（对于中间轮次，这是中间摘要，存在SHA_IDIGEST_x中）。
继续或结束：如果是中间轮次，读取中间摘要，保存上下文。然后回到步骤2，设置新的LENGTH（下一个64字节），但这次ALGO_CONSTANT必须设为0，并手动将上一步的中间摘要写回SHA_IDIGEST_x寄存器，再写入数据。如果是最后一块（数据<=55字节，可以容纳填充位），则在步骤1设置CLOSE_HASH=1，LENGTH为剩余字节数（如23）。硬件会自动填充并完成计算，最终摘要从SHA_ODIGEST_x读出。

4.2 处理非对齐消息尾块

这是最容易出错的地方。哈希要求消息总长度填充至64字节的整数倍。填充规则是：先补一个0x80字节，再补零，最后8字节存放原始消息长度的位表示。

情况一：最后一块数据 ≤ 55字节。例如最后剩23字节。将这23字节数据写入，并设置CLOSE_HASH=1，LENGTH=23。硬件会在这23字节后追加0x80、40个零字节（因为23+1+40=64），以及8字节的长度信息，然后在一个64字节块内完成计算。
情况二：最后一块数据 > 55字节但 < 64字节。例如最后剩60字节。60字节已经无法在同一个64字节块内容纳填充（60+1+8 > 64）。此时流程是： a. 将这60字节作为一块数据传入，设置CLOSE_HASH=0，LENGTH=60（注意，虽然不足64，但CLOSE_HASH=0时长度仍必须为64？不，这里是个关键！当CLOSE_HASH=0时，你传入的数据必须正好填满64字节的输入缓冲区。对于不足64字节的非最后块，你需要手动补零至64字节再传入，并记住实际长度。更好的做法是，总是用CLOSE_HASH=1来处理最后一块，无论其大小）。 b. 实际上，正确的做法是：对于最后一块（60字节），直接设置CLOSE_HASH=1和LENGTH=60。硬件会自动识别这种情况。它会先处理这60字节（此时缓冲区未满），然后硬件内部会自动再消耗一个额外的、全为填充的64字节块来完成计算。这意味着从主机角度看，你只提交了一次60字节的数据，但硬件会进行两次哈希计算。SHA_DIGEST_COUNT最终读出的值是60（原始消息长度），但硬件内部经历了两个块的运算。

4.3 三种操作模式实战配置

硬件支持轮询、中断和DMA三种模式来传递数据和接收通知。

1. 轮询模式这是最简单直接的模式，适用于低数据率或简单应用。

流程：配置好模式和长度后，循环检查SHA_IRQSTATUS[1] (INPUT_READY)。当它为1时，向SHA_DATA_n_IN写入64字节数据。然后等待SHA_IRQSTATUS[0] (OUTPUT_READY)变为1，读取结果。重复直到所有数据处理完。
优点：无需配置中断或DMA，代码简单。
缺点：CPU被长时间阻塞在等待状态，效率低下。

2. 中断模式适合需要异步处理、提高CPU利用率的场景。

配置：在SHA_SYSCONFIG寄存器中设置IT_EN=1，使能中断。在MCU的中断控制器中配置好SHA中断向量。
流程：
- 启动操作后，当输入缓冲区空（INPUT_READY=1）或输出结果就绪（OUTPUT_READY=1）时，硬件会产生中断。
- 在中断服务程序（ISR）中，首先读取SHA_IRQSTATUS判断中断源。
- 如果是INPUT_READY，则写入下一块数据。
- 如果是OUTPUT_READY，则读取摘要结果，并可能进行后续处理（如启动下一轮或通知主程序）。
注意事项：中断处理要快，避免丢失数据。对于高速数据流，中断开销可能仍然较大。

3. DMA模式这是处理大量数据（如网络数据包、文件流）时的终极性能方案。硬件通过uDMA控制器与内存直接交换数据，完全解放CPU。

全局初始化： a. 使能SHA模块的时钟（通过RCGCCCM寄存器）。 b. 在uDMA通道映射寄存器（DMACHMAPn）中，将特定的DMA通道分配给SHA的“数据输入”请求。 c. 执行一次软件复位（SHA_SYSCONFIG.SOFTRESET），等待复位完成（SHA_SYSSTATUS.RESETDONE=1）。 d. 在SHA_SYSCONFIG中设置DMA_EN=1，使能DMA请求。 e. 配置uDMA通道：设置源地址（内存中的数据缓冲区）、目标地址（SHA_DATA_0_IN）、传输数据量（必须是64字节的倍数，除非是最后一块且配合CLOSE_HASH），并配置为基本模式或Ping-Pong模式。
操作流程：
- 配置好SHA_MODE和SHA_LENGTH。
- 启动uDMA传输。DMA控制器会自动将内存中的数据块搬运到SHA_DATA_n_IN寄存器。
- 硬件每处理完一个块，会自动发出下一个DMA请求，直到所有指定长度的数据传输完毕。
- 最终计算完成，通过中断或轮询OUTPUT_READY位来读取结果。
核心优势：CPU只需进行初始配置和最终结果处理，中间的数据搬运由DMA硬件完成，系统吞吐量达到硬件极限。在我的项目中，使用DMA模式处理连续数据流，CPU占用率几乎为零，而哈希计算速度完全取决于加速器本身的时钟周期。

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

在实际开发中，你一定会遇到计算结果不对、模块不响应、DMA卡住等问题。下面是我踩过的一些坑和解决方法。

问题1：计算得到的哈希值/ HMAC值完全错误。

可能原因A：字节序问题。硬件要求所有数据（输入消息、密钥、初始向量）都是小端格式。如果你的源数据是大端格式，或者在内存中以大端方式存储，必须在写入寄存器前进行字节序转换。一个常见的错误是直接将一个32位整数指针指向的数据内存拷贝到SHA_DATA_n_IN，而忽略了端序。
排查：对一个已知标准测试向量（如空字符串的SHA-256）进行计算。确保你的输入数据每个32位字内的字节顺序是正确的。
可能原因B：密钥填充错误。对于HMAC，如果密钥不是64字节，你必须手动补零。手册明确写道“the core does not pad”。如果你只写了密钥的前32字节，后面的寄存器是随机值或上次操作残留值，必然导致错误。
排查：在写入密钥后，读取SHA_IDIGEST_x和SHA_ODIGEST_x寄存器，确认所有512位（16个32位寄存器）的值都符合预期（密钥部分+零填充部分）。
可能原因C：CLOSE_HASH标志使用不当。在中间轮次错误地设置了CLOSE_HASH=1，会导致提前填充和结束。在最后轮次忘记设置CLOSE_HASH=1，则不会进行填充，摘要自然错误。
排查：仔细检查你的多轮计算流程中，每一轮SHA_MODE寄存器的配置，特别是CLOSE_HASH和ALGO_CONSTANT位。

问题2：模块不开始计算，INPUT_READY始终为0。

可能原因A：SHA_LENGTH寄存器写入时机不对。SHA_LENGTH是触发信号。你必须先配置好SHA_MODE（算法、模式等），最后写入SHA_LENGTH。如果先写长度再写模式，模块可能处于未定义状态。
可能原因B：上下文未正确加载。在ALGO_CONSTANT=0的模式下（继续哈希或HMAC），你必须先向SHA_IDIGEST_x寄存器写入正确的初始摘要值，并且向SHA_DIGEST_COUNT写入正确的已处理字节数，然后才能配置SHA_MODE和SHA_LENGTH。顺序错误会导致硬件使用错误的初始状态。
标准流程：1) 写SHA_IDIGEST_x（如果需要）；2) 写SHA_DIGEST_COUNT（如果需要）；3) 写SHA_MODE；4) 写SHA_DATA_n_IN（数据）；5)最后写SHA_LENGTH。

问题3：DMA传输启动后，SHA模块没有发出请求或卡住。

可能原因A：DMA通道未正确映射。TI的芯片中，外设的DMA请求需要映射到具体的uDMA通道。你必须查阅芯片数据手册，找到SHA数据输入请求对应的具体映射值，并正确写入DMACHMAPn寄存器。
可能原因B：SHA_SYSCONFIG配置遗漏。除了设置DMA_EN=1，还需要确保SDAM_EN（如果存在，用于使能特定DMA功能）位被正确设置。有些版本的手册可能用不同名称。
可能原因C：DMA传输大小与哈希块大小不匹配。在CLOSE_HASH=0的中间轮次，DMA传输量必须是64字节的整数倍。如果传输了非64倍数的数据，模块会等待更多数据填满缓冲区，而DMA认为传输已完成，导致死锁。
排查：使用调试器检查SHA_IRQSTATUS寄存器的状态位。检查uDMA通道的控制寄存器，确认传输是否完成、是否有错误。在DMA初始化后、启动哈希前，可以尝试先使用轮询模式写入一块数据，测试硬件本身是否工作正常。

问题4：在多任务系统中，哈希上下文被破坏。

场景：一个低优先级任务正在进行一个长消息的哈希计算，被高优先级任务打断。等高优先级任务返回，发现哈希结果错误。
解决方案：在任务切换时，必须保存和恢复SHA模块的完整“上下文”。这不仅仅是SHA_IDIGEST_x寄存器。至少包括：
1. SHA_IDIGEST_A-H（当前中间摘要）。
2. SHA_DIGEST_COUNT（已处理的字节数）。
3. 未处理的消息数据。这是最容易忽略的。如果中断发生在你刚向SHA_DATA_n_IN写入部分数据但还未触发计算时，这部分数据可能丢失。更安全的架构是：在应用层，将“已处理偏移量”和“原始消息”作为上下文保存。恢复时，从偏移量处重新开始流程，而不是依赖硬件缓冲区的瞬时状态。

调试技巧：利用性能计数器与状态寄存器SHA_SYSSTATUS寄存器中的RESETDONE位可以确认模块是否处于就绪状态。在性能分析时，可以参考手册中的“Cycles per block”表格。例如，SHA-256处理一个64字节块需要65个时钟周期。如果你测量发现实际耗时远大于此，瓶颈很可能在数据供给（CPU或DMA速度）而非计算本身。这时就应考虑优化数据搬运路径，或采用DMA模式。

最后，分享一个我个人的编码习惯：为SHA模块的操作封装一个清晰的状态机。将“初始化”、“加载密钥”、“处理数据块”、“结束哈希”等步骤封装成独立的函数，并用一个结构体来维护当前操作的上下文（算法、模式、已处理长度、中间摘要等）。这样不仅代码更清晰，在调试和实现多实例、可重入的哈希操作时，也会轻松很多。硬件加速器是性能利器，但只有深入理解其机理，才能用得稳、用得好。

查看全文

http://www.jsqmd.com/news/1240734/