GPIO false interrupt when using multiple GPIO interrupt pins (IDFGH-14781)

[FrankBJensen]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Hi forum.

ESP32-S3 and espidf.

I have a problem, with false triggers. I use 2 inputs with both falling and rising interupts, to measure pulse withs. My pulses is around 150uS wide. The code is running smoothly, as long as only this code is running.

However. When I started to use a totally unrelated pin as output, to do some stuff, I get false interupts all of this pins. It happens randomly, and across both inputs.

I did a workaround with that pin, and no worries. I use a lot of other pins as IO, so for some reason this pin (GPIO44) was making the false triggers.

Now I have begun to use the builtin W5500 library, and I experience the exact same behaviour. Randon interupts, but ONLY when there is web traffic. If I keep the W5500 running, but with no traffic, it all works. W5500 is connected to GPIO 14(int), 21(SS), 45(MOSI), 47(SLK) and 48(MISO).

To me, it seems, that using some GPIOs, or maybe even just other kinds of interupt services, can influence interupts on other GPIOs.

Its NOT a glitch. Eg. I have a clean 150uS input, and in the middle of the high level, eg. 92uS in, I get an interupt, eventhough the input is clean, measured with my scope directly on the pin.

It only happens with seconds interval, but the more activity on other pins, the more often, but taken in CPU time, its rare.

It makes no difference, if I activate the built-in glitch filter or not.

I pass a number to identity the pin to the ISR, and the false triggers do identify as one of the wanted pins. So its no NULL, or another value, indicating another source. Except for the W5500, I do not use interupts on any other pins.

Can anyone help me, with what is going on???

Init:

gpio_config_t io_conf;
io_conf.intr_type = GPIO_INTR_DISABLE;
io_conf.mode = GPIO_MODE_OUTPUT;
io_conf.pin_bit_mask = ((1ULL << board.io_out.A0) | (1ULL << board.io_out.A1) | (1ULL << board.io_out.A2) | (1ULL << board.io_out.D0) | (1ULL << board.io_out.D1) | (1ULL << board.io_out.GATE) | (1ULL << board.io_out.CLR));
io_conf.pull_down_en = GPIO_PULLDOWN_DISABLE;
io_conf.pull_up_en = GPIO_PULLUP_DISABLE;
gpio_config(&io_conf);

    //    gpio_install_isr_service(0); is installed by W5500

    io_conf.intr_type = GPIO_INTR_ANYEDGE;
    io_conf.mode = GPIO_MODE_INPUT;
    io_conf.pull_up_en = GPIO_PULLUP_ENABLE;
    io_conf.pull_down_en = GPIO_PULLDOWN_DISABLE;

    for (int i = 0; i < NUM_INPUTS; i++) { // NUM_INPUTS

        io_conf.pin_bit_mask = (1ULL << input_pins[i]);
        gpio_config(&io_conf);
        gpio_isr_handler_add(input_pins[i], gpio_isr_handler, (void*)i);
    }

/////////////// INPUT ///////////////

    gpio_evt_queue = xQueueCreate(10, sizeof(INPUT));

    INPUT data;

    while (1) {

        if(xQueueReceive(gpio_evt_queue, &data, portMAX_DELAY)) {

            if (data.nModul < 8) GVs->IHC_input[data.nModul] = data.nData;

            printf("Module: %u - ", data.nModul);
            for (int i = 31; i >= 0; i--) {
                printf("%d", (data.nData >> i) & 1);
            }
            printf("\n");

        }

        vTaskDelay(pdMS_TO_TICKS(50));
    }

}

interupt:
The
if (high < 100) esp_rom_printf("io: %d, nBit: %u, time: %llu\n", pin_index, nBitCount[pin_index], high);
should never happen. My minimum pulsewidth is 150uS.
log:

io: 0, nBit: 16, time: 81
io: 0, nBit: 8, time: 47
io: 1, nBit: 7, time: 35
io: 0, nBit: 2, time: 54
io: 1, nBit: 1, time: 52

Interuptcode:

void IRAM_ATTR MyIHC::gpio_isr_handler(void* arg) {

    pin_index = (int)arg;
    curtime = esp_timer_get_time();

    if (gpio_get_level(input_pins[pin_index]) == 1) {   // rising edge

        nHigh[pin_index] = curtime;
    } else {                                            // falling edge

        high = curtime - nHigh[pin_index];

        if (high < 100) esp_rom_printf("io: %d, nBit: %u, time: %llu\n", pin_index, nBitCount[pin_index], high);

        if (high > 1000) { // all bits received

            if (nBitCount[pin_index] == 16 && nBits_cur[pin_index] != nBits_pre[pin_index]) {
                input.nModul = pin_index;
                input.nData = nBits_cur[pin_index];

                esp_rom_printf("Input %d, %u ", pin_index, nBits_cur[pin_index]);

                xQueueSendFromISR(gpio_evt_queue, &input, NULL);
                nBits_pre[pin_index] = nBits_cur[pin_index];
            }

            nBits_cur[pin_index] = 0;
            nBitCount[pin_index] = 0;
            nStart[pin_index] = true;
        }
        else
        {
            if (nStart[pin_index]) {

                if (nBitCount[pin_index] < 16) {
                    nBits_cur[pin_index] >>= 1;
                    if (high > 225) {               // 0
                    } else if (high > 100) {        // 1
                        nBits_cur[pin_index] |= 0b1000000000000000;
                    }
                    nBitCount[pin_index]++;
                }
                else if(nBitCount[pin_index] == 16)
                {
                    if (high > 225) {               // 0
                        parity[pin_index] = false;
                    } else if (high > 100) {        // 1
                        parity[pin_index] = true;
                    }
                    nBitCount[pin_index]++;
                }
                else {
                    nStart[pin_index] = false;
                    nBitCount[pin_index]++;
                }
            }
        }
    }
}

[songruo]

Hi @FrankBJensen, I guess the handling of GPIO interrupt got postponed by other peripherals' interrupt handling. Since you are using S3, which has two cores, you could register GPIO interrupt on the core other than the one used to handle interrupts for other modules. You may take this test case as a reference.

[FrankBJensen]

Hi Sungruo.

Thank you. I am still struggling with this issue. I will try out this. My problem is not that any interupts get postponed - I simply gets too many. I get false interupts on one GPIO when using another GPIO as output (interupts are disabled on that GPIO).

[songruo]

Say your GPIO interrupt is supposed to be triggered at timestamp 50us, 200us, 350us, 500us... If there is other interrupt processing at the timestamp 200us, and it finishes at 280us, then the GPIO interrupt which is supposed to be fired at 200us will get postponed to a timestamp > 280us. But if at the moment when the next GPIO interrupt which fires at 350us, there is no other interrupt affecting, then this one will get fired instantaneously at 350us. This will lead to an escaped time you calculated in the ISR be less than 150us for sure.

Do you think this is your case?

[FrankBJensen]

Not exactly. I have a GPIO set up to trigger at both rising and falling edge. I have pulses at 150uS low and 300uS low. And these pulses are always 300uS high. I measure the time between falling and rigsing edge, in order to determine the width of the pulse. This is working flawlessly. I even have this running on 8 inputs simultanious, out of sync, and it still works flawlessly. When I look at the data, the measurements are 150 and 300uS within a very few uS. So all is fine.

So in other words, this is working, No false triggers, no postponed interupts.

Then I take another GPIO, and use it as output, to do some totally unrelated stuff. When I begin using this GPIO, the pulsewidth on the other GPIOs suddenly are all over the place, but always shorter than expected = I get a false interupt.

I have measured the pulses with my scope, directly at the pin, and they dont change at all.

And one thing. I use a lot of other pins as output, (GPIO 1, 2, 3, 4, 5, 15, 40, 41, 42, 43, 44(problem)) even multiplexing some stuff at relative high frequency, no problem. This is specific when using GPIO44 as output. I have a feeling, that it could be cause RxD handles differently, even though I have reset the pin.

So my first workaround, was simply to avoid GPIO44. All working flawlessly.

Then I started using W5500.
GPIO 14(int), 21(SS), 45(MOSI), 47(SLK) and 48(MISO)
same problem again.... false triggers. Avoiding this pins are difficult, without new design of my hardware..... I can try and pinpoint, what pin, if that gives any clue.....

[songruo]

I use a lot of other pins as output, (GPIO 1, 2, 3, 4, 5, 15, 40, 41, 42, 43, 44(problem)) even multiplexing some stuff at relative high frequency, no problem. This is specific when using GPIO44 as output. I have a feeling, that it could be cause RxD handles differently, even though I have reset the pin.

May I know how exactly you are doing for multiplexing some stuff at relatively high frequency? Is this not related to any other peripheral drivers, but only with GPIO APIs? Can you try switching to (IO 14, 21, 45, 47, 48) to find the problematic pins?

BTW, are you on the master branch? If not, please try with the master branch.

[FrankBJensen]

I use some pins for a buzzer and I2C, but most of them to drive some 74HC259 adressable latches, to optain extra GPIOs. Fortunately I used the problematic GPIO44 for the reset of those chips, and I can do a reset by simply just writing to the latches instead. its 8 operations in stead of 1, but it works.

I will try to disable the W5500, and toggle the pins individually, to see, what pins are causing this. Maybe its only one of them.

I am on framework-espidf @ 3.50301.0 (5.3.1)

I will get back :-)