STM32程序异常——中断处理要谨慎

问题背景

最近有一个新项目（车载项目），板子上除了原来的ARM + STM32F030K6Tx又多了一个8bit的mcu的单片机，这可真是嵌入式全家福了。

系统的主要核心工作是由arm来完成，但是在开机早期及休眠、唤醒等过程是由stm32来控制完成的。

开机过程中的ACC打火检测、高低压检测，同时也是为了保证休眠的时候整块板子的的低功耗（休眠时只有rtc有电及stm32处于深度休眠，其他全部掉电）。

最近添加了一颗tw8836mcu，主要是为了快速开机出预览，因为我的linux系统开机起来出摄像头预览需要11s左右，客户需求开机2s内出预览画面，

这种速度只能依赖屏驱芯片（或者更换成rtos）来实现，所以我们又多了一颗屏驱芯片，其作用就是在上电开机的时候快速输出摄像头预览，等arm开机起来之后接受来自arm的lvds信号切换显示arm输出的内容。

考虑到开发费用，没有采用由芯片厂来完成tw8836的程序开发的合作方式，有考虑到开发时间问题，也没有自己去重新学习这块mcu的编程，而是通过iic方式刷参数实现。

开机第一阶段

stm32通过iic给tw8836刷参数，显示摄像头数据，然后交出tw8836的控制权

开机第二阶段

arm启动完成，由arm通过iic给TW8836刷参数，显示arm输出的lvds信号。

在我开始写stm32代码之前，公司有一份成熟的代码实现的是开机、休眠、唤醒、升级等功能，这部分代码已经有人一直在维护。

我需要完成的是加上tw8836这部分功能，以及lcd的控制逻辑。

代码模块有以下：

1、iic通讯，由于所接的两个io口不是硬件iic，所以需要写一个模拟iic通讯。

2、部分io口控制功能。

3、pwm控制lcd背光亮度。

4、光感模块的adc值检测。

为了避免新功能与旧逻辑的干扰，我这边没有在他们的代码基础上去修改，而是重头写了一份全新的，待我验证ok后再交给另外一个维护的同事合并验证。

————————————————————————————————————————————————————————————————————

上周五把验证ok的代码交给同事合并验证，搞了一天说跑不了，用在线调试，经常停在某处不返回，没办法这周叫他吧整个工程代码撸过来瞧一瞧。

经过调试验证确实后莫名死在某处不出来，不知道是掉坑里了还是逛窑子去了。

有以下几个地方会无返回，也有可能还会有其他地方。

RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOB, ENABLE);

/*
 * 函数名：Delay_5us
 * 描述: 5us延时函数 单位为5us
 * 输入： nTime
 * 输出：无
 * 调用： Delay_5us(1)实现的延时为5us
 *       外部调用
 */
void Delay_5us(__IO uint32_t nTime)  {
    TimingDelay = nTime;    
    while(TimingDelay != 0);
}

/*
 * 函数名：TimingDelay_Decrement
 * 描述：获取节拍程序
 * 输入：无
 * 输出：无
 * 调用：在SysTick  中断函数SysTick_Handler()调用
 */  
void TimingDelay_Decrement(void)
{
    if (TimingDelay != 0x00)
    { 
       TimingDelay--;
    }
}

这些诡异的不返回和滴答定时器的初始化使能有关。

/*
 * 函数名：SysTick_Init
 * 描述：配置并启动系统滴答定时器SysTick
 * 输入：无
 * 输出：无
 * 调用：外部调用
 */
void sys_tick_init(void)
{
        RCC_ClocksTypeDef RCC_Clocks;
    RCC_GetClocksFreq(&RCC_Clocks);
    /* SystemFrequency / 1000    1msÖÐ¶ÏÒ»´Î
     * SystemFrequency / 100000     10usÖÐ¶ÏÒ»´Î
     * SystemFrequency / 1000000 1usÖÐ¶ÏÒ»´Î
     */
    if (SysTick_Config(/*SystemCoreClock*/RCC_Clocks.HCLK_Frequency / 200000))    // ST3.5.0¿â°æ±¾,5us/tick
    { 
        /* Capture error */ 
        while (1);
    }
}

我的代码系统时钟是采用pll倍频道72M的，滴答定时器原始的中断函数如下：

/**
  * @brief  This function handles SysTick Handler.
  * @param  None
  * @retval None
  */
void SysTick_Handler(void)
{
      TimingDelay_Decrement(); 
}

旧代码系统时钟没有配置，采用默认的48M，合并代码后采用了我这边的时钟配置，提高到72M。

旧代码systick中断是设置的1ms一次，合并后采用5us的中断（因为模拟iic需要用的us级别的精准延时函数），

最终合并了旧程序的逻辑后中断函数变成了如下，增加了一大堆用来做状态机的标志：

/**
  * @brief  This function handles SysTick Handler.
  * @param  None
  * @retval None
  */
void SysTick_Handler(void)
{
      TimingDelay_Decrement();
   
      sysTickCtrl++;
    
    /* 2MS LOOP */
    if(!(sysTickCtrl%COUNT_2MS_MAX))
    {
        F_SYS_2MS=1;
    }
    
     /* 4MS LOOP */
    if(!(sysTickCtrl%COUNT_4MS_MAX))
    {
        F_SYS_4MS=1;
    }
    /* 8MS LOOP */
    if(!(sysTickCtrl%COUNT_8MS_MAX))
    {
        F_SYS_8MS=1;
    }
    /* 12MS LOOP */
    if(!(sysTickCtrl%COUNT_12MS_MAX))
    {
        F_SYS_12MS=1;
    }
    /* 12MS LOOP */
    if(!(sysTickCtrl%COUNT_40MS_MAX))
    {
        F_SYS_40MS=1;
    }
    /* 100MS LOOP */
    if(!(sysTickCtrl%COUNT_100MS_MAX))
    {
          F_SYS_100MS+=1;
    }

}

于是上面所述的诡异问题就产生了。

经过进一步验证，如果在初始化systick的时候设置中断时间大于10us程序就可以正常运行。

void sys_tick_init(void)
{
        RCC_ClocksTypeDef RCC_Clocks;
    RCC_GetClocksFreq(&RCC_Clocks);
    /* SystemFrequency / 1000    1msÖÐ¶ÏÒ»´Î
     * SystemFrequency / 100000     10usÖÐ¶ÏÒ»´Î
     * SystemFrequency / 1000000 1usÖÐ¶ÏÒ»´Î
     */
    if (SysTick_Config(/*SystemCoreClock*/RCC_Clocks.HCLK_Frequency / 200000))    // ST3.5.0¿â°æ±¾,5us/tick
    { 
        /* Capture error */ 
        while (1);
    }
}

想来想去不应该是中断频率太高导致的，由此想到了linux系统内核中的中断处理函数的几点说明。

内核里面的中断处理函数：

1、不能做延时delay操作。

2、不能做耗时过长的操作。

3、最好不用打印（调用printf打印其实也是很费时间的操作）

4、不能用死循环等待。

所以在内核驱动里面一般都是采用中断上下午来处理，中断上文唤醒处理线程，下午都在线程里干活。

这条铁律同样适用于单片机，即时——中断处理函数一定不能做耗时较长的操作。

现在中断函数里面进行了一大堆的取模运算，这是耗时比较长（相对而言）的运算。据此提出以下猜想：

中断函数耗时太长，在中断频率又高的时情况下占据了大部分cpu资源。

验证

将中断后面部分的操作屏蔽，将中断时间调整到5us 1us都没问题。

/**
  * @brief  This function handles SysTick Handler.
  * @param  None
  * @retval None
  */
void SysTick_Handler(void)
{
      TimingDelay_Decrement();
   
      sysTickCtrl++;

    /*only for test */
return;

    /* 2MS LOOP */
    if(!(sysTickCtrl%COUNT_2MS_MAX))
    {
        F_SYS_2MS=1;
    }
.............
}

所以真音就是；中断函数耗时较长占据了大部分cpu。

解决方法：优化中断处理函数

——————————————————————————————

有关加减乘除运算耗时的说明：

了解汇编的人应该都知道加减乘除中的加减运算是比较快的，但是要实现乘除运算需要n多条指令才能实现，这是一种效率比较低下的操作，所以在可以的情况下尽量避免乘除运算，或者转换成效率较高的移位运算（<< >>）

例如

/*乘除预算装换移位运算
*、
num * 8   ==> num << 3
num / 8   ==> num >> 3

移位运算相对于乘除运算效率高的多得多。

2018年6月26

深圳南山科技工业园

posted @ 2018-06-26 16:12 mcdull^0^ 阅读(7283) 评论(0) 编辑收藏举报

刷新页面返回顶部

mcdull^0^

STM32程序异常——中断处理要谨慎

公告