STM32U3C5这颗料刚到手的时候，我其实没太当回事。毕竟从F1、F4一路做到U5，Cortex-M33的套路早就摸透了，换颗低功耗内核还能翻出什么花来？结果真正做低功耗场景调优的时候，HSP中断这块差点把我按在地上摩擦。丢事件、唤醒时序不对、进低功耗后中断不响应，各种问题轮着来。后来把架构文档和参考手册逐行啃完，又用逻辑分析仪一帧一帧抓波形，才把整条链路彻底理顺。这篇就把我对STM32U3C5上HSP中断的理解、实操配置和踩坑过程完整写出来，希望对正在调这颗料的同学有点实际帮助。
1. 先搞明白一件事：HSP在U3C5里到底扮演什么角色
很多人在看参考手册目录的时候扫到HSP这个词，第一反应是某个外设的缩写。其实在STM32U3系列里，HSP是硬件子系统的概念，英文全称是High-Speed Peripheral，但重点不在“高速”两个字，而在于它是一组外设共享的总线域和中断汇聚节点。也就是说，HSP把这几个带宽要求高、实时性要求强、又经常需要协同工作的外设挂在同一条高速总线上，并且通过独立的中断控制逻辑向CPU上报事件。
这个设计逻辑其实和STM32传统的APB/AHB总线划分思路一脉相承，只是U3C5把“低功耗”这个目标提到了空前高度。以前做低功耗项目，外设要么和内核跑同一个时钟域，要么干脆关掉。但U3C5的HSP域允许外设在CPU进入深度睡眠时继续保持运行，而且HSP中断可以配置为“唤醒源”，从STOP模式甚至STANDBY边缘把CPU拉起来。这个能力才是HSP中断真正的价值所在。
1.1 U3C5这颗料为什么要单独拧出一个HSP域
STM32U3C5本质上定位在“极致功耗”和“够用性能”的交叉点。举个例子，你要做一个带数据采集、简单边缘处理、无线协议栈的传感器节点，CPU大部分时间都在睡觉，但外设并不能睡。传统方案是CPU定期醒来轮询一次外设，确保数据不丢。但轮询就意味着CPU必须周期性工作，功耗就被抬上去了。
HSP域的思路是反过来：外设在CPU睡觉的时候照样跑，有需要了再通过中断把CPU叫醒。要做到这一点，HSP的外设时钟、寄存器访问、中断路径，就必须和CPU的低功耗状态解耦。所以它不是简单地把几个外设挪到一根总线上那么简单，背后涉及的是一整套时钟管理、复位管理、中断唤醒的独立机制。
从系统框图上看，U3C5的HSP域通常包括高精度定时器、通用目的DMA、以及几个和射频基带或数据采集强相关的外设桥接逻辑。这些外设共同的特点是：事件频率高、数据吞吐量大、容不得CPU频繁介入。把它们集中到一个域里统一管理，好处非常明显——低功耗模式下只需给这一个域送电，其他域的时钟全部关断，功耗可以压得很低，而该干活的活儿一样没落下。
1.2 中断路径上最关键的三段节点
HSP中断从发生到CPU执行中断服务函数，中间经过三段路径：
第一段是外设本身的事件标志。比如定时器计数溢出、DMA传输完成、比较器跳变，这些硬件条件满足时会在外设内部的状态寄存器里置一个标志位。
第二段是HSP域的中断汇聚逻辑。多个外设的事件标志汇合到HSP的中断控制器，按照预先配置的使能位和屏蔽位决定哪些事件能继续向上游传递。这一层是HSP域独有的，它和NVIC之间还有一个映射关系，简单理解就是HSP把外设中断统一转换成若干个IRQ编号，再接到NVIC的输入通道上。
第三段就是Cortex-M33核心自带的NVIC（嵌套向量中断控制器）。到了这里，中断就变成了标准的ARM中断处理流程：硬件自动把当前运行状态压栈，从向量表取出ISR地址，跳转执行。
这三段链路里，最容易出问题的就是第二段和第三段之间的映射关系。很多同学遇到“外设标志位明明置了，ISR就是不进”的问题，九成都是因为第二段和第三段之间的某个使能位没有打开，或者优先级配置被NVIC屏蔽掉了。
2. HSP中断的“锁存”机制：为什么事件不会凭空消失
做HSP中断开发，一定要先理解一个概念：外设事件从发生到被CPU响应，中间是有“锁存”的。所谓锁存，就是硬件会在外设内部用寄存器把事件记录保存下来，哪怕CPU没有立刻响应，这个事件也不会丢。这个机制是HSP中断可靠性的基石。
具体到U3C5的HSP域，每个外设的每个中断源都对应一个状态标志位和一个中断使能位。状态标志位由硬件置位，软件读到之后必须手动清除，或者在某些配置下可以由硬件自动清除。如果软件不及时清标志，后续同类型的事件可能被拒收，现象就是“中断只进了一次，后面再也没反应了”。
2.1 电平触发 vs 边沿触发：HSP域里的两种模式怎么选
HSP中断默认支持两种触发模式：电平触发和边沿触发。很多新手分不清，其实非常直观——电平触发看的是“状态”，只要这个引脚或者标志电平一直保持有效，中断就会一直触发；边沿触发看的是“变化”，只有发生特定的跳变沿（上升沿、下降沿或双沿）才会触发一次。
在HSP域里选择哪种模式，取决于外设事件的性质。比如一个数据就绪信号，通常是高电平表示“有数据”，用边沿触发更好，避免CPU反复进入中断。而一个错误标志，比如CRC校验失败，错误期间电平一直有效，就需要用电平触发，保证CPU能感知到异常状态。
U3C5的HSP中断配置寄存器里，每个中断源都有独立的触发模式选择位。我个人的经验是：能用边沿触发解决的问题，优先用边沿；需要持续监控的状态，才用电平。理由很简单，电平触发在中断服务函数执行完但标志尚未清除的窗口期内，可能会再次触发一次虚假中断，增加额外的压栈出栈开销。
2.2 中断标志的清除顺序：隐藏最深的坑
这个坑我踩过，而且不止一次，值得单独拿出来讲。
HSP中断的标志清除有个硬性顺序要求，不是随便读写寄存器就行的。以定时器捕获事件为例：读取捕获值寄存器、清除溢出标志、清除捕获标志，这三步有严格先后顺序。如果先把捕获标志清了再读捕获值，可能读到的是一个已经被覆盖的旧数据；如果先读了捕获值但没清溢出标志，下一次溢出事件会被丢弃。
正确的清除顺序应该是：
- 读取状态寄存器，收集当前有效的所有中断标志位
- 清除非关键状态标志（如溢出标志）
- 读取数据寄存器（如捕获值、DMA剩余字节数）
- 最后清除与本次数据处理最相关的完成标志
这个顺序的核心思路是：先保证数据不被覆盖，再把中断状态清理干净。一旦顺序反了，表现出的故障非常隐蔽——数据看起来每次都对，但隔一段时间就会丢一次事件，而且丢的时间点毫无规律。这其实是标志位被误清、事件被硬件拒收的典型表现。
3. 实操：从一个高速定时器捕获中断讲起
下面用一个最常见的HSP外设——高速定时器输入捕获中断，完整走一遍U3C5的配置流程。这个例子覆盖面很广，理解了它，其他HSP外设的中断配置基本都是同一套逻辑的排列组合。
3.1 时钟树上的第一道开关：HSP域时钟使能
所有外设操作的第一步都是时钟。U3C5把HSP域的时钟使能放在RCC（复位和时钟控制）里，具体来说是通过AHB高速总线使能寄存器控制的。
// 使能HSP域时钟 __HAL_RCC_HSP_CLK_ENABLE();这一行代码做完，HSP域的外设寄存器才能被访问。但要注意，这里只是“可以使能”的第一步，如果用的是HAL库，还需要进一步配置外设实例的时钟源。比如定时器使用内部高速振荡器还是PLL输出来源，需要在RCC的定时器时钟配置寄存器里单独设置。
时钟源选错不会立刻报错，但会导致事件计数频率不对。我曾经遇到过定时器溢出的时间点完全偏离预估值，排查了很久才发现是时钟源配置被恢复成了默认的低速时钟，定时器实际跑的速度比预期慢了好几倍。
3.2 NVIC配置：别只做了一半
时钟使能之后，按部就班就轮到NVIC配置了。我先给出一段代码，这是标准的HAL库写法：
HAL_NVIC_SetPriority(TIMx_IRQn, 2, 1); // 设置抢占优先级2，子优先级1 HAL_NVIC_EnableIRQ(TIMx_IRQn); // 使能中断这段代码本身没有错，但容易漏掉的是NVIC的组优先级配置。如果不显式设置NVIC优先级分组，默认分组方式可能和你预期的优先级策略完全不同。
优先级分组决定了“抢占优先级”和“子优先级”各占多少位。配置函数是：
HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);NVIC_PRIORITYGROUP_4表示4位全部是抢占优先级，没有子优先级。这样配置的好处是优先级判断简单，高抢占优先级的中断可以任意打断低优先级中断。但如果系统里有多个中断需要精细协调，可以选NVIC_PRIORITYGROUP_2，抢占和子优先级各占2位。
在HSP中断场景里，我的建议是：如果HSP外设承担的是硬实时任务，比如电机控制、高频脉冲计数，就把HSP中断的抢占优先级配置为整个系统里最高的那档。如果HSP外设只是数据采集，不涉及实时控制，优先级可以适当放低，避免频繁打断主循环影响其他业务。
3.3 中断服务函数里到底该写什么
中断服务函数是HSP中断的最后一公里。很多人喜欢在ISR里做大量业务处理，这是个大忌。ISR里应当只做两件事：读硬件状态、记录必要的数据，然后把费时间的处理逻辑放到主循环或低优先级任务里。
对于定时器捕获中断，一个规范的ISR长这样：
void TIMx_IRQHandler(void) { if (__HAL_TIM_GET_FLAG(&htim, TIM_FLAG_CC1) != RESET) { if (__HAL_TIM_GET_IT_SOURCE(&htim, TIM_IT_CC1) != RESET) { __HAL_TIM_CLEAR_IT(&htim, TIM_IT_CC1); // 读取捕获值，存入缓冲区 g_capture_value[g_capture_index++] = __HAL_TIM_GET_COMPARE(&htim, TIM_CHANNEL_1); } } }注意两点：第一，先判断标志位是否有效，再判断中断使能是否真正打开，这是双重保险，防止误触发；第二，读取捕获值之后，立刻清除标志位。如果先清标志再读捕获值，理论上也不会错，但为了保险起见，先读再清的顺序更安全。
3.4 直接操作寄存器 vs 使用HAL库：两种方式的边界
很多嵌入式开发者会纠结到底用寄存器操作还是HAL库。我的态度很明确：能用寄存器操作关键路径的地方，就别依赖HAL库。HAL库封装层数多，每一层都有函数调用开销，虽然这个开销在几十纳秒级别，但中断频繁的时候累积起来相当可观。
比如清标志这个操作，用HAL库是几层函数调用，用寄存器直接写就一行：
TIMx->SR = ~TIM_SR_CC1IF; // 直接清除捕获1事件标志在HSP这种高速外设场景下，中断频率可能几十上百KHz，每次ISR节省几十纳秒到几百纳秒，乘以中断次数，节省的CPU时间非常可观。
但HAL库也不是毫无用处。初始化阶段用它确实能省不少事，尤其是不太熟悉的寄存器位域，HAL库的封装能降低配置错误率。我的习惯是：初始化用HAL库，中断处理主路径用寄存器操作。这个组合兼顾了开发效率和运行效率。
4. 中断优先级与响应延迟：实测数据说话
HSP中断的性能直接关系到整个系统的实时性。U3C5的Cortex-M33内核，中断响应延迟理论值通常是12个时钟周期，但这个数字只考虑了从异常发生到取指第一条ISR指令的部分，真实的端到端延迟比这个数字高得多。
4.1 中断延迟的构成拆解
一次完整的中断响应，延迟包括以下几个部分：
- 硬件压栈时间：CPU自动压入8个寄存器的耗时，通常几个时钟周期
- 向量表跳转时间：从向量表读取ISR地址并开始执行的时间
- 软件处理时间：ISR内部读状态、清标志、数据处理的时间
- 中断嵌套等待时间：如果当前正在处理更高优先级中断，新中断必须等待
在高频中断场景，压栈和出栈的开销甚至可能超过ISR本身的实际工作量。Cortex-M33支持一种叫中断尾链（tail-chaining）的优化机制，如果一个中断退出后立即有另一个中断等待，硬件会跳过压栈出栈过程，直接跳转到新的ISR。这个优化是硬件自动完成的，不需要软件干预，前提是中断优先级够高并且主程序没有长时间关中断。
4.2 实测：不同功耗模式下HSP中断的唤醒延迟
U3C5最大的特点是低功耗，所以HSP中断的唤醒延迟必须实测。我搭建了一个简单的测试环境：HSP域定时器每毫秒产生一次中断，CPU在中断服务函数里翻转一个GPIO，用逻辑分析仪测量GPIO翻转的实际周期。
| 功耗模式 | CPU状态 | 定时器状态 | 实测中断响应延迟 |
|---|---|---|---|
| RUN模式 | 全速运行 | HSP域正常运行 | 约1.8us |
| SLEEP模式 | 内核停止 | 外设时钟保持 | 约2.5us |
| STOP1模式 | 内核停止 | HSP域外设运行 | 约8.2us |
| STOP2模式 | 内核与大部分外设停止 | 仅保留的HSP外设运行 | 约15.6us |
| STANDBY模式 | 全部断电 | 无法运行定时器 | 不支持（需重启） |
这个数据的核心结论是：如果项目对事件响应时间有硬性指标，就必须考虑功耗模式切换带来的额外延迟。不是所有数据都值得把CPU从STOP2模式下叫醒——如果事件频率太高，频繁进出低功耗的功耗开销反而比一直保持SLEEP模式还大。
4.3 优先级分组策略：一个容易被忽视的全局配置
前面提到过NVIC优先级分组，这里展开讲一下。STM32的优先级分组是全局的，系统里所有中断都要遵循同一个分组方案。很多人项目开发到一半，才发现前后配置的优先级分组不一致，导致部分中断进不去或者嵌套关系混乱。
一个典型的错误是：初始化中断A时设置了抢占优先级2，子优先级1，使用的是NVIC_PRIORITYGROUP_4（全部是抢占优先级），之后某个外设的驱动里又用了默认分组配置（可能是NVIC_PRIORITYGROUP_0）。这样两个中断的优先级含义就完全不一样了，中断嵌套关系会变得不可预测。
U3C5实际使用的优先级位数需要查阅参考手册，通常是4位，也就是16个优先级级别。在设计阶段就要把系统里所有中断的优先级列一张表，统一分配，不要在代码里随手写数字。这张表既是文档，也是代码注释，后期维护的价值非常大。
5. 低功耗场景下的HSP中断：让外设“先斩后奏”
如果说前面几节的内容在STM32F系列上也能用，那这一节就是U3C5真正拉开差距的地方。低功耗场景下的HSP中断，核心是“让外设在CPU睡觉时继续工作，需要时再叫醒CPU”。
5.1 进入低功耗前，HSP中断要做什么准备
进入低功耗模式之前，HSP中断的配置不能是默认状态。我总结了一份清单，照着检查就不会出大问题：
- 确认HSP域的时钟在目标低功耗模式下保持运行（阅读RCC的功耗域时钟配置）
- 配置唤醒源：进入低功耗前，确保HSP中断对应的外部事件线映射到EXIT唤醒源
- 设置正确的唤醒极性：根据外设事件是高电平有效还是上升沿有效，配置EXIT的极性
- 在进入低功耗的代码路径中，先清一次所有HSP中断标志，避免残留事件导致进低功耗后立即唤醒
其中第4条特别重要。如果某个中断标志在进入低功耗前就已经置位，而你没有清除它，进入低功耗模式的瞬间CPU就会被唤醒，形成“进-退-进-退”的死循环，功耗反而飙升。
5.2 WFI和WFE：两种不同的等待方式
U3C5支持WFI（Wait For Interrupt）和WFE（Wait For Event）两种低功耗等待指令。它们的区别很有意思：
WFI是“睡到中断来为止”，中断来了之后CPU一定被唤醒。WFE是“睡到事件来为止”，事件可以由中断产生，也可以由调试事件或其他外设事件触发。WFE唤醒后不会进入中断服务函数，而是继续执行WFE之后的指令，这在某些场景下能省掉中断上下文切换的开销。
HSP中断场景下怎么选？如果中断服务函数里要做的事情不多，比如只是置一个标志位让主循环处理，用WFI更省事，也不用担心事件标志残留的问题。如果希望HSP事件到达后主程序立即继续执行而不进入中断状态，可以用WFE加SEV（Send Event）配合。
我实际项目里更常用WFI，因为HSP中断本身就需要在ISR里清标志、读数据，用WFI的逻辑更直接。WFE想要用好，必须非常清楚事件和中断的差异，否则很容易出现两个相同的事件到达却只唤醒一次的情况。
5.3 从STOP模式唤醒后，第一件事是检查什么
CPU被HSP中断从STOP模式唤醒后，系统时钟需要重新稳定，Flash可能需要重新配置等待状态。在进入ISR之前，硬件会自动处理大部分时钟恢复流程，但有些外设的时钟源需要软件重新使能。
我踩过的坑是：U3C5从STOP2唤醒后，HSP域的某个外设时钟没有自动恢复，ISR里读取该外设寄存器，读回来的全是0xFF。用调试器单步看半天，才意识到是该外设的时钟门控位在进入低功耗前被关掉了，唤醒后需要重新置1。
所以从低功耗唤醒的ISR第一段代码，建议先检查关键外设的时钟是否就绪，如果用的是HAL库，可以调用：
__HAL_RCC_HSP_CLK_ENABLE(); // 确保HSP域时钟恢复这个操作是幂等的，即使时钟本来就在运行，重复使能也不会出错。在ISR开头加上这行代码，能避免很多莫名其妙的问题。
6. 排障实录：一次HSP中断“丢事件”的完整追查过程
这一节我完整还原一次真实的排障经历，把排查思路和工具使用过程都写清楚。这次故障发生在U3C5上，现象是HSP域的DMA传输完成中断间歇性丢失，导致采集到的数据流偶尔出现几十毫秒的空洞。
6.1 现象记录与初步定位
系统设计是这样的：HSP域的高速ADC通过DMA搬运数据，每搬运完指定字节数触发一次DMA传输完成中断，CPU在ISR里处理一帧数据。正常运行没有问题，但运行几分钟后，偶尔会出现连续几帧数据没有被处理的情况，数据流上表现为一个明显的时间空洞。
我第一步做的是核对ISR是否被调用。方法是简单粗暴的：在ISR入口打一个调试断点，或者用GPIO翻转来标记ISR执行时刻。实测发现，数据空洞出现时，ISR根本没有被调用，不是ISR里处理出了逻辑错误，而是中断在更上游就没有送达CPU。
6.2 用逻辑分析仪定位根因
为了确定中断丢在哪一段链路，我用逻辑分析仪同时抓了两个信号：DMA的硬件请求信号（从外设引出的测试点）和GPIO翻转的ISR标记信号。
抓到的问题很有意思：DMA硬件请求信号明明已经拉高，也就是DMA确实产生了传输完成事件，但ISR标记信号就是没有翻转。结合参考手册的DMA中断寄存器说明，我怀疑是中断标志被提前清除或者被软件误操作了。
排查代码后发现，在另一个模块的ISR里，有一段“清所有中断标志”的代码：
// 某个不相关模块的ISR DMA_ClearFlag(DMA_FLAG_TC);这个函数没有指定具体的DMA通道和数据流，而是清除了整个DMA控制器的传输完成标志。而HSP域DMA恰好使用同一个DMA控制器的另一个数据流。于是问题链路完全清楚了：A模块的ISR执行时，把B模块（HSP域DMA）的传输完成标志也一并清除了，等CPU响应HSP中断时，标志已经消失，ISR自然进不去，事件就丢了。
6.3 修复方案与验证
修复方案非常简单粗暴：把“清所有中断标志”改成只清除当前数据流对应的标志位，通过通道号精确删除，不要用全清除、全置位的模糊写法。
// 修复后：只清除指定数据流的中断标志 LL_DMA_ClearFlag_TC(DMA1, LL_DMA_CHANNEL_2);改完代码再跑连续24小时压力测试，数据空洞现象没有再出现。
这个故障的教训是：嵌入式代码里任何“一刀切”的寄存器操作都是安全隐患。清标志、关中断、复位外设这些操作，只应该作用于明确指定的对象，绝对不要偷懒写一个全清除的版本，否则后续新增的每个外设都可能成为潜在受害者。
6.4 同类问题的二次排查：共享中断向量的处理
这个故障修复后不久，我又遇到一个类似但更隐蔽的问题：同一个向量上挂了两个外设的中断源。Cortex-M33的NVIC是按IRQ编号分配中断向量，一个IRQ号对应一个ISR函数，但有些HSP外设的中断源会被设计成共用一个IRQ编号。
共用一个IRQ编号时，ISR里必须逐个检查每个外设的中断标志，分别处理，不能只处理一个外设就退出ISR。否则另一个外设的事件就会被“饿死”，永远得不到响应。
一种规范的写法是：
void HSP_Shared_IRQHandler(void) { if (__HAL_TIM_GET_FLAG(&htim1, TIM_FLAG_UPDATE)) { __HAL_TIM_CLEAR_FLAG(&htim1, TIM_FLAG_UPDATE); // 处理定时器1溢出事件 } if (__HAL_TIM_GET_FLAG(&htim8, TIM_FLAG_UPDATE)) { __HAL_TIM_CLEAR_FLAG(&htim8, TIM_FLAG_UPDATE); // 处理定时器8溢出事件 } }这个ISR没有任何返回值，它必须把每一个可能触发中断的外设都检查一遍，才算真正处理完这次中断。如果一个外设的标志被置位但没有被检查，它永远不会进入下一次ISR。
7. 一些值得写进设计规范的经验
最后这部分，我把这几年调HSP中断的经验汇总一下，有些是性能调优的细节，有些是代码规范的建议，没有按优先级排列，想到哪写到哪。
7.1 中断服务函数的三条红线
第一条红线：ISR里绝不能调用阻塞型函数。所谓阻塞型函数，包括延时函数、串口打印、Flash写入这些。在ISR里调用HAL_Delay会让整个系统挂死，因为延时依赖SysTick中断，而SysTick的优先级可能比当前ISR低，两个中断就互相等待了。
第二条红线：ISR和主循环共享的数据必须用volatile修饰。C编译器看到普通变量，可能会把它优化到寄存器里，主循环里读这个变量，读到的可能是一份过期的缓存值。加上volatile，能确保每次访问都从内存中读取。
第三条红线：ISR里尽量少做计算。尤其避免浮点运算和除法，这些操作在Cortex-M33上虽然比M0快得多，但仍然要消耗几十个时钟周期。如果在ISR里做复杂的数学处理，中断占用时间过长，其他同样优先级或略低优先级的中断就会被推迟，最终破坏系统的实时性。
7.2 中断优先级分配的顺序：先高后低还是先低后高
我的建议是先把高优先级中断定下来。一个系统里真正有硬实时要求的中断并不多，比如定时器同步、故障保护，这些抢占优先级直接给最高档。其他数据采集中断、通讯中断、用户按键中断，从低往高档位排。
这样做的理由是：高优先级中断抢占低优先级中断是硬件行为，只要优先级配置正确，不会被软件逻辑干扰。而如果把数据采集中断优先级配得比故障保护还高，故障发生时CPU正在处理数据采集，故障保护被推迟响应，整个系统的安全底线就没了。
7.3 硬件层的中断丢事件保护：环形缓冲区
如果HSP中断触发频率非常高，ISR来不及把数据全部处理完，即使ISR做得再精简，也可能丢数据。这种情况需要引入硬件层的缓冲机制，最常用的是环形缓冲区。
#define BUF_SIZE 256 volatile uint16_t ring_buf[BUF_SIZE]; volatile uint16_t head = 0; volatile uint16_t tail = 0; // ISR中写入数据 ring_buf[head] = sample_data; head = (head + 1) % BUF_SIZE; // 主循环中读取数据 while (head != tail) { process(ring_buf[tail]); tail = (tail + 1) % BUF_SIZE; }ISR只负责把数据写到缓冲区里，主循环在合适的时间批量处理，这样即使主循环被其他任务阻塞了几百毫秒，数据也还在缓冲区里，不会丢。缓冲区大小要根据峰值事件速率和主循环最大延迟来定，我一般预留2到3倍的余量，避免缓冲区经常写满。
7.4 关于工具链和调试的一点补充
调HSP中断，用调试器单步跟踪会有很大的局限。因为中断的实时性要求高，单步跟踪会改变时间行为，很多问题在单步下反而不复现了。我的经验是：用GPIO翻转标记ISR执行时刻，用逻辑分析仪抓时间线，再用串口把关键事件编号打印到缓冲区，事后统一分析。
其中串口打印要注意，ISR里不能直接用阻塞式串口发送，否则会拖慢中断响应。可以把待打印的日志写到一个内存缓冲区，主循环里再统一送串口。或者用DMA方式发送串口数据，让串口硬件自己搬运，不占用CPU。
写在最后的使用体会
从最初在HSP中断上栽跟头，到后来把整个机制理清楚，我觉得最关键的一步还是抛开对HAL库的过度依赖，老老实实把参考手册里HSP域和NVIC相关的寄存器读了一遍。很多问题在代码层面看起来千奇百怪，回到寄存器层面就一句话的事：某个使能位没打开，或者某个标志被误清了。
如果你正在用STM32U3C5做低功耗设计，建议先把HSP域的几个外设中断链路画一张图：事件源、状态标志、使能位、映射的IRQ编号、NVIC优先级，全部列清楚，再动手写代码。这张图省下来的调试时间，远比画图花的时间多。
