第11章 FreeRTOS任务栈大小确定及其溢出检测

本章节为大家讲解FreeRTOS任务栈大小的确定方法以及栈溢出检测方法。给任务分配多大的栈空间，一直是初学者比较头疼的问题，本章就主要为大家讲解如何解决此问题。
本章教程配套的例子含Cortex-M3内核的STM32F103和Cortex-M4内核的STM32F407以及F429。

11.1 任务栈大小的确定

在基于RTOS的应用设计中，每个任务都需要自己的栈空间，应用不同，每个任务需要的栈大小也是不同的。将如下的几个选项简单的累加就可以得到一个粗略的栈大小：
u 函数的嵌套调用，针对每一级函数用到栈空间的有如下四项：
l 函数局部变量。
l 函数形参，一般情况下函数的形参是直接使用的CPU寄存器，不需要使用栈空间，但是这个函数中如果还嵌套了一个函数的话，这个存储了函数形参的CPU寄存器内容是要入栈的。所以建议大家也把这部分算在栈大小中。
l 函数返回地址，针对M3和M4内核的MCU，一般函数的返回地址是专门保存到LR（Link Register）寄存器里面的，如果这个函数里面还调用了一个函数的话，这个存储了函数返回地址的LR寄存器内容是要入栈的。所以建议大家也把这部分算在栈大小中。
l 函数内部的状态保存操作也需要额外的栈空间。

u 任务切换，任务切换时所有的寄存器都需要入栈，对于带FPU浮点处理单元的M4内核MCU来说，FPU寄存器也是需要入栈的。

u 针对M3内核和M4内核的MCU来说，在任务执行过程中，如果发生中断：
l M3内核的MCU有8个寄存器是自动入栈的，这个栈是任务栈，进入中断以后其余寄存器入栈以及发生中断嵌套都是用的系统栈。
l M4内核的MCU有8个通用寄存器和18个浮点寄存器是自动入栈的，这个栈是任务栈，进入中断以后其余通用寄存器和浮点寄存器入栈以及发生中断嵌套都是用的系统栈。

u 进入中断以后使用的局部变量以及可能发生的中断嵌套都是用的系统栈，这点要注意。
实际应用中将这些都加起来是一件非常麻烦的工作，上面这些栈空间加起来的总和只是栈的最小需求，实际分配的栈大小可以在最小栈需求的基础上乘以一个安全系数，一般取1.5-2。上面的计算是我们用户可以确定的栈大小，项目应用中还存在无法确定的栈大小，比如调用printf函数就很难确定实际的栈消耗。又比如通过函数指针实现函数的间接调用，因为函数指针不是固定的指向一个函数进行调用，而是根据不同的程序设计可以指向不同的函数，使得栈大小的计算变得比较麻烦。
另外还要注意一点，建议不要编写递归代码，因为我们不知道递归的层数，栈的大小也是不好确定的。
一般来说，用户可以事先给任务分配一个大的栈空间，然后通过第8章介绍的调试方法打印任务栈的使用情况，运行一段时间就会有个大概的范围了。这种方法比较简单且实用些。
l 函数栈大小确定
函数的栈大小计算起来是比较麻烦的，那么有没有简单的办法来计算呢？有的，一般IDE开发环境都有这样的功能，比如MDK会生成一个htm文件，通过这个文件用户可以知道每个被调用函数的最大栈需求以及各个函数之间的调用关系。但是MDK无法确定通过函数指针实现函数调用时的栈需求。另外，发生中断或中断嵌套时的现场保护需要的栈空间也不会统计。
关于MDK生成的map和htm文件的使用，我们安富莱电子有出过一期视频教程，可以在这里查看：http://bbs.armfly.com/read.php?tid=15408

11.2 什么是栈溢出

前面为大家讲解了如何确定任务栈的大小，那什么又是栈溢出呢？简单的说就是用户分配的栈空间不够用了，溢出了。下面我们举一个简单的实例，栈生长方向从高地址向低地址生长（M4和M3是这种方式）。

（1） 上图标识1的位置是RTOS的某个任务调用了函数test()前的SP栈指针位置。

void  test (void);
{
     int i;
     int array[10];
     :
     :
     // Code
}

（2） 上图标识2的位置是调用了函数test需要保存返回地址到栈空间。这一步不是必须的，对于M3和M4内核是先将其保存到LR寄存器中，如果LR寄存器中有保存上一级函数的返回地址，需要将LR寄存器中的内容先入栈。
（3） 上图标识3的位置是局部变量int i和int array[10]占用的栈空间，但申请了栈空间后已经越界了。这个就是所谓的栈溢出了。如果用户在函数test中通过数组array修改了这部分越界区的数据且这部分越界的栈空间暂时没有用到或者数据不是很重要，情况还不算严重，但是如果存储的是关键数据，会直接导致系统崩溃。
（4） 上图标识4的位置是局部变量申请了栈空间后，栈指针向下偏移（返回地址+变量i+10个数组元素）*4 =48个字节。
（5） 上图标识5的位置可能是其它任务的栈空间，也可能是全局变量或者其它用途的存储区，如果test函数在使用中还有用到栈的地方就会从这里申请，这部分越界的空间暂时没有用到或者数据不是很重要，情况还不算严重，但是如果存储的是关键数据，会直接导致系统崩溃。

11.3 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提供的这两种栈溢出检测机制，还有其它的栈溢出检测机制，大家可以在Mircrium官方发布的如下这个博文中学习：https://www.micrium.com/detecting-stack-overflows-part-2-of-2/
  钩子函数
  钩子函数的主要作用就是对原有函数的功能进行扩展，用户可以根据自己的需要往里面添加相关的测试代码，大家可以在FreeRTOS工程中检索这个钩子函数vApplicationStackOverflowHook所在的位置。