STM32F4 程序运行一段时间后死掉 但中断正常响应(串口一直进中断导致程序被卡死)

本文详细描述了一个STM32F4控制系统在运行过程中出现程序死锁的问题,尽管中断仍能响应。经过分析,问题根源在于串口接收中断(USART)触发的上溢错误(ORE)未被正确处理,导致中断循环触发,系统任务无法继续执行。解决方案是确保在中断服务函数中正确清除ORE标志位。
摘要由CSDN通过智能技术生成

问题描述

控制系统使用的是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的问题,除此之外也尝试扩大了硬件和操作系统的堆栈,问题没有解决,确定不是这里有问题。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值