嵌入式MCU中AES硬件加速器与看门狗定时器的实战配置与避坑指南

1. 项目概述：嵌入式安全与稳定的基石

在嵌入式系统开发，尤其是物联网终端、支付设备或工业控制器这类对安全性和可靠性有严苛要求的领域，我们开发者常常面临两个核心挑战：如何高效、安全地处理敏感数据，以及如何确保系统在无人值守或复杂电磁环境下长期稳定运行，不死机、不跑飞。这两个看似独立的问题，其实在芯片层面有着紧密的耦合，其答案往往就藏在微控制器（MCU）的那些专用硬件模块里——AES硬件加速器和看门狗定时器（WDT）。

AES硬件加速器，简单说就是芯片里专门用来干AES加解密这个“重活”的协处理器。当你的固件需要对通信数据或存储信息进行加密时，如果让主CPU（比如Cortex-M系列内核）通过软件算法去执行那十几轮的字节替换、行移位、列混合和轮密钥加操作，不仅会消耗大量时钟周期，拉高系统功耗，更会在实时性要求高的场景下成为性能瓶颈。而硬件加速器则不同，它用专用的数字电路直接实现AES算法的流水线，你只需要通过几个寄存器把密钥和数据“喂”进去，它就能在固定的时钟周期内（比如167个MCLK周期）完成计算，CPU在此期间可以去处理其他任务，极大地提升了系统效率和实时响应能力。

另一方面，看门狗定时器则是嵌入式系统的“生命保险”。它的逻辑非常直接：你需要定期（在定时器溢出前）去“喂狗”（清除计数器），向系统证明“我还活着，程序在正常跑”。一旦因为程序跑飞、陷入死循环或外部干扰导致“喂狗”动作停止，看门狗就会超时，随即触发一个系统复位（PUC），把整个MCU拉回一个已知的初始状态，从而从故障中恢复。这种机制对于需要7x24小时连续工作的设备至关重要。

在实际项目中，这两个模块的配置和使用是嵌入式开发者的基本功。但仅仅知道“怎么配”还不够，更重要的是理解寄存器每一个比特位背后的设计意图、状态机的流转逻辑，以及在实际编程中那些容易踩坑的细节。比如，AES加速器的密钥加载和数据写入顺序有何讲究？看门狗在低功耗模式下如何选择时钟源才能既保证功能又不额外耗电？接下来，我将结合多年的实战经验，为你深入拆解这两个模块的工作原理、寄存器配置的每一个细节，并分享那些在数据手册里不会明写，但却能决定项目成败的实操技巧。

2. AES硬件加速器：从算法到硬件的深度解析

2.1 AES-128算法核心流程与硬件映射

要理解硬件加速器，必须先明白它要加速的算法。AES-128是对称加密算法，处理128位（16字节）的数据块，使用128位的密钥，经过10轮迭代运算。每一轮都包含四个基本操作：字节替换（SubBytes）、行移位（ShiftRows）、列混合（MixColumns）和轮密钥加（AddRoundKey）。初始轮和最终轮稍有不同。

硬件加速器的设计，正是将这些数学运算固化到电路中。当你查看数据手册中的框图（Figure 11-3），会发现它清晰地展示了这个流程：明文从AESADIN寄存器输入，密钥从AESAKEY寄存器加载，经过一个名为“Cipher”的加密引擎（内部就是这10轮变换的硬件实现），最终密文从AESADOUT寄存器输出。这个“黑盒”化的处理，对开发者而言是透明的，我们无需关心内部每轮变换的具体实现，只需要关注如何正确地与这几个寄存器交互。

这里有一个关键点：硬件加速器通常以“块”为单位进行操作。你必须一次性写入完整的16字节密钥和16字节数据，它才会开始工作。这种设计决定了我们的软件流程必须是：准备密钥缓冲区 -> 分次或单次写入AESAKEY-> 准备数据缓冲区 -> 分次或单次写入AESADIN-> 等待操作完成 -> 从AESADOUT读取结果。任何步骤的错序或数据不完整，都会导致操作失败或得到错误结果。

2.2 核心寄存器组详解与配置策略

AES加速器的寄存器不多，但每个都至关重要。理解它们的状态机和互锁关系，是写出稳健驱动代码的前提。

2.2.1 控制与状态寄存器：AESACTL0, AESACTL1, AESASTAT

AESACTL0是大脑。它的低两位AESOPx决定操作模式：00加密，01解密（使用加密密钥），10生成解密所需的第一轮密钥，11解密（使用已生成的第一轮密钥）。这里就有一个重要的设计考量：为什么解密有两种模式（01和11）？模式01是“在线解密”，硬件在解密前，会先用你提供的原始加密密钥，内部执行一个密钥扩展的逆过程，生成解密所需的第一轮密钥（即加密的第10轮密钥），这个过程需要额外的时钟周期（总共214 MCLK）。而模式11是“离线解密”，你需要先用模式10提前算好这个第一轮密钥并保存起来，解密时直接加载它，这样解密过程就和加密一样快（167 MCLK）。在需要频繁解密的场景下，预先计算并缓存这个“解密密钥”可以显著提升性能。

AESKLx位选择密钥长度：00对应AES-128（16字节密钥），01对应AES-192（24字节），10对应AES-256（32字节）。特别注意：当你改变AESOPx或AESKLx时，硬件会自动清除AESKEYWR（密钥写入完成标志）和AESDINWR（数据写入完成标志）状态。这意味着，每次切换操作模式或密钥长度后，你必须重新加载密钥！这是一个非常常见的错误来源，很多开发者配置完模式后直接使用之前残留的密钥状态，导致加解密失败。

AESACTL1寄存器在使能了密码分组模式（AESCMEN=1）并与DMA配合时才有用，其中的AESBLKCNTx用于设置需要连续处理的块数量。在普通的单块操作下，我们很少直接操作它。

AESASTAT是状态窗口。AESBUSY位直观地告诉我们加速器是否正在工作中。AESKEYWR,AESDINWR,AESDOUTRD这三个标志位构成了一个完整的状态机，它们分别指示密钥、输入数据是否已完整写入（16字节），以及输出数据是否已完整读出。这里有一个硬件与软件协同的精细设计：这些标志位既可以由硬件在字节计数器（AESKEYCNTx,AESDINCNTx,AESDOUTCNTx）满时自动置位，也可以由软件手动置位。手动置位有什么用？想象一个场景：你需要用同一个密钥加密多个数据块。对于第一个块，你老老实实地通过AESAKEY寄存器写入16字节密钥，硬件会自动置起AESKEYWR。对于后续的块，你不再需要重新写入密钥，只需要在加载新数据到AESADIN之前，用软件将AESKEYWR标志再次写1，告诉硬件：“密钥还是之前那个，没变，可以直接用”。这避免了重复传输密钥的开销，提升了流加密的效率。

2.2.2 数据与密钥寄存器：AESAKEY, AESADIN, AESADOUT

这三个是数据通道寄存器。AESAKEY用于写入密钥，AESADIN用于写入待处理的数据（明文或密文），AESADOUT用于读取处理结果（密文或明文）。它们有一个共同特点：只写或只读属性，且不能混合字节和字访问模式。

以AESAKEY为例，数据手册的寄存器描述（Table 11-5）明确写着：“Do not mix word and byte access.” 这是什么意思？假设你的密钥存放在一个字节数组key[16]中。如果你选择以字（16位）为单位写入，那么你应该这样操作：

for(i=0; i<8; i++) { // 将两个字节组合成一个字写入 AESAKEY = (key[i*2+1] << 8) | key[i*2]; }

如果你选择以字节为单位写入，则应访问AESAKEY_L（低字节部分）：

for(i=0; i<16; i++) { AESAKEY_L = key[i]; }

但绝对不要混用！比如先写几个字，再写几个字节。这会导致内部字节计数器混乱，AESKEYWR标志无法正确置位，操作必然失败。AESADIN和AESADOUT同理。在项目初期，我建议统一使用一种访问方式（通常字节访问更直观），并在整个驱动中保持一致。

AESAXDIN和AESAXIN这两个寄存器用于实现密码分组链接（CBC）、输出反馈（OFB）等高级加密模式。它们的作用是在数据输入加密引擎前，先与一个初始向量（IV）或前一个密文块进行异或（XOR）操作。AESAXDIN在写入时会自动触发加密操作，而AESAXIN则不会。在实现CBC模式时，你需要将前一个密文块（或对于第一个块，是IV）写入AESAXDIN，然后将当前明文块写入AESADIN，硬件会自动完成异或和加密。这再次体现了硬件加速的优势，将模式运算也部分硬件化了。

2.3 完整操作流程与中断处理实战

让我们以一个完整的AES-128加密流程为例，串联起所有寄存器操作，并探讨轮询与中断两种处理方式。

步骤1：初始化与模式选择首先，确保模块处于复位状态或空闲状态。可以通过设置AESACTL0中的AESSWRST=1来发起一个软件复位（该位会自动清零）。然后，配置操作模式和密钥长度。假设我们进行加密：

// 选择AES-128加密模式 AESACTL0 = AESOP_0 | AESKL_0; // AESOPx=00, AESKLx=00

注意：此操作会清零AESKEYWR和AESDINWR标志。

步骤2：加载密钥将16字节的密钥写入AESAKEY寄存器。可以采用字节或字访问，但不能混用。

volatile uint8_t *aes_key_ptr = (uint8_t *)&AESAKEY_L; const uint8_t key[16] = {...}; // 你的128位密钥 for(int i=0; i<16; i++) { *aes_key_ptr = key[i]; } // 写入完成后，AESKEYWR标志应由硬件自动置1

你也可以在写入部分字节后，通过软件置位AESKEYWR来提前“告知”硬件密钥已就绪，但这要求你确信写入的密钥数据是正确的。更稳妥的做法是等待硬件置位，或写入完成后检查AESASTAT寄存器中的AESKEYWR位。

步骤3：加载数据并启动加密将16字节的明文数据写入AESADIN寄存器。

volatile uint8_t *aes_din_ptr = (uint8_t *)&AESADIN_L; const uint8_t plaintext[16] = {...}; // 待加密数据 for(int i=0; i<16; i++) { *aes_din_ptr = plaintext[i]; } // 当第16字节写入后，硬件置位AESDINWR，并立即开始加密，AESBUSY变为1

步骤4：等待完成并获取结果此时，你有两种方式等待操作完成：

• 轮询方式：循环检查AESASTAT中的AESBUSY位变为0，或者检查AESACTL0中的AESRDYIFG中断标志置位。

  while((AESASTAT & AESBUSY) != 0) { ; // 空循环等待，或执行其他低优先级任务 }

• 中断方式：使能AESACTL0中的AESRDYIE中断，并在中断服务程序（ISR）中读取结果。这里有一个至关重要的细节：AESRDYIFG标志会在三种情况下被自动清除：1) 读取AESADOUT；2) 写入AESAKEY；3) 写入AESADIN。这意味着，如果你在ISR中读取结果，标志位会自动清零，无需手动清除。但如果你采用轮询方式，在读取结果前需要手动清除AESRDYIFG（向该位写1清零，具体取决于寄存器设计，有些是写1清零，有些是读操作清零，需查手册确认）。

读取结果同样需要注意访问一致性：

volatile uint8_t *aes_dout_ptr = (uint8_t *)&AESADOUT_L; uint8_t ciphertext[16]; for(int i=0; i<16; i++) { ciphertext[i] = *aes_dout_ptr; } // 读取完成后，AESDOUTRD标志应由硬件自动置1

步骤5：连续加密如果你要用同一个密钥加密下一个数据块，流程可以简化。因为密钥标志AESKEYWR在上次操作后仍然是1（只要没有改变AESOPx或AESKLx），你只需要：

1. 确保上一个块的结果已从AESADOUT读完（AESDOUTRD=1）。
2. 将新的明文数据写入AESADIN。
3. 硬件会自动开始新一轮加密。

2.4 低功耗模式下的协同与注意事项

许多嵌入式设备大部分时间处于低功耗模式（LPM）。AES加速器在设计时考虑到了这一点。数据手册第11.2.4节明确指出：当AES加速器忙时，它会自动激活主时钟（MCLK），无论时钟源的控制位如何设置。这意味着，你可以在CPU休眠（MCLK关闭）时启动一个AES操作，加速器会“唤醒”时钟来完成工作，完成后时钟可能再次关闭。

这对我们的编程策略有何影响？首先，功耗估算：如果你在低功耗模式下频繁进行AES操作，需要意识到每次操作都会临时激活MCLK，这会增加动态功耗。在电池供电设备中，需要权衡安全处理的需求和功耗预算。 其次，时序同步：在中断驱动的设计中，你可以在LPM中启动AES，然后让CPU进入休眠。AES完成时产生的中断会唤醒CPU。这时要特别注意，在AES中断服务程序中，首先要判断中断源（虽然AES只有一个中断源），其次要确保在读取结果或进行下一步操作前，CPU的时钟和相关外设已经稳定（通常从低功耗模式唤醒后需要几个时钟周期稳定）。 最后，一个关键陷阱：不要在AES加速器忙（AESBUSY=1）的时候，试图去修改AESAKEY或AESADIN寄存器。这不仅会导致AESERRFG错误标志置位，当前正在进行的计算也可能被破坏，得到不可预知的结果。在编写驱动时，任何对这两个寄存器的写操作前，都必须检查AESBUSY位。

3. 看门狗定时器：系统稳定的守护者

3.1 看门狗的核心机制与初始状态

看门狗定时器的本质是一个独立的、持续运行的向上计数器（WDTCNT）。这个计数器对开发者是不可见的，我们只能通过WDTCTL寄存器去控制它。它的核心逻辑是：如果计数器达到由WDTIS位设定的阈值（即超时），就会触发一个系统复位（PUC）。

这里有一个所有嵌入式开发者都必须牢记的“上电第一课”：在绝大多数MCU中，包括本文所述的架构，看门狗在系统上电复位（POR）或经过一个上电清除（PUC）后，默认是开启的，并且处于看门狗模式，使用SMCLK作为时钟源，初始超时间隔大约为32毫秒（具体值取决于SMCLK频率）。这意味着，如果你的初始化代码（配置时钟、初始化外设、创建任务等）耗时超过32毫秒，且没有在这期间“喂狗”或停用它，系统将会被自动复位，陷入不断重启的循环。你可能会看到设备反复重启，却找不到原因。

因此，在main()函数的最开始，甚至在系统时钟初始化之后的第一条指令，就必须处理看门狗。通常有两种做法：

1. 彻底关闭它（如果不打算使用）：WDTCTL = WDTPW | WDTHOLD;
2. 立即“喂狗”并配置为所需模式：WDTCTL = WDTPW | WDTCNTCL | WDTSSEL__ACLK | WDTIS__2_31; // 使用ACLK，设置一个很长的超时时间

密码保护机制：WDTCTL的高字节（位15-8）是密码域WDTPW。任何写WDTCTL的操作，都必须以字（16位）为单位，且高字节必须写入0x5A。读操作时，高字节永远返回0x69。如果你错误地写入其他值，或者尝试以字节方式写入（例如WDTCTL_L = 0x01;），都会立即触发一个PUC。这是一个非常强硬的保护机制，防止程序跑飞后意外修改了看门狗配置，导致其失效。在编程时，务必使用厂商提供的宏定义（如WDTPW），而不要自己硬编码0x5A00之类的数值，以提高代码可读性和安全性。

3.2 工作模式深度解析：看门狗模式 vs. 间隔定时器模式

WDTCTL寄存器的WDTTMSEL位决定了它的双重人格。

3.2.1 看门狗模式 (WDTTMSEL=0)这是其本职工作。在此模式下，超时事件会直接导致系统复位（PUC）。你需要编写一个“喂狗”任务，在超时前定期执行“清计数器”操作。喂狗指令很简单：

WDTCTL = WDTPW | WDTCNTCL; // 写入密码，并设置WDTCNTCL位为1

WDTCNTCL位是一个“瞬间”位，写入1后，硬件会立即将内部的32位WDTCNT计数器清零，然后该位会自动被硬件清零。所以，你不需要、也不能手动去清除这个位。

喂狗策略是设计关键：

• 位置：喂狗操作应该放在系统主循环或一个高优先级、定期执行的定时器中断中。绝对不要放在某个可能被阻塞或长时间不执行的分支里。
• 频率：超时间隔应该远大于正常的喂狗间隔。例如，如果主循环周期是10ms，超时可设置为1秒。这为程序偶尔的延迟提供了缓冲，避免因单次执行时间波动导致误复位。
• 单一性：在整个系统中，最好只有一个地方执行喂狗操作。多个地方喂狗会掩盖问题，如果某个任务卡死但其他任务仍在喂狗，看门狗就失去了作用。

3.2.2 间隔定时器模式 (WDTTMSEL=1)在此模式下，看门狗“变身”为一个普通的周期性中断定时器。超时后，它不会引发复位，而是设置中断标志WDTIFG。如果中断使能位WDTIE和全局中断使能GIE都打开，则会触发一个看门狗定时器中断。

这个模式非常有用，可以为你节省一个硬件定时器资源。例如，你可以用它来产生一个秒级的时基，用于低功耗设备的周期性唤醒和采样。需要注意的是，在间隔定时器模式下，中断向量地址与看门狗模式下的复位向量不同。你需要为间隔定时器模式单独编写中断服务程序。

模式切换的陷阱：数据手册特别警告：“The watchdog timer interval should be changed together with WDTCNTCL = 1 in a single instruction.” 这意味着，当你需要改变超时间隔WDTIS或时钟源WDTSSEL时，必须在同一条写WDTCTL的指令中，同时设置WDTCNTCL=1。为什么？假设你先写一条指令修改了WDTIS，将超时从1秒改到100毫秒，但此时计数器WDTCNT可能已经累加到接近1秒（例如990毫秒）。在新的、更短的超时阈值下，计数器当前值（990毫秒）可能已经超过了新的阈值（100毫秒），导致立即触发超时事件（复位或中断）！这是一条非常容易忽略但后果严重的规则。安全的做法永远是：

// 安全地改变间隔（例如改为250ms间隔） WDTCTL = WDTPW | WDTCNTCL | WDTTMSEL | WDTSSEL__ACLK | WDTIS__2_13; // 密码 + 清计数器 + 间隔定时器模式 + ACLK时钟源 + 2^13分频

3.3 时钟源选择与低功耗设计精要

WDTSSEL位提供了多种时钟源选择：SMCLK（子系统主时钟）、ACLK（辅助时钟，通常来自32.768kHz低频晶振）、VLOCLK（内部超低功耗低频振荡器）、X_CLK（外部时钟）。

选择时钟源的本质，是在功能可靠性和功耗之间做权衡。

• 高可靠性场景（如工业控制）：建议使用独立的、稳定的时钟源，如ACLK（外部32.768kHz晶振）。即使主时钟（MCLK/SMCLK）因干扰失效，看门狗依然能依靠ACLK工作，触发复位拯救系统。
• 超低功耗场景（如电池传感节点）：如果设备需要进入深度睡眠（LPM3/LPM4），SMCLK和ACLK（如果源自高频晶振）可能被关闭。此时，唯一仍在运行的可能是VLOCLK。你可以将看门狗配置为使用VLOCLK。但要注意，VLOCLK的频率精度和稳定性较差（通常±5%甚至更差），这意味着超时间隔会有较大误差，不适合需要精确定时的场合，但用于防止死锁是足够的。
• 时钟失效安全（Clock Fail-Safe）特性：这是看门狗一个非常强大的功能。当处于看门狗模式（WDTTMSEL=0）时，如果所选的时钟源（SMCLK或ACLK）失效，硬件会自动将时钟切换到VLOCLK，确保看门狗计数器不会停止。但请注意，这个特性仅在看门狗模式下有效，在间隔定时器模式下无效。这也意味着，在低功耗模式下，如果你选择了SMCLK作为看门狗时钟，即使CPU进入休眠，SMCLK也可能因为看门狗的请求而保持活动，从而增加功耗。因此，在低功耗设计时，需要仔细评估。

低功耗模式下的操作建议：

1. 进入低功耗模式前：如果不需要看门狗，用WDTHOLD位停止它。如果需要，则根据预期的休眠时长和可用的时钟源，合理配置看门狗的超时间隔。
2. 从低功耗模式唤醒后：如果唤醒事件是看门狗中断（间隔定时器模式），则在中断服务程序中完成所需任务后，看门狗计数器会从0重新开始。如果是其他事件唤醒，并且你打算再次进入休眠，需要评估是否需要“喂狗”以复位计数器，防止在下次休眠期间超时。
3. 使用WDTHOLD：在调试阶段，或者某些绝对不允许复位的极短关键代码段（例如Flash编程），可以临时设置WDTHOLD=1来暂停看门狗。但务必在离开关键段后立即恢复，并且要意识到这期间系统失去了看门狗保护。

3.4 软件示例与常见错误排查

数据手册提供了一些汇编示例，我们将其转化为更易理解的C语言伪代码，并附上注释：

// 示例1：定期“喂狗”（在看门狗模式下） #define WDT_PASSWORD (0x5A00) #define WDT_CLEAR_COUNT (0x0008) // WDTCNTCL 位掩码 #define WDT_HOLD (0x0080) // WDTHOLD 位掩码 // 假设已配置好看门狗模式和时钟源 void feed_watchdog(void) { // 一条指令完成密码写入和计数器清零 WDTCTL = WDT_PASSWORD | WDT_CLEAR_COUNT; } // 示例2：停止看门狗（常用于调试或初始化） void stop_watchdog(void) { WDTCTL = WDT_PASSWORD | WDT_HOLD; } // 示例3：配置为间隔定时器，使用ACLK，2^15分频（约1秒 @32.768kHz） void init_wdt_as_interval_timer(void) { // 单条指令完成：密码+清计数器+间隔模式+选择ACLK+设置分频 WDTCTL = WDT_PASSWORD | WDT_CLEAR_COUNT | WDTTMSEL | WDTSSEL__ACLK | WDTIS__2_15; // 使能看门狗定时器中断 SFRIE1 |= WDTIE; // 使能全局中断 __enable_interrupt(); }

常见问题与排查技巧实录：

1. 问题：系统不断莫名复位。

   • 排查：首先检查SYSRSTIV寄存器（系统复位中断向量寄存器）。这个寄存器会指示最后一次复位的来源。如果它的值是0x0002，则表明是看门狗超时导致的复位。
   • 可能原因：
     • 初始化代码耗时过长，超过了默认的32ms窗口，没有及时喂狗或停止看门狗。
     • 喂狗代码没有被执行到。检查喂狗函数是否被调用，是否在某个条件分支中被跳过，或者系统是否陷入了某个阻塞调用（如等待一个永远不会发生的事件）。
     • 看门狗时钟源配置错误。例如，配置为SMCLK但SMCLK未开启或频率极低，导致计数器几乎不增长，看似“喂狗”及时，实则早已超时。
     • 低功耗模式下，喂狗任务所在的定时器或线程被挂起。

2. 问题：看门狗间隔定时器中断不触发。

   • 排查：
     • 确认WDTTMSEL=1（间隔定时器模式）。
     • 确认WDTIE（中断使能）和GIE（全局中断使能）都已置位。
     • 检查时钟源是否有效。例如，如果选择了ACLK，但外部32.768kHz晶振未起振或未配置，则计数器不工作。
     • 检查是否在中断服务程序中清除了WDTIFG标志？在间隔定时器模式下，该标志通常在中断响应时自动清零，但有些架构可能需要手动清除，需查阅具体器件手册。

3. 问题：试图配置看门狗后系统立即复位。

   • 排查：这几乎肯定是密码错误或访问方式错误。
     • 检查写WDTCTL时，高字节是否为0x5A。确保使用了正确的宏或常量。
     • 确保是对WDTCTL进行字（16位）写操作。在C语言中，对定义为volatile unsigned int的WDTCTL进行赋值就是字操作。绝对不要分别写WDTCTL_H和WDTCTL_L。
     • 检查编译器或代码是否意外地对WDTCTL进行了字节操作。

4. 协同应用场景与高级实践

在实际的嵌入式安全产品中，AES加速器和看门狗往往是协同工作的。例如，一个智能门锁的无线通信模块：

1. 上电初始化：首先，在main()开头立即配置或停止看门狗。然后初始化系统时钟、GPIO、串口、无线模块等。
2. 建立安全连接：当需要与服务器建立TLS/DTLS连接或进行密钥协商时，使用AES加速器来快速计算握手消息的哈希或加密临时密钥。这个过程可能涉及多次加解密操作。
3. 数据加密传输：在正常通信中，所有上行和下行的敏感数据（如开锁指令、日志）都通过AES加速器进行加密（CBC模式）和认证。
4. 看门狗守护：在主循环或一个独立的定时器中断中，定期执行“喂狗”操作。这个循环还需要处理无线数据包的接收、解析、执行命令并返回加密的响应。
5. 低功耗心跳：在待机状态，系统可能进入低功耗模式。看门狗可以配置为使用VLOCLK，并设置一个较长的超时（如1分钟）。同时，可以启用看门狗的间隔定时器模式（如果支持且向量不同），或者用另一个基础定时器，来周期性地唤醒系统，检查是否有网络心跳或本地触发事件。
6. 故障恢复：如果无线协议栈出现异常、解析数据包时出现致命错误，或者程序跑飞，导致喂狗停止，看门狗将在超时后触发复位。复位后，设备重新初始化，尝试重新连接网络，恢复到可工作状态。为了区分是上电复位还是看门狗复位，可以在初始化时检查SYSRSTIV，如果是看门狗复位，可以增加一些诊断日志上报或进入更保守的恢复模式。

高级技巧：使用DMA配合AES加速器对于需要加密/解密大量连续数据的应用（如读写加密的Flash镜像、高速数据流加密），频繁的CPU中断来搬运数据会成为瓶颈。此时，可以启用AES加速器的DMA支持（AESCMEN=1）。你需要：

1. 配置DMA通道：源地址为明文数据缓冲区，目的地址为AESADIN寄存器（对于加密），或源地址为AESADOUT，目的地址为密文缓冲区（对于读取结果）。设置传输宽度为字节或字，并匹配AES寄存器的访问方式。
2. 在AESACTL1中设置AESBLKCNTx为需要处理的块数量。
3. 配置AES加速器为所需的密码模式（AESCMx），如CBC。
4. 启动DMA。DMA会自动将数据块搬入AESADIN，触发加密，然后在加密完成后将结果从AESADOUT搬出到目标缓冲区，整个过程无需CPU频繁干预，极大提升了吞吐量。

最后，分享一个我踩过的坑：在一次产品测试中，发现设备在高温下运行一段时间后，AES加密偶尔会出错。排查了很久，最终发现是电源纹波在高温下变大，导致在向AESAKEY寄存器写入密钥时，个别字节写入因时序问题未能成功，但AESKEYWR标志却被异常置位了。硬件开始了加密，但使用的是错误的密钥。教训是：在对安全性要求极高的场合，在加载密钥和重要数据后，如果条件允许，可以增加一个回读验证的步骤（虽然密钥寄存器读回为0，但可以验证状态标志和后续加密一个已知明文的结果）。更根本的是，要确保MCU的供电电源质量，尤其是在高温、高干扰的工业环境中。