最近在使用FreeRTOS的时候，突然发现程序在运行了几分钟之后所有的任务都不再调用了，只有几个中断能正常使用，看来是系统挂掉了，连续测试了几次想找出问题，可是这个真的有点不知所措。
我先看了下文档里的常见错误，发现和我现在有关系的也就堆栈大小的设置和中断嵌套优先级的设置了，不过我这几个任务都是比较简单的，没有太多的变量，那么现在设置的堆栈大小是够的，不然也不会运行一段时间才奔溃，应该一运行就会奔溃的。那么把问题就集中到了中断嵌套优先级里，我尝试了把 configKERNEL_INTERRUPT_PRIORITY = 15/configMAX_SYSCALL_INTERRUPT_PRIORITY = 10结果程序比之前更不如，直接进入了HardFault异常，那么只能看看相关的说明和解释了。
看了下文档里的介绍，configKERNEL_INTERRUPT_PRIORITY 是设置系统心跳时钟的中断优先级，configMAX_SYSCALL_INTERRUPT_PRIORITY是设置中断安全版本FreeRTOS API 可以运行的最高中断优先级。且建立一个全面的中断嵌套模型需要设置 configMAX_SYSCALL_INTERRUPT_PRIRITY
为比configKERNEL_INTERRUPT_PRIORITY 更高的优先级。而基于Cortex-M3中断优先级的特点，优先级是数值越低优先级越高，即0是最高优先级，255是最低优先级。貌似我设置的和这个不冲突啊，没办法去google去，找到了一个解释：
configMAX_SYSCALL_INTERRUPT_PRIORITY needs to be a raw priority value as it is written to the NVIC priority registers in the Cortex-M3 device, as documented in the ARM manuals. The priorities of 0..15 are not real Cortex-M3 priorities, and are simplified priorities for use in some library calls (because the real priorities are so complex on Cortex-M devices).
If you want a simplified priority of 8, then you need to set configMAX_SYSCALL_INTERRUPT_PRIORITY to 0x8n, where n can be any value, but by convention, and for future proofing in case future STM32 parts implement more priority bits, should be set to f. Therefore, the priority you want is 0x8f.
“the code app-faults at "svc 0" in vPortStartFirstTask”
Presumably a hard fault because you are attempting a call to effectively a synchronous interrupt while simultaneously having that interrupt masked out.
看到这里的解释我知道了问题，原来我之前那样的设置是相当于无效的， 出问题时肯定的了， 优先级设置原来是0xbx,才相当于11的优先级，原来/* equivalent to 0xb0, or priority 11. */这段注释是这个意思 ，不过一般看到这个注释还真联系不起来，还好找到原因了，下面测试下任务是不是还会挂掉。
下面这个图是一个RTOS中断优先级的说明，如果系统的优先级比configMAX_SYSCALL_INTERRUPT_PRIORITY高，则这些中断可以直接触发，不会被RTOS延时，如果优先级比其低，则有可能被RTOS延时。
在使用STM32Cbue调用FreeRTOS，系统默认：configMAX_SYSCALL_INTERRUPT_PRIORITY=15，configKERNEL_INTERRUPT_PRIORITY=5，故在中断优先级为0～4的中断，均不会被内核延迟，并且可嵌套。在5～15之间的中断均会被系统内核延迟。