关于FreeRTOS函数xSemaphoreGiveFromISR卡死的问题

0. 概述

关于FreeRTOS函数xSemaphoreGiveFromISR卡死的问题

1. 遇到的问题

在使用FreeRTOS调试激光雷达检测面积的项目的时候，遇到一个现象：在新加了一个线程之后，把程序下载到板子之后程序不会运行（实际上已经运行了，原因后续再进行解释），此时再下载一次程序程序才能正常运行起来。

具体现象

1. 程序下载之后运行，发现没有正确的运行现象；此时再下载一次程序即可正常运行。
2. 板子在正常运行状态下，如果下载程序，发现程序无法运行。
3. 板子整体断电上电之后每次都能正常运行。
4. 程序如果未运行到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这个问题的一个收获吧。）

此时根据上面的内容进行了如下的尝试

1. 更改整个工程的优化等级为0发现可以正常运行了！！！
2. 更改工程优化等级为1，手动单独将某个.c文件的优化等级改为0。经过很久的尝试（文件太多了，汗），发现将stm32h7xx_hal_gpio.c的优化等级改为0之后程序可以运行，因此就定位到问题可能出在了GPIO上面，也给后文的调试找到了方向。（但是stm32h7xx_hal_gpio.c这个文件是STM32CubeMX自动生成的，因此不太愿意用这种修改优化等级的办法解决，因此还需要后面再排查一下问题）

5. 尝试使用DAP在线调试的功能看程序是否运行了

调试的时候发现程序没运行起来的时候实际上是进入了xSemaphoreGiveFromISR函数，卡在了下图这里：

其实这个时候就应该发现问题是出现在这里了（在线仿真状态下程序一直卡在这里！）

3. 问题原因分析

这个问题其实是STM32CUBEMX自动生成FreeRTOS代码的坑：

1. HAL库初始化完之后会自动打开GPIO的输入中断（当然其它中断也可能会发生类似的问题）；
2. FreeRTOS的初始化（包含任务、消息队列、信号量等OS相关内容的创建）在HAL库及其外设初始化的后面；
3. 程序需要在GPIO的中断里面进行信号量的释放，以表示IST8310转换完成了，可以在线程里面进行读取了；
4. IST8310的数据完成引脚可能会在FreeRTOS的初始化之前完成，从而在FreeRTOS还没初始化的时候就进入GPIO的中断进行信号量的释放了。

上述过程就会导致：

1. 如果程序处于还未运行的状态（可能是程序卡死或者其它状态），此时GPIO没有中断，此时下载程序的话可以保证IST8310的数据完成引脚在FreeRTOS的初始化之后触发中断，因此程序会正常运行；
2. 如果程序处于运行的状态，再下载程序的话，一瞬间IST8310的DRY引脚会变为低电平（IST8310转换比较快），此时IST8310芯片还处于上电的状态，因此改低电平状态会一直保持，此时新程序运行的时候会发生这种现象：IST8310的数据完成引脚在FreeRTOS的初始化之前触发中断，此时在GPIO中断里面IST8310_DRYBinaryHandle这个信号量还没被创建，因此会使程序整体卡死在Handle模式，不会回到正常的Thread模式，任务无法正常调度，表现为整体的卡死，表现为任务下载完程序之后程序不会自动运行。

4. 解决办法

1. 定义一个全局变量用来记录OS是否已经初始化完成了。uint8_t IS_OS_Running = 0;
2. 在main函数的开始地方将变量值设为0，表示OS还没运行（初始化）。IS_OS_Running = 0;
3. 在void MX_FREERTOS_Init(void)函数的结尾处将变量设为1，表示OS初始化完成了。
4. 在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初始化完成之前会进入一些中断处理函数导致卡死。