痞子衡嵌入式：探析i.MXRT1050在GPIO上增加RC延时电路后导致边沿中断误触发问题(上篇)

痞子衡嵌入式 2024-08-12 08:15:00 阅读 66

大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家分享的是i.MXRT1050在GPIO上增加RC延时电路后导致边沿中断误触发问题探析。

前段时间有一个 RT1052 客户反馈了一个有趣的问题，他们设计得是一个带 LCD 屏交互的应用，应用以官方 SDK 里的 lvgl_demo_widgets_bm 例程为基础。当客户在这个例程基础上增加了 GPIO 输入边沿中断检测，并且硬件上给 GPIO 增加了 RC 延时电路后，发现边沿中断触发得不太准确，这是怎么回事？今天痞子衡带大家还原现场：

一、问题描述

客户做得硬件改动很简单，在 GPIO_AD_B1_04 引脚和 GPIO_AD_B1_10 引脚之间加了如下的 RC 延时电路。GPIO_AD_B1_04 上产生得是 500Hz 的方波（既可以是 GPIO 模块输出，也可以去掉 R290 后直接接信号发生器），这个方波经过 RC 电路之后输出给 GPIO_AD_B1_10，然后通过其输入边沿中断来检测电平变化，并且在每个边沿中断里都翻转一次 GPIO_AD_B1_11 电平。

代码改动也足够简单，只需要在 \SDK_2_15_000_EVKB-IMXRT1050\boards\evkbimxrt1050\lvgl_examples\lvgl_demo_widgets_bm 工程里添加 test_gpio_irq() 函数调用即可（这里假定 GPIO_AD_B1_04 上的方波是由外部信号发生器提供的）：

<code>void GPIO1_Combined_16_31_IRQHandler(void)

{

// 检测到 GPIO_AD_B1_10 边沿

if ((GPIO1->ISR & (1U << 26)) && (GPIO1->IMR & (1U << 26)))

{

GPIO_PortClearInterruptFlags(GPIO1, 1U << 26);

// 翻转 GPIO_AD_B1_11 电平

GPIO_PortToggle(GPIO1, 1 << 27);

__DSB();

}

void config_rc_in_gpio(void)

{

// 配置 GPIO_AD_B1_10 为边沿中断输入检测模式

gpio_pin_config_t in_config = { kGPIO_DigitalInput, 1, kGPIO_NoIntmode };

IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B1_10_GPIO1_IO26, 1);

IOMUXC_SetPinConfig(IOMUXC_GPIO_AD_B1_10_GPIO1_IO26, 0x011030U);

GPIO_PinInit(GPIO1, 26, &in_config);

GPIO_SetPinInterruptConfig(GPIO1, 26, kGPIO_IntRisingOrFallingEdge);

EnableIRQ(GPIO1_Combined_16_31_IRQn);

GPIO_PortEnableInterrupts(GPIO1, 1U << 26);

}

void config_user_out_gpio(void)

{

// 配置 GPIO_AD_B1_11 为普通输出模式

gpio_pin_config_t out_config = { kGPIO_DigitalOutput, 1, kGPIO_NoIntmode };

IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B1_11_GPIO1_IO27, 0);

GPIO_PinInit(GPIO1, 27, &out_config);

GPIO_PinWrite(GPIO1, 27, 0U);

}

void test_gpio_irq(void)

{

config_rc_in_gpio();

config_user_out_gpio();

}

如果 GPIO_AD_B1_10 边沿中断检测无误，那么输出的 GPIO_AD_B1_11 信号应该是和原始输入 GPIO_AD_B1_04 完全同频的方波，而事实上客户用示波器抓到的 GPIO_AD_B1_11 信号偶尔会出现如下情况，很显然有边沿中断误触发的情况发生：

并且更有趣的是，这样的测试仅在 lvgl_demo_widgets_bm 工程里能复现，而在普通 input_interrupt 工程下没有任何问题。

Note1：在 lvgl_demo_widgets_bm 工程下出现的 GPIO 边沿中断误触发问题仅在增加 RC 电路时存在。

Note2：在普通 input_interrupt 工程下即使增加 RC 电路，GPIO 边沿中断误触发问题也不存在。

二、问题复现

理论上分析 GPIO_AD_B1_10 引脚输入的信号频率是 500Hz，那么其边沿中断应该是每 1ms 产生一次，而从上一节客户抓取的 GPIO_AD_B1_11 实际信号反推，似乎有时候边沿中断在 10us 内连续产生了两次。

为了从软件角度抓到这个中断误触发现象，痞子衡稍微改了一下代码，将 GPIO_AD_B1_04 上信号改为软件输出（在 SysTick 1ms 一次的中断响应里翻转电平），并且用了两个计数器 s_outputPinEdgeCount、s_inputRcPinIrqCount 来分别记录 GPIO_AD_B1_04、GPIO_AD_B1_10 边沿次数。如果边沿中断触发无误的话，这两个计数器的值应该是永远相等的，但是实际跑了一段时间后发现 s_inputRcPinIrqCount 会超过 s_outputPinEdgeCount，并且随着时间累积，差距会越来越大。这说明边沿中断误触发现象是一直存在的。

<code>volatile uint32_t s_inputRcPinIrqCount = 0;

volatile uint32_t s_outputPinEdgeCount = 0;

void GPIO1_Combined_16_31_IRQHandler(void)

{

// 检测到 GPIO_AD_B1_10 边沿

if ((GPIO1->ISR & (1U << 26)) && (GPIO1->IMR & (1U << 26)))

{

GPIO_PortClearInterruptFlags(GPIO1, 1U << 26);

// 计数 GPIO_AD_B1_10 边沿

s_inputRcPinIrqCount++;

__DSB();

}

void config_rc_out_gpio(void)

{

// 配置 GPIO_AD_B1_04 为普通输出模式

IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B1_04_GPIO1_IO20, 0);

GPIO_PinInit(GPIO1, 20, &out_config);

GPIO_PinWrite(GPIO1, 20, 0U);

}

void test_gpio_irq(void)

{

config_rc_in_gpio();

config_rc_out_gpio();

}

void SysTick_Handler(void)

{

// 计数 GPIO_AD_B1_04 边沿

s_outputPinEdgeCount++;

GPIO_PortToggle(GPIO1, 1 << 20);

__DSB();

// 原应用代码省略

}

三、问题定位

描述至此，你的第一反应到底是哪里出了问题？痞子衡想你可能会觉得罪魁祸首是 RC 延时电路，它将标准的方波上升、下降过程变得平缓，导致信号电压处于临界区的时间变长（极端情况下，对于高频信号，可能会导致其一直处于临界区），这个可能会影响 GPIO 电平跳变判定。既如此，我们先翻看一下 RT1050 的 datasheet，找到如下 GPIO DC 参数表，其高、低电平判定值分别是 70%、30% NVCC_XXXX，此外备注里说明了只要电平变化是单调的（随着时间单向增大或减小），且转换时间范围在 0.1ns - 1s 内均会被认定为有效跳变。

这时候我们再根据 RC 延时电路标准时间常数公式 t = RC * $\ln (\frac{(V1-V0)}{V1-Vt})$ 来推算（V1 电源电压、V0 电容初始时刻电压、$V_t$ 为 t 时刻电容电压）。如果 NVCC 为 3.3V，那么上升沿时从 0V 充电到 2.31V 的时间是 12us，显然这个 12us 充电时间对于 500Hz 的方波来说不足以影响其跳变判定。

有没有方法能抓住这个异常边沿中断发生时，GPIO_AD_B1_10 信号当时的波形状态呢？当然是可以的，我们可以再修改一下边沿中断处理函数代码，在里面计算两次中断之间的 Tick 间隔，如果间隔 Tick 低于一定值，说明是误触发，此时翻转一次 GPIO_AD_B1_11 电平用作标记。

<code>volatile uint32_t s_systickCurVal = 0;

volatile uint32_t s_systickLastVal = 0;

volatile uint32_t s_systickCurCount = 0;

volatile uint32_t s_systickLastCount = 0;

volatile uint32_t s_systickDeltaVal;

uint32_t s_systickReloadVal = 0;

void GPIO1_Combined_16_31_IRQHandler(void)

{

/* clear the interrupt status */

if ((GPIO1->ISR & (1U << 26)) && (GPIO1->IMR & (1U << 26)))

{

s_systickCurVal = SysTick->VAL;

s_systickCurCount = s_outputPinEdgeCount;

GPIO_PortClearInterruptFlags(GPIO1, 1U << 26);

// 计算两次中断之间的 Tick 间隔

s_systickDeltaVal = (s_outputPinEdgeCount - s_systickLastCount) * s_systickReloadVal + s_systickLastVal - s_systickCurVal;

s_systickLastVal = s_systickCurVal;

s_systickLastCount = s_systickCurCount;

// 当间隔 Tick 低于一定值时，说明是误触发，此时翻转一次 GPIO_AD_B1_11 电平

if (s_systickDeltaVal <= s_systickReloadVal / 2)

{

GPIO_PortToggle(GPIO1, 1 << 27);

}

__DSB();

}

int main(void)

{

// 应用代码省略...

test_gpio_irq();

s_systickReloadVal = SystemCoreClock / (LVGL_TICK_MS * 1000U);

s_inputRcPinIrqCount = 0;

s_systickLastVal = s_systickReloadVal;

DEMO_SetupTick();

// 应用代码省略...

}

如果用示波器以 GPIO_AD_B1_11 跳变为触发信号(ch2)，即能看到案发现场 GPIO_AD_B1_10 状态(ch1)，确实我们看到充放电时间内出现了短时脉冲波干扰（glitch），这个脉冲导致了电平变化不是单调的，因而产生了 GPIO 中断误触发。本篇仅是定位问题，下一篇我们会具体分析这个 glitch 是如何产生的！