Cortex-M3平台FreeRTOS的NVIC配置相关问题咨询

你已经定位修复的优先级分组、应用中断优先级阈值两个问题，是这类偶发HardFault、看门狗复位的最高发诱因，剩下的常见坑点按排查优先级列如下：

• 优先级数值逻辑搞反
  Cortex-M内核中断优先级规则是数值越小，抢占优先级越高，不少人写配置时会下意识把“高优先级”对应大数值，要么把调用FreeRTOS API的中断优先级数值设小踩了红线，要么把需要实时响应的中断设成大数值导致响应不及时。尤其你用的StdPeriph库配置时要明确：所有调用FreeRTOS API的中断，优先级数值必须大于configMAX_SYSCALL_INTERRUPT_PRIORITY定义的值，等于、小于都不行。
• 手动操作内核中断屏蔽寄存器破坏临界区逻辑
  你用的v7.3.0属于FreeRTOS早期版本，端口层临界区是通过配置BASEPRI寄存器实现的，只屏蔽优先级高于阈值的中断，不会关全局中断。如果遗留代码里有手动写汇编操作PRIMASK、BASEPRI寄存器直接关全局中断的逻辑，且关中断时间超过系统节拍周期，很容易导致系统节拍中断丢步、任务调度链表损坏，出现无规律的HardFault。另外在中断服务函数里调用带FromISR后缀的API后，必须在退出中断前调用portYIELD_FROM_ISR触发上下文切换，否则高优先级任务就绪后不会立刻调度，很容易出现任务超时、喂狗不及时的问题。
• 系统异常优先级配置错误
  Cortex-M3的SysTick、PendSV、SVCall三个和FreeRTOS调度强相关的系统异常，优先级必须设为最低档位：你现在用NVIC_PriorityGroup_4全抢占模式下，这三个异常的抢占优先级要设为15（即最低优先级），绝对不能设为比configMAX_SYSCALL_INTERRUPT_PRIORITY更高（数值更小）的优先级，否则调度逻辑会被打断，出现完全无规律的内存访问错误。这类问题很多是初始化外设时写错NVIC通道号，误改了系统异常优先级导致的，往往跑几天才会复现一次，排查难度极高。
• 中断服务函数绑定错误
  IAR EWARM v6.7版本的启动文件向量表是硬编码的弱符号函数名，如果自己写的外设中断服务函数名和启动文件里的定义不一致，中断触发时会直接跳转到默认的中断死循环，触发看门狗复位。这类问题同样偶发——只有对应外设触发中断时才会死机，平时运行完全正常，很容易被误判为其他逻辑问题。
• 中断栈溢出
  Cortex-M3的中断上下文使用独立的MSP栈空间，不占用各任务的栈，FreeRTOS v7.3.0默认没有开启中断栈溢出检测。如果中断服务函数逻辑复杂、定义了大体积局部变量、存在多层函数调用，或者出现多层中断嵌套，很容易把中断栈踩穿，篡改栈内的返回地址触发HardFault。排查时可以在系统初始化时把中断栈空间全部填充为固定魔数（比如0xA5），跑一段时间后读取栈空间末尾的魔数被覆盖的长度，就能判断是否存在栈空间不足的问题。
• NVIC优先级寄存器位操作错误
  STM32F205的NVIC优先级寄存器是8位位宽，但实际仅高4位有效，低4位保留读0写忽略。如果有代码直接操作寄存器写优先级值时没有左移4位，比如要设优先级5直接写入0x05，实际生效的优先级是0（高4位为0），直接变成最高优先级档位，一旦中断里调用了FreeRTOS API就会立刻触发Fault。用StdPeriph库的NVIC接口会自动处理移位，但是自己写汇编操作寄存器时很容易漏这个步骤。

你目前把所有应用中断优先级设到阈值以下的方案是完全可行的，不需要逐行检查中断里有没有调用API，后续可以按外设实时性需求调整优先级档位：高速采样、实时收发类的外设中断可以设为略高于普通外设的优先级（数值更小，但仍大于configMAX_SYSCALL_INTERRUPT_PRIORITY），低速外设、低实时性需求的中断设为更低档位即可，避免中断阻塞时间过长。

内容的提问来源于stack exchange，提问作者RLepa.1