0. 概述
关于FreeRTOS函数xSemaphoreGiveFromISR卡死的问题
1. 遇到的问题
在使用FreeRTOS调试激光雷达检测面积的项目的时候,遇到一个现象:在新加了一个线程之后,把程序下载到板子之后程序不会运行(实际上已经运行了,原因后续再进行解释),此时再下载一次程序程序才能正常运行起来。
具体现象
- 程序下载之后运行,发现没有正确的运行现象;此时再下载一次程序即可正常运行。
- 板子在正常运行状态下,如果下载程序,发现程序无法运行。
- 板子整体断电上电之后每次都能正常运行。
- 程序如果未运行到
void IST8310Task(void *argument)
这个线程的for循环之前重新下载程序的话(这个线程的主要任务会延时大约3s之后才启动),程序是可以正常运行的;但是如果运行到上面的线程具体任务之后再进行下载程序,程序就无法运行了。
2. 尝试的解决办法
1. 更换调试器,修改调试器的设计
通过修改调试器的设置尝试解决:尝试了多个配置发现问题依旧
将使用的H7TOOL更换为无线DAP和STLINK V3发现问题依旧
最终定位到这个问题不是仿真器以及仿真器设置的问题
2. 尝试屏蔽新加入的线程代码
void IST8310Task(void *argument)//IST8310的控制线程
{
extern QueueHandle_t IST8310QueueHandle;//IST8310的数据
extern SemaphoreHandle_t IST8310_DRYBinaryHandle;//IST8310转换完成的信号量
imusensorStruct_t IST8310Data;
BaseType_t xResult =pdPASS;//消息队列发送状态
osDelay(3000);
//init error handle
if(IST8310_Init() != IST8310_NO_ERROR)
{
for(;;)
{
osDelay(100);
}
}
osDelay(100);
for(;;)
{
xResult = xSemaphoreTake(IST8310_DRYBinaryHandle,0);//等待DRY完成
if(xResult ==pdPASS)
{
IST8310_Updata(&IST8310Data);
IST8310_Data_Single_Measurement_Once();
IST8310Data.yaw_RAW = atan(IST8310Data.rawMag_X/IST8310Data.rawMag_Y)/2/3.141592654*360;
xQueueOverwrite(IST8310QueueHandle,&IST8310Data);//覆盖消息队列发送
}
osDelay(50);
}
}
上述代码主要完成IST8310的单次数据读取,即在循环中等待IST8310的转换完成信号量(在GPIO的中断处理函数里面进行信号量的释放),然后进行数据读取,然后与IST8310通信进行下一个数据的读取,当IST8310数据完成之后会将其DRY引脚变为低电平,此时会进入到下面的GPIO中断处理函数。
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) __attribute__((optnone))
{
extern SemaphoreHandle_t IST8310_DRYBinaryHandle;//IST8310转换完成的信号量
BaseType_t xHigherPriorityTaskWoken = pdFALSE;//定义一个变量,记录一下退出中断是否进行任务切换
BaseType_t xResult;
if (GPIO_Pin==IST_DRDY_Pin) //判断是否为IST8310的外部中断
{
xResult = xSemaphoreGiveFromISR(IST8310_DRYBinaryHandle,&xHigherPriorityTaskWoken);//释放信号量,告诉任务已经发送完了,如果有更高优先级任务就绪就进行任务切换
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);//如果需要的话就进行一次任务切换
}
}
此时经过把该线程的代码屏蔽之后,即该线程不启动,程序就可以正常运行,每次下载完程序之后都会正常运行。但此时并没有发现具体问题所在,还需要尝试其它办法进行解决。
3. 尝试加大程序的栈空间
此时怀疑是程序栈太小了,程序可能偶尔跑飞了,但是实际上把栈空间变为原来的16倍现象仍然一致,因此排除这个问题。
4. 尝试调整程序的优化等级
将程序的优化等级调整为0之后发现程序可以正常运行!!!
因此,此时怀疑是keil优化的问题(keil无端背锅0^0,因为keil的代码优化确实会出现一些问题)。
经过查阅各种网上资料,找到了在keil里面进行设置优化等级各种办法,包括不限于:
- 整个工程的优化等级调整(最简单,直接在工程设置里面进行调整即可)
- 文件夹或者单个文件的优化等级调整(右键文件夹或者文件进行相关设置)
- 单个函数的优化等级(在函数的定义后面加上代码:
__attribute__((optnone))
太强了,也算是这次debug这个问题的一个收获吧。)
此时根据上面的内容进行了如下的尝试
- 更改整个工程的优化等级为0发现可以正常运行了!!!
- 更改工程优化等级为1,手动单独将某个.c文件的优化等级改为0。经过很久的尝试(文件太多了,汗),发现将
stm32h7xx_hal_gpio.c
的优化等级改为0之后程序可以运行,因此就定位到问题可能出在了GPIO上面,也给后文的调试找到了方向。(但是stm32h7xx_hal_gpio.c
这个文件是STM32CubeMX自动生成的,因此不太愿意用这种修改优化等级的办法解决,因此还需要后面再排查一下问题)
5. 尝试使用DAP在线调试的功能看程序是否运行了
调试的时候发现程序没运行起来的时候实际上是进入了xSemaphoreGiveFromISR
函数,卡在了下图这里:
其实这个时候就应该发现问题是出现在这里了(在线仿真状态下程序一直卡在这里!)
3. 问题原因分析
这个问题其实是STM32CUBEMX自动生成FreeRTOS代码的坑:
- HAL库初始化完之后会自动打开GPIO的输入中断(当然其它中断也可能会发生类似的问题);
- FreeRTOS的初始化(包含任务、消息队列、信号量等OS相关内容的创建)在HAL库及其外设初始化的后面;
- 程序需要在GPIO的中断里面进行信号量的释放,以表示IST8310转换完成了,可以在线程里面进行读取了;
- IST8310的数据完成引脚可能会在FreeRTOS的初始化之前完成,从而在FreeRTOS还没初始化的时候就进入GPIO的中断进行信号量的释放了。
上述过程就会导致:
- 如果程序处于还未运行的状态(可能是程序卡死或者其它状态),此时GPIO没有中断,此时下载程序的话可以保证IST8310的数据完成引脚在FreeRTOS的初始化之后触发中断,因此程序会正常运行;
- 如果程序处于运行的状态,再下载程序的话,一瞬间IST8310的DRY引脚会变为低电平(IST8310转换比较快),此时IST8310芯片还处于上电的状态,因此改低电平状态会一直保持,此时新程序运行的时候会发生这种现象:IST8310的数据完成引脚在FreeRTOS的初始化之前触发中断,此时在GPIO中断里面
IST8310_DRYBinaryHandle
这个信号量还没被创建,因此会使程序整体卡死在Handle模式,不会回到正常的Thread模式,任务无法正常调度,表现为整体的卡死,表现为任务下载完程序之后程序不会自动运行。
4. 解决办法
- 定义一个全局变量用来记录OS是否已经初始化完成了。
uint8_t IS_OS_Running = 0;
- 在main函数的开始地方将变量值设为0,表示OS还没运行(初始化)。
IS_OS_Running = 0;
- 在
void MX_FREERTOS_Init(void)
函数的结尾处将变量设为1,表示OS初始化完成了。 - 在GPIO中断处理函数里面对变量
IS_OS_Running
进行判断,参考如下代码:
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) __attribute__((optnone))
{
extern SemaphoreHandle_t IST8310_DRYBinaryHandle;//IST8310转换完成的信号量
BaseType_t xHigherPriorityTaskWoken = pdFALSE;//定义一个变量,记录一下退出中断是否进行任务切换
BaseType_t xResult;
if (GPIO_Pin==IST_DRDY_Pin) //判断是否为IST8310的外部中断
{
if(IS_OS_Running ==1)//cubemx的坑,freertos卡死,因为os没启动的时候进入了中断,中断里面释放信号量,造成卡死
{
xResult = xSemaphoreGiveFromISR(IST8310_DRYBinaryHandle,&xHigherPriorityTaskWoken);//释放信号量,告诉任务已经发送完了,如果有更高优先级任务就绪就进行任务切换
}
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);//如果需要的话就进行一次任务切换
}
}
上述代码可以实现:在OS还未初始化完成的时候不进行信号量的释放操作,只有OS被成功初始化之后才进行信号量释放,从而避免以上的问题。
5. 总结
这个问题可以简单归结为STM32CubeMX生成代码的先后逻辑顺序问题。在使用的时候要注意:在中断处理函数里面进行信号量等与OS相关的代码要先判断一下OS是否已经初始化完毕了,因为可能会出现在OS初始化完成之前会进入一些中断处理函数导致卡死。