工作总结及记录

此后所有工作中遇到的问题及如何解决的经验都会统计在这：

FreeRtos

1.堆栈溢出

项目背景：
近期在项目中遇到了程序代码跑着跑着，systick突然变慢的情况，甚至出现了有的Task正常运行，有的Task不正常运行的情况。这个问题查了很久，不论是时钟的寄存器，还是堆栈溢出，还是内存越界，都有在排查，但还是没有查到问题在哪。但凡事总会有个原因，后经过长时间压测及分析，终于找到了程序运行异常的原因…
分析过程：
当时程序代码在压测过程中，出现了某个Task的串口消息出现异常打印的情况，经过分析是消息队列出现了问题，而在消息队列出现问题之后，马上出现了串口打印的时间间隔和FreeRtos的时间间隔不一样(世界时间过了5.7-5.9s，但是OS时间还是过了3s)。于是，我们进行debug，当一旦有消息队列收到消息，便马上停在接收消息队列的地方。这时候，我们去查看了内存以及堆栈，果然，爆栈了，还不止一个Task爆栈。当初觉得没有爆栈的可能是因为做过堆栈的缩小，从1284Byte缩小到644Byte，这时候程序会立马进入FreeRtos的钩子函数，导致看门狗复位，于是就没把堆栈当回事。。。。
后来调用了FreeRtos的官方函数uxTaskGetStackHighWaterMark，打印每个Task的剩余堆栈大小，发现果然剩余堆栈的大小为0*4Byte，爆了！！！
具体原因：
后查阅相关文章终于发现了原因：FreeRTOS 的栈溢出检测机制

FreeRTOS 提供了两种栈溢出检测机制，这两种检测都是在任务切换时才会进行：
方法一
在任务切换时检测任务栈指针是否过界了，如果过界了，在任务切换的时候会触发栈溢出钩子函数。
void vApplicationStackOverflowHook( TaskHandle_t xTask,signed char *pcTaskName );
用户可以在钩子函数里面做一些处理。这种方法不能保证所有的栈溢出都能检测到。比如任务在执行
的过程中出现过栈溢出。任务切换前栈指针又恢复到了正常水平，这种情况在任务切换的时候是检测
不到的。又比如任务栈溢出后，把这部分栈区的数据修改了，这部分栈区的数据不重要或者暂时没有
用到还好，但如果是重要数据被修改将直接导致系统进入硬件异常，这种情况下，栈溢出检测功能也
是检测不到的。
使用方法一需要用户在 FreeRTOSConfig.h 文件中配置如下宏定义：#define configCHECK_FOR_STACK_OVERFLOW 1方法二
任务创建的时候将任务栈所有数据初始化为 0xa5，任务切换时进行任务栈检测的时候会检测末
尾的 16 个字节是否都是 0xa5，通过这种方式来检测任务栈是否溢出了。相比方法一，这种方法的速
度稍慢些，但是这样就有效地避免了方法一里面的部分情况。 不过依然不能保证所有的栈溢出都能检
测到，比如任务栈末尾的 16 个字节没有用到，即没有被修改，但是任务栈已经溢出了，这种情况是
检测不到的。 另外任务栈溢出后，任务栈末尾的 16 个字节没有修改，但是溢出部分的栈区数据被修
改了，这部分栈区的数据不重要或者暂时没有用到还好，但如果是重要数据被修改将直接导致系统进
入硬件异常，这种情况下，栈溢出检测功能也是检测不到的。
使用方法二需要用户在 FreeRTOSConfig.h 文件中配置如下宏定义：#define configCHECK_FOR_STACK_OVERFLOW 2钩子函数
钩子函数的主要作用就是对原有函数的功能进行扩展，用户可以根据自己的需要往里面添加相关的测
试代码， 大家可以在 FreeRTOS 工程中检索这个钩子函数 vApplicationStackOverflowHook 所在的位置。
除了 FreeRTOS 提供的这两种栈溢出检测机制，还有其它的栈溢出检测机制，大家可以在 Mircrium 官方发布的如下这个博文中学习：
https://www.micrium.com/detecting-stack-overflows-part-2-of-2/
对于这种溢出检测，确实不容易检测到，多半进入硬件错误中断，所以以后要是遇到程序硬件中断死循环，清注意检测堆栈大小。
不确定的时候，先使用printf调试打印任务栈的剩余，选择一个合理安全的值作为堆栈设置，这确实是个难以简单计算的东西。

我们用的是方法一…所以就导致了程序要跑一阵才会出现栈溢出的情况，宝宝心里苦啊。。。。到此，问题解决！

2.中断优先级的设定

项目背景：
和第一点堆栈溢出的情况一样，在查找问题的过程中，发现了中断优先级的设定也是具有一定问题的。。。。（咱就说这项目有多少坑吧）
分析过程：
在第一点分析问题的过程中，程序运行了一段时间后，突然卡死了，然后我停止运行，想看看断点停在那，您猜怎么着，进list.c文件的vListInsert函数里面卡在For循环了！（因为事先关了看门狗，所以不会复位）后面就排查问题被，查资料什么的，果然发现点东西：

  /* *** NOTE ************************************************************  If you find your application is crashing here then likely causes are*  listed below.  In addition see https://www.FreeRTOS.org/FAQHelp.html for*  more tips, and ensure configASSERT() is defined!*  https://www.FreeRTOS.org/a00110.html#configASSERT**   1) Stack overflow -*      see https://www.FreeRTOS.org/Stacks-and-stack-overflow-checking.html*   2) Incorrect interrupt priority assignment, especially on Cortex-M*      parts where numerically high priority values denote low actual*      interrupt priorities, which can seem counter intuitive.  See*      https://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html and the definition*      of configMAX_SYSCALL_INTERRUPT_PRIORITY on*      https://www.FreeRTOS.org/a00110.html*   3) Calling an API function from within a critical section or when*      the scheduler is suspended, or calling an API function that does*      not end in "FromISR" from an interrupt.*   4) Using a queue or semaphore before it has been initialised or*      before the scheduler has been started (are interrupts firing*      before vTaskStartScheduler() has been called?).**********************************************************************/

具体原因：
如上文所示，进这有四个条件：

1. 堆栈溢出；
2. 错误的中断优先级分配；
3. 在Task调度或者关键部分暂停时调用API函数，或者在中断里面调用FreeRTOS官方的非FromISR结尾的函数；
4. 在队列或者信号量未被初始化前调用它们。

第一个我们已经知道了，肯定是有堆栈溢出的，毋庸置疑，但我去查中断优先级的时候，发现外设的中断优先级全部默认是0，而我们的FreeRTOS管理的优先级configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY才为4，因为数字越大，优先级越低，因此会导致外设中断优先级高于FreeRtos的中断优先级，这时候调用任何一个FreeRTOS官方的API函数，就会导致程序卡在这个死循环。