STM32F4+UCOSII program runs for a while and the operating system dies and the interrupt responds normally

Problem Description

The control system uses the STM32F4+UCOSII preemptive kernel. Recently, there has been a problem that the operating system dies directly after the program has run for a period of time. The manifestation is: a breathing light task with a very low priority is set in the operating system. As long as the operating system is working normally, the breathing light will keep jumping, but when a problem occurs, the breathing light stops beating, the task controlling the movement of the chassis also dies, the chassis is out of control, and the task where the LCD is located also dies and no longer refreshes. It is speculated that all the tasks of the operating system are dead and cannot work normally, but the interrupt can still be responded to, and the emergency stop operation written in the timer interrupt can be executed.

problem analysis

• Suspected to have entered some error interrupt

• I suspect there is a problem with the pointer or stack.

• Suspect that there is an infinite loop in the highest priority task

• Suspect there are some bugs in the operating system

• It is suspected that the program is always interrupted due to the interruption and cannot enter the normal task 
  solution

• Check and analyze the error interrupt. The only error interrupt response enabled in the program is HardFault. After entering the HardFault interrupt service function, corresponding processing will be performed 
  . /* *

• @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); 
  } 
  }` 
  Therefore, judging from the performance, the possibility of entering Hard Fault can be basically ruled out. In addition, the interrupt priority of Hard Fault is -1. If the program dies in Hard Fault, then other interrupt responses should also be unresponsive. This is inconsistent with the performance of the problem, and the interrupt can still be responded to. Therefore, it can be concluded that it is not entering Hard Fault or some other problem interrupts.

• Regarding pointer and stack issues, generally, if there is a problem, it will go directly to Hard Fault. At this point, the Hard Fault problem has basically been ruled out. In addition, we have also tried to expand the stack of the hardware and operating system, but the problem was not solved. It is certain that the problem is not here.

• 
  

• I have checked a lot about operating system bugs on the Internet. Early operating systems did have problems, but the 2.92 version used in the system should not have such bugs.

  To sum up, 
  the above explanation of the problem is a bit far-fetched, because most of the time sending and receiving are processed in this way, but there are no problems, and DMA has been used for a long time without any problems, and even if there are problems, they are random, not every time. Therefore, it is suspected that the problem should be related to the priority, response time, and specific timing of each interrupt. There is some complex relationship. It is difficult to find the specific relationship. The recommended approach is to prevent it before it happens and turn off all unused interrupts. This will never do any harm.