痞子衡嵌入式：探析i.MXRT1050在GPIO上增加RC延時電路後導致邊沿中斷誤觸發問題(上篇)

痞子衡發表於2024-08-11

　　大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家分享的是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 上的方波是由外部訊號發生器提供的）：

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，並且隨著時間累積，差距會越來越大。這說明邊沿中斷誤觸發現象是一直存在的。

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 電平用作標記。

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 是如何產生的！

　　至此，i.MXRT1050在GPIO上增加RC延時電路後導致邊沿中斷誤觸發問題探析（上篇）痞子衡便介紹完畢了，掌聲在哪裡~~~

歡迎訂閱

文章會同時釋出到我的 部落格園主頁、CSDN主頁、知乎主頁、微信公眾號 平臺上。

微信搜尋"痞子衡嵌入式"或者掃描下面二維碼，就可以在手機上第一時間看了哦。

相關文章