MSPM0 AES硬件加速器实战：从原理到DMA优化与安全应用

1. 项目概述与AES硬件加速器核心价值

在嵌入式系统，尤其是物联网设备的设计中，数据安全已经从“加分项”变成了“必选项”。无论是设备间的通信、固件的安全启动，还是用户数据的本地存储，加密都是不可或缺的一环。然而，对于资源受限的微控制器而言，在软件层面实现复杂的加密算法，如AES（高级加密标准），往往会消耗大量的CPU周期和内存，直接影响到系统的主业务逻辑性能和实时性。这就好比让一个精于计算的会计，同时去干搬运工的活儿，两边都干不好。

AES硬件加速器的出现，正是为了解决这个核心矛盾。它本质上是一个专用的协处理器，被集成在微控制器内部，专门用来高效地执行AES算法的加密和解密运算。当主CPU需要进行AES操作时，它只需将密钥、数据和配置参数“交代”给这个硬件模块，然后就可以去处理其他任务了。硬件加速器会独立、并行地完成所有复杂的轮变换计算，完成后通过中断或DMA通知CPU来取结果。这个过程，就像你有一个专门负责加密解密的“秘书”，你只需要把要处理的文件（数据）和保险柜密码（密钥）给他，他就能在后台默默处理好，完全不影响你手头正在写的报告（主程序）。

德州仪器MSPM0 L系列微控制器中集成的AESADV模块，就是一个非常典型的嵌入式级硬件加密加速器。它不仅仅是一个基础的AES-ECB引擎，更是一个支持多种主流工作模式（如CBC, CTR, GCM）和认证模式（如CMAC, CCM）的完整解决方案。对于从事物联网终端、智能家居、工业传感节点开发的工程师来说，深入理解并熟练运用这个模块，意味着能在不增加额外芯片成本和外设的前提下，为产品构建起坚实可靠的数据安全防线，同时保持系统整体的低功耗和高响应性。接下来，我们就从原理到实践，一步步拆解这个强大的安全引擎。

2. AESADV硬件加速器架构与核心原理深度解析

要高效地使用一个硬件模块，绝不能停留在“调用API”的层面，必须对其内部架构和运作机制有清晰的认识。MSPM0的AESADV模块并非一个黑盒，其设计体现了现代微控制器在安全与效率上的精巧平衡。

2.1 模块整体架构与数据流

从系统层面看，AESADV模块是一个挂载在芯片内部总线上的外设。它通过一组内存映射寄存器与CPU进行通信，同时具备与DMA控制器和密钥存储控制器（Keystore）交互的能力。其核心架构可以抽象为三个主要部分：配置接口、数据处理核心和数据缓冲区。

配置接口就是那一组我们通过软件读写的寄存器（CTRL, KEY0-7, IV0-3等）。CPU通过写入这些寄存器，来告诉加速器：“这次用256位的密钥”、“采用CBC模式加密”、“初始化向量是某个值”。这是软件驱动硬件的“控制面板”。

数据处理核心是模块的“心脏”，它内部包含两个主要的计算单元：

1. AES-ECB核心：这是执行标准AES轮运算的硬件电路。对于128位密钥，它执行10轮变换；对于256位密钥，则执行14轮。每一轮都包含字节替换（SubBytes）、行移位（ShiftRows）、列混合（MixColumns）和轮密钥加（AddRoundKey）操作。在硬件中，这些操作通过查找表和组合逻辑并行执行，速度极快。
2. 伽罗瓦域乘法器（GHASH核心）：这是一个专门用于执行GCM模式中认证部分计算的硬件单元。它能在32个时钟周期内完成一次128位的伽罗瓦域乘法。关键在于，在GCM模式下，当有数据可供处理时，这个乘法器可以与AES加密核心并行工作。例如，在加密第一个数据块的同时，GHASH核心可以开始处理关联数据（AAD），这种并行化设计大幅提升了GCM这种同时要求加密和认证的复杂模式的吞吐率。

数据缓冲区包括输入缓冲区和输出缓冲区。它们的作用是解耦CPU/DMA的数据传输速度与硬件核心的计算速度。CPU或DMA可以一次性写入128位（4个32位字）的待处理数据到输入缓冲区，然后核心开始计算。计算完成后，结果被放入输出缓冲区，等待CPU或DMA读取。这种双缓冲机制是实现连续数据流处理、发挥DMA效能的基础。

注意：理解“内存映射寄存器”这个概念至关重要。对工程师而言，AES_DATA0这个寄存器不是一个变量，而是芯片设计时固定在某个物理地址（比如0x4003_5000）上的一组触发器。我们通过C语言中的指针访问（如*(volatile uint32_t *)0x40035000）或厂商提供的驱动库函数，实际上是在通过芯片的内部总线向这个物理位置进行读写操作，从而直接操控硬件电路。

2.2 密钥加载的双重路径与安全考量

AESADV模块提供了两种密钥加载方式，这体现了其在安全设计上的层次性。

方式一：软件显式配置。这是最直接的方式，工程师通过代码依次向KEY0到KEY7寄存器写入密钥数据。对于256位密钥，需要写满8个寄存器；对于128位密钥，则只需写KEY0到KEY3。这种方式灵活，适用于密钥动态生成或从非安全存储区加载的场景。

方式二：通过密钥存储控制器（Keystore）安全初始化。这是更高级、更安全的方式。Keystore是芯片内一个独立的、常设计有物理防护的安全区域，用于存储根密钥、证书等敏感信息。当AES操作需要使用存储在Keystore中的密钥时，Keystore控制器会通过一条私有的、不与系统总线共享的安全内部总线，将密钥直接注入到AESADV模块的密钥寄存器中。整个传输过程由硬件控制，CPU无法窥探，密钥明文也绝不会出现在通用RAM或总线上，有效防止了基于软件的内存扫描或总线侦听攻击。

模块内部有一个状态位STATUS.KEYWR来标识当前密钥的加载状态。一旦通过Keystore完成了安全密钥加载，该位会被置1，此后软件对KEY0-KEY7寄存器的任何写操作都将被硬件忽略。这是一种硬件级的防篡改保护。如果你想改用软件加载密钥，必须复位整个AESADV模块，这会清除所有现有密钥和上下文。这个设计强制工程师在安全路径和非安全路径之间做出明确选择，避免了因代码逻辑错误导致的安全降级。

2.3 性能指标解读与真实场景预估

数据手册中给出的性能表格（如76周期完成128位加/解密）是在理想实验室条件下的峰值性能。作为一个有经验的嵌入式开发者，我们必须学会解读这些数字背后的现实意义。

以表格中“128位密钥，32MHz主频下加密耗时2.38μs”为例。这个76周期是如何构成的？它大致包括：数据从总线写入输入缓冲区的几个周期、核心执行10轮AES运算的周期（每轮约6-7个周期）、以及结果从核心传输到输出缓冲区的周期。这个速度确实很快，比纯软件实现快了两个数量级。

然而，在实际系统中，“系统开销”往往是性能的瓶颈。例如：

• 总线竞争：如果CPU和DMA同时争抢访问内存或外设，会导致AES模块读写数据时被阻塞（Stall），等待总线空闲。
• 中断延迟：在中断模式下，从AES模块产生“输出就绪”中断，到CPU响应中断、保存现场、跳转到中断服务程序（ISR）开始读取数据，这中间可能有数十甚至上百个周期的延迟。在此期间，AES模块的输出缓冲区满，无法开始下一块数据的处理，引擎处于空闲等待状态。
• DMA通道优先级与仲裁：如果为AES服务的DMA通道优先级较低，当高优先级DMA（如ADC数据采集）长时间占用总线时，AES的数据传输也会被延迟。

因此，在评估一个加密任务的真实耗时，尤其是涉及多块数据连续处理时，绝不能简单用块数 × 2.38μs来计算。你必须考虑系统的整体架构。最佳实践是启用DMA进行数据传输，并合理设置DMA通道优先级，让数据搬运在后台自动完成，使AES硬件引擎和DMA控制器形成高效的“生产-搬运”流水线，CPU只需在全部完成后处理一个完成中断，这样才能最大程度逼近理论性能。

3. 核心工作模式详解与工程选型指南

AES是一个分组密码算法，它本身只能加密一个固定长度的（128位）数据块。直接使用这种基本模式（称为ECB）存在严重的安全缺陷。因此，我们需要一系列“工作模式”来将AES安全地应用于任意长度的数据。AESADV支持多种模式，每种都有其特定的应用场景和优缺点。

3.1 电子密码本模式：为何不推荐使用？

ECB模式是最简单的模式：将明文分割成独立的128位块，每块用自己的密钥加密。解密过程亦然。它的最大问题是缺乏扩散性：相同的明文块总是产生相同的密文块。想象一下加密一张BMP格式的位图（其背景可能是大片的同一种颜色），ECB加密后的图片，虽然看起来杂乱，但依然可能保留大片的纹理图案，攻击者无需破解密钥就能获得大量信息。

在AESADV中，ECB模式通常仅作为其他复杂模式（如CBC、CTR）的一个内部构建块，或者用于加密完全随机、无模式的数据（这种情况极少）。在绝大多数实际应用中，应避免直接使用ECB模式加密有意义的数据。

3.2 密码分组链接模式：经典与可靠之选

CBC模式通过引入“链式”结构解决了ECB的模式重复问题。在加密时，第一个明文块先与一个随机生成的初始化向量进行异或，然后再加密。之后，每一个明文块在加密前，都会先与前一个密文块进行异或。这样，即使两个明文块完全相同，由于前一个密文块不同（它是随机的或依赖于更早的明文），加密后的结果也完全不同。

初始化向量至关重要。IV不需要保密，但必须是不可预测的（通常是一个密码学安全的随机数），并且对于同一个密钥，每次加密会话都必须使用一个新的IV。如果IV重复使用，会严重削弱CBC模式的安全性。在AESADV中，IV通过IV0-IV3寄存器加载。

CBC模式的一个特点是加密是串行的，无法并行化，因为加密第N块需要第N-1块的密文结果。但解密过程可以并行，因为解密时，是用当前密文块解密后，再与前一个密文块异或得到明文，而前一个密文块是已知的。CBC模式长期以来被广泛应用于SSL/TLS、磁盘加密等领域，是久经考验的可靠模式。

3.3 计数器模式：并行化与效率之王

CTR模式将分组密码转换成了一个流密码。它不再直接加密数据本身，而是加密一个“计数器”值来生成密钥流，然后将密钥流与明文进行异或得到密文。这个计数器通常由一个随机数和一个递增的计数值拼接而成。

CTR模式的巨大优势在于加解密都可以完全并行化。因为每一块的密钥流只依赖于“随机数+块序号”，与其他数据块无关。这意味着硬件可以预先计算多块密钥流，或者在处理大量数据时获得极高的吞吐率。同时，由于加解密是对称的（都是异或操作），加密和解密使用完全相同的硬件流程，简化了设计。

在AESADV中，CTR模式需要设置CTRL[CTR]=1，并通过CTRL[CTR_WIDTH]选择计数器宽度（如CTR32表示计数器部分为32位，可加密2^32个数据块）。必须确保“随机数”部分在同一个密钥下永不重复，否则会导致密钥流复用，安全性完全崩塌。

3.4 伽罗瓦/计数器模式：现代通信的集大成者

GCM模式是当今网络通信（如TLS 1.3, IPsec）中的明星。它实际上是CTR模式（用于加密）和GHASH认证（用于完整性校验）的结合体，一次性提供了保密性、完整性和身份认证。

其工作流程可以概括为：

1. 根据IV生成初始的计数器。
2. 使用CTR模式加密明文，产生密文。
3. 同时，将附加认证数据和密文一起，通过GHASH函数（基于伽罗瓦域乘法）进行计算，最终生成一个128位的认证标签。

接收方在解密后，会用同样的过程重新计算一个认证标签，并与发送方传来的标签进行比较。如果不匹配，则说明数据在传输过程中被篡改，接收方会直接丢弃数据，无需尝试解密。

AESADV对GCM的支持非常完善，支持“自主GCM”（内部计算H和Y0）、“H预计算”以及“纯GHASH”三种子模式。对于需要同时加密和认证的物联网设备通信数据包，GCM是首选。它的效率很高，因为认证和加密可以部分并行，并且它产生的密文长度与明文相同（认证标签是额外附加的），没有填充开销。

3.5 模式选择速查与实战建议

面对这么多模式，如何选择？这里有一个简单的决策指南：

实操心得：在资源极度受限且只需要保密性的场景（如传感器数据本地加密存储），CTR模式因其并行性和加解密对称性，通常是性能最佳的选择。如果需要与现有老系统兼容，则选CBC。而所有涉及网络传输或防止数据篡改的场景，应优先考虑GCM或CCM模式，绝不能只加密不认证。

4. MSPM0 AESADV模块的实战编程与DMA优化

理解了原理和模式，我们进入实战环节。如何用代码驱动这个硬件？我们将以最常见的CBC加密和GCM加密为例，展示从寄存器操作到DMA集成的完整流程。

4.1 基础单块操作：理解寄存器握手流程

在启用DMA等高级功能前，通过CPU轮询寄存器进行单块操作是理解模块工作流程的基础。以下是一个使用128位密钥进行CBC加密的伪代码流程，其中包含了关键的“握手”信号：

// 假设所有AES寄存器基地址已定义，如 AES_BASE // 1. 等待模块就绪，可接受新上下文配置 while(!(AES_CTRL & CNTXT_RDY_MASK)) { // 空循环等待，或可在此处加入超时处理 } // 2. 等待输入缓冲区就绪，可接受新数据 while(!(AES_CTRL & INPUT_RDY_MASK)) { // 等待 } // 3. 写入密钥 (128位，共4个32位寄存器) AES_KEY0 = key[0]; // 密钥最低字 AES_KEY1 = key[1]; AES_KEY2 = key[2]; AES_KEY3 = key[3]; // 密钥最高字 // 4. 写入初始化向量IV (128位) AES_IV0 = iv[0]; AES_IV1 = iv[1]; AES_IV2 = iv[2]; AES_IV3 = iv[3]; // 5. 配置控制寄存器：选择CBC模式、加密方向、128位密钥 uint32_t ctrl_value = 0; ctrl_value |= (1 << KEY_SIZ_POS); // 例如：01b 代表128位密钥 ctrl_value |= (1 << DIR_POS); // 1 代表加密 ctrl_value |= (1 << CBC_POS); // 使能CBC模式 // SAVE_CNTXT 位在此例中清零，表示不保存上下文用于后续操作 AES_CTRL = ctrl_value; // 6. 写入明文数据 (128位，共4个32位寄存器) AES_DATA0 = plaintext[0]; // 明文最低字 AES_DATA1 = plaintext[1]; AES_DATA2 = plaintext[2]; AES_DATA3 = plaintext[3]; // 明文最高字 // 写入DATA3会触发硬件开始计算 // 7. 等待输出缓冲区就绪 while(!(AES_CTRL & OUTPUT_RDY_MASK)) { // 等待计算完成 } // 8. 读取密文结果 ciphertext[0] = AES_DATA0; ciphertext[1] = AES_DATA1; ciphertext[2] = AES_DATA2; ciphertext[3] = AES_DATA3;

这个过程清晰地展示了模块的“请求-响应”式接口：配置上下文（密钥、IV、模式）-> 提供数据 -> 等待 -> 获取结果。CNTXT_RDY,INPUT_RDY,OUTPUT_RDY这些状态位是软件与硬件同步的关键。

4.2 使用DMA进行多块连续加密：以CBC模式为例

单块操作效率低下，因为CPU大部分时间在等待。对于加密一个完整的文件或数据包，必须使用DMA。下面我们详细拆解如何配置两个DMA通道来实现CBC模式下的连续加密。

步骤一：规划内存与DMA通道假设我们有N个128位明文块（即N*16字节）存储在SRAM的plaintext_buffer[]中，我们希望加密后的密文存储到ciphertext_buffer[]。

• DMA通道A（输入）：负责将plaintext_buffer中的数据搬运到AES模块的DATA_IN寄存器。
• DMA通道B（输出）：负责将AES模块DATA_OUT寄存器中的数据搬运到ciphertext_buffer。 需要确保这两个缓冲区在内存中连续且对齐良好（通常32位对齐即可）。

步骤二：配置AES模块以启用DMA握手在开始DMA传输前，需要告诉AES模块我们将使用DMA来传输数据，而不是CPU。

// 设置DMA握手使能位 AES_DMA_HS |= DMA_DATA_ACK_MASK;

这个设置会改变模块的行为：当输入缓冲区空时，它会自动触发DMA_TRIG0事件；当输出缓冲区有数据时，它会自动触发DMA_TRIG1事件。

步骤三：详细配置输出DMA通道（通道B）这是整个流程中最容易出错的一环。配置的目标是：每当AES输出一个32位字（即DATA_OUT寄存器就绪），DMA就自动将其搬走。

// 假设使用TI的DriverLib或类似库进行配置 DMA_ChannelHandle chB = DMA_openChannel(DMA_CHB); // 打开一个DMA通道 DMA_configMode(chB, DMA_MODE_SINGLE); // 单次触发模式，每来一个事件搬一次 DMA_configTrigger(chB, DMA_TRIG_SRC_AES_OUT); // 触发源：AES输出就绪事件 DMA_configSource(chB, (uint32_t)&AES_DATA_OUT, DMA_DATA_SIZE_32); // 源地址：AES_DATA_OUT寄存器，每次搬32位 DMA_configDestination(chB, (uint32_t)ciphertext_buffer, DMA_DATA_SIZE_32); // 目的地址：密文缓冲区 DMA_configTransferSize(chB, N * 4); // 总传输次数：N块 * 4字/块 DMA_configInterrupt(chB, DMA_INT_COMPLETE, enable); // 使能传输完成中断 DMA_enableChannel(chB); // 使能通道，等待触发

关键点在于DMA_TRIG_SRC_AES_OUT这个触发源选择，它需要与芯片数据手册中定义的事件编号匹配。

步骤四：详细配置输入DMA通道（通道A）输入通道的配置与输出对称，但触发逻辑相反：它需要等待AES输入缓冲区空的事件，然后搬送数据过去。

DMA_ChannelHandle chA = DMA_openChannel(DMA_CHA); DMA_configMode(chA, DMA_MODE_SINGLE); DMA_configTrigger(chA, DMA_TRIG_SRC_AES_IN); // 触发源：AES输入就绪事件 DMA_configSource(chA, (uint32_t)plaintext_buffer, DMA_DATA_SIZE_32); DMA_configDestination(chA, (uint32_t)&AES_DATA_IN, DMA_DATA_SIZE_32); DMA_configTransferSize(chA, N * 4); // 输入通道通常不需要完成中断，由输出通道的完成中断代表整个任务结束 DMA_enableChannel(chA);

步骤五：配置AES上下文并启动在DMA通道准备就绪后，CPU需要完成AES模块的初始配置，然后启动流程。

// 1. 写入密钥 (同单块操作) AES_KEY0 = key[0]; ... AES_KEY3 = key[3]; // 2. 写入IV AES_IV0 = iv[0]; ... AES_IV3 = iv[3]; // 3. 配置控制寄存器为CBC加密模式 AES_CTRL = (KEY_SIZE_128 | DIR_ENCRYPT | MODE_CBC); // 4. 写入总数据字节数！这是启动DMA传输的关键一步 AES_C_LENGTH_0 = (N * 16) & 0xFFFF; // 低16位 AES_C_LENGTH_1 = ((N * 16) >> 16) & 0xFFFF; // 高16位 // 写入长度寄存器后，AES模块立即进入就绪状态，等待输入数据。 // 此时，输入DMA通道（chA）在等待第一个TRIG0事件。

步骤六：等待完成与后处理CPU配置完成后即可进入低功耗模式或处理其他任务。当输出DMA通道（chB）完成所有N*4次传输后，会触发一个DMA完成中断。

// 在DMA通道B的完成中断服务函数中： void DMA_CHB_ISR(void) { // 1. 清除中断标志 DMA_clearInterrupt(DMA_CHB); // 2. 此时，ciphertext_buffer中已存有完整的N块密文。 // 3. 可以进行后续操作，如计算并验证MAC（如果是GCM），或通知主程序任务完成。 // 4. 如果需要，可以在这里读取AES模块的TAG寄存器（对于GCM/CMAC模式）。 post_process_task(); // 后处理任务 }

避坑指南：DMA配置的常见陷阱

1. 传输大小错误：最常见的错误是DMA_configTransferSize中设置的总传输次数不对。记住，AES每次处理128位（4个32位字），所以对于N块数据，总传输次数是N*4，而不是N。
2. 地址对齐问题：源地址和目的地址，特别是对AES_DATA_IN/OUT这类外设寄存器的访问，必须确保是32位对齐的。使用(uint32_t*)&reg进行强制转换是标准做法。
3. 触发源混淆：务必确认数据手册中DMA_TRIG0和DMA_TRIG1具体对应AES的输入就绪还是输出就绪事件。不同厂商或系列芯片的命名可能不同。
4. 启动顺序：一定要先配置并启用DMA通道，最后再写入AES的C_LENGTH寄存器。如果顺序反了，AES模块可能已经触发事件，但DMA还未准备好，导致数据流错乱。
5. 缓冲区溢出：确保plaintext_buffer和ciphertext_buffer的大小至少为N*16字节，并且内存区域没有其他冲突。

4.3 GCM模式实战：加密与认证的完整流程

GCM的配置比CBC/CTR更复杂，因为它涉及AAD（附加认证数据）和TAG（认证标签）的处理。以下是实现GCM加密的关键步骤解析：

1. 数据分区：你需要将输入数据明确分为两部分：AAD（只认证不加密，如数据包头）和PAYLOAD（既认证又加密，如数据载荷）。在内存中，它们通常需要连续存放，且AAD在前，PAYLOAD在后。

2. 寄存器配置关键点：

• 模式选择：CTRL[GCM]需设置为3（自主模式）。
• 启用TAG保存：CTRL[SAVE_CNTXT]需设置为1，这样在加密结束后，计算出的认证标签会保存在TAG0-TAG3寄存器中，而不是被丢弃。
• 长度设置：需要设置两个长度寄存器：
  • AAD_LENGTH：AAD数据的字节长度。
  • C_LENGTH_0/1：PAYLOAD（加密数据）的字节长度。切记：长度必须以字节为单位，且是原始数据的长度。

3. DMA配置调整：输入DMA通道的源地址应指向包含AAD和PAYLOAD的连续内存区，其传输总大小应为(AAD长度 + PAYLOAD长度) / 4（以字为单位）。输出DMA通道则只搬运PAYLOAD加密后产生的密文。

4. 操作流程：

// 伪代码流程 1. 配置AES密钥 (KEY0-KEY7)。 2. 配置GCM IV (写入IV0-IV3寄存器)。对于96位IV，通常写入IV0-IV2，IV3置0或特定值。 3. 将TAG寄存器（TAG0-TAG3）初始化为0（对于自主模式，有时可省略，但显式清零是好习惯）。 4. 配置CTRL寄存器：GCM模式、加密方向、密钥长度、SAVE_CNTXT=1。 5. 写入AAD_LENGTH和C_LENGTH。 6. 配置并启用输入/输出DMA通道（与CBC示例类似，但输入数据总量是AAD+PAYLOAD）。 7. 写入C_LENGTH寄存器（这一步会启动整个GCM运算流程）。 8. 等待DMA输出通道完成中断。 9. 中断服务程序中，从TAG0-TAG3寄存器读取128位的认证标签。这个标签需要和密文一起发送给接收方。

5. 认证验证：接收方使用相同的密钥、IV、AAD和接收到的密文，运行相同的GCM解密流程。解密后，它会自己计算出一个认证标签，并与发送方传来的标签进行比较。如果匹配，则说明数据完整且真实。

重要提示：GCM模式中，IV的重复使用是灾难性的。通常建议使用一个递增的计数器或真随机数生成器来产生每个消息的IV。对于96位IV，可以直接使用；对于非96位IV，需要经过GHASH运算生成一个128位的内部Y0，这在AESADV的“纯GHASH”模式下可以完成。

5. 高级话题：中断、低功耗与上下文保存

5.1 中断驱动 vs. DMA驱动

除了DMA，中断也是与AES模块交互的一种方式。模块可以产生INPUTRDY（输入就绪）和OUTPUTRDY（输出就绪）中断。

• 中断驱动模式：适用于数据块到达不规则、或CPU需要在每块数据处理间隙执行其他逻辑的场景。在中断服务程序中，CPU需要手动读写DATA0-DATA3寄存器。这种模式的吞吐率较低，因为每个数据块都会产生两次中断（一次写，一次读），中断响应和上下文保存/恢复开销很大。
• DMA驱动模式：适用于连续、大批量的数据加密。数据搬运完全由DMA控制器在后台完成，CPU仅在开始和结束时介入。这是追求性能和能效时的首选方案。在DMA传输期间，CPU可以进入睡眠模式，进一步降低系统功耗。

选择依据很简单：只要数据是连续或可预见的批量数据，就应毫不犹豫地使用DMA。

5.2 低功耗运行支持

MSPM0的AESADV模块的一个突出优点是它支持在RUN和SLEEP模式下工作。这意味着，当CPU因等待加密完成而进入低功耗睡眠状态时，AES加速器和DMA控制器可以继续协同工作。这对于电池供电的物联网设备至关重要。

实现方式通常是：

1. 配置好AES和DMA。
2. 启动传输（写入C_LENGTH）。
3. CPU执行__WFI()（等待中断）或类似指令进入睡眠。
4. DMA完成全部传输后，产生中断唤醒CPU。
5. CPU在中断服务程序中处理后续事宜。

这种“发射后不管”的模式，最大限度地减少了CPU活跃时间，对延长设备续航有显著帮助。

5.3 上下文保存与恢复

在一些复杂场景下，你可能需要暂停一个长时间的加密操作（例如GCM处理一个很大的数据包），去处理更高优先级的任务，然后再回来继续。AESADV模块的SAVE_CNTXT功能和相关的上下文保存寄存器就是为了这个目的。

当设置CTRL[SAVE_CNTXT]=1并启动一个操作后，在操作过程中的特定点（例如，在GCM模式下处理完一部分AAD后），可以通过触发GET_DIGEST操作，让模块将当前的内部状态（如GHASH的中间结果、计数器值等）保存到一组特定的上下文寄存器中。之后，你可以安全地切换任务或修改密钥去处理其他事情。

当需要恢复时，你需要将这些保存的上下文值写回模块，并重新配置密钥、IV等（如果没变则无需重复），然后从暂停点继续执行。这个功能非常高级，在绝大多数应用中用不到。如果使用不当，很容易引入状态混乱的错误。除非你有确切的、需要处理高优先级实时中断的需求，否则建议在单次操作中完成整个加密/认证流程。

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

即使按照手册一步步配置，在实际调试中也可能遇到各种问题。以下是一些常见故障现象和排查思路：

问题一：数据加密/解密结果不正确。

• 检查密钥和IV：这是最常见的原因。确认写入KEY0-KEY7和IV0-IV3寄存器的值完全符合你的预期，字节序（大端/小端）是否正确。使用调试器在写入后立刻读取这些寄存器进行验证。
• 检查模式配置：确认CTRL寄存器的DIR（方向）、MODE（模式）位设置正确。加密和解密的配置是相反的。
• 检查数据对齐和大小：确保输入数据是128位（16字节）的整数倍。如果不是，需要根据模式规范进行填充（如PKCS#7填充）。AES硬件本身不负责填充。
• 验证参考值：使用已知的测试向量（Test Vector）。NIST或芯片厂商通常会提供标准的AES测试向量（密钥、明文、密文）。用你的代码加密一个测试向量中的明文，看结果是否与标准密文匹配。

问题二：DMA传输启动后，AES模块没有反应，或者DMA传输卡住。

• 检查DMA触发源：确认DMA通道配置的触发事件号与AES模块产生的DMA_TRIG0/DMA_TRIG1事件号一致。查阅芯片的《技术参考手册》中的DMA事件映射表。
• 检查DMA握手使能：确认AES_DMA_HS[DMA_DATA_ACK]位已被设置为1。没有这个，AES不会产生DMA触发信号。
• 检查长度寄存器：确认C_LENGTH_0/1寄存器已被写入正确的总字节数。这是启动DMA协作模式的“开关”。
• 检查缓冲区地址：确认DMA配置的源地址和目的地址是有效的、可访问的内存地址或外设寄存器地址。
• 使用调试器监控状态：单步执行，在写入C_LENGTH后，观察AES模块的STATUS寄存器或INPUT_RDY/OUTPUT_RDY位是否发生变化。观察DMA通道的TRIG状态位是否被置起。

问题三：GCM模式下的认证标签验证失败。

• 确认AAD和PAYLOAD数据完全一致：发送方和接收方处理的AAD数据（长度和内容）必须一字不差。即使是长度值差一个字节，最终的TAG也会完全不同。
• 检查IV的唯一性：确保本次加密使用的IV从未与当前密钥一起使用过。
• 确认TAG比较方式：接收方计算出的TAG与发送方传来的TAG需要进行恒定时间比较，即逐字节比较且时间固定，以避免遭受侧信道计时攻击。不要用memcmp这类短路比较函数。
• 检查长度寄存器写入顺序和值：AAD_LENGTH和C_LENGTH必须在启动前正确写入，且单位是字节。

问题四：性能远低于预期。

• 测量真实周期：不要只看AES核心的计算周期。使用GPIO翻转或系统滴答定时器，测量从启动加密到收到完成中断的整个时间跨度。这包含了DMA搬运、总线仲裁等所有开销。
• 优化内存布局：确保源数据和目标数据位于SRAM中访问速度最快的区域（如TCM内存，如果芯片有的话）。避免使用需要等待状态的慢速Flash区域作为DMA源/目的。
• 提升系统时钟：AES模块的工作频率通常与系统主频相关。在允许的功耗预算内，尝试提高系统时钟频率。
• 检查总线竞争：如果系统中还有其他高带宽外设（如USB、高速ADC）在同时工作，可能会与AES的DMA产生总线竞争。尝试调整DMA通道的优先级，或错开高带宽操作的时间。

调试硬件加密模块，逻辑分析仪或示波器是很好的帮手。你可以通过监控与AES操作相关的GPIO信号（例如，在ISR开始和结束时拉高/拉低一个引脚）来精确测量执行时间。同时，充分利用芯片的调试模块，设置对关键寄存器（如AES_DATA_IN）的写访问断点，可以清晰地跟踪数据流。