问题描述

控制系统使用的是STM32F4+UCOSII 抢占型内核，最近一段时间出现了程序跑一段时间之后操作系统直接死掉的问题，表现为：操作系统中设有优先级很低的呼吸灯任务，只要操作系统在正常工作，呼吸灯就会不停的跳动，但是当出现问题时，呼吸灯停止跳动，控制底盘运动的任务也死掉，底盘处于失控状态，LCD所在的任务也死掉，不再进行刷新，推测为所有的操作系统的任务均死掉，不能正常工作，但是中断仍然可以响应，写在定时器中断中的急停操作是可以执行的。

问题分析

• 怀疑是进入了一些错误中断

• 怀疑是指针或者堆栈出了问题

• 怀疑最高优先级的任务中存在死循环

• 怀疑操作系统中存在一些bug

• 怀疑是中断引起的程序一直在中断中，不能进入正常任务 
  解决方案

• 对错误中断进行排查分析，程序中开启的错误中断响应只有HardFault，在进入HardFault的中断服务函数后会进行相应的处理 
  `/* *

• @brief This function handles Hard Fault exception.

• @param None

• @retval None 
  */ 
  void HardFault_Handler(void) 
  { 
  /* Go to infinite loop when Hard Fault exception occurs */ 
  while (1) 
  { 
  BEEP_TOGGLE; 
  Delay_ms(500); 
  } 
  }` 
  因此，从表现上看基本可以排除进入Hard Fault的可能，除此之外，Hard Fault的中断优先级为 -1，如果程序是死在HardFault中，那么其他的中断响应应该也是无法响应的，这与问题的表现，中断仍然可以响应矛盾，因此可以断定，不是进入了HardFault和其他的一些问题中断。

• 关于指针和堆栈的问题，一般有问题会直接进Hard Fault，而此时基本已经排除了Hard Fault的问题，除此之外也尝试扩大了硬件和操作系统的堆栈，问题没有解决，确定不是这里有问题。

• 
  

• 关于操作系统的Bug在网上查了不少，早期的操作系统确实存在问题但是系统中使用的2.92版本应该是不存在此类Bug的。

  总结 
  上述对问题的解释其实有点牵强，因为大多数时候发送和接收都是这样进行处理的，但是都没有出现问题，而且DMA的使用也使用了很长时间也没有出现过问题，并且就算出问题也是随机的，并不是每次都出问题，所以怀疑出现问题应该是跟各个中断之间的优先级、响应时间、以及具体的时序有一些复杂的关系，具体是什么关系就很难寻找了，推荐的做法就是防范于未然，将不用的中断统统关闭，这样总是没有坏处的。