TCA8418: GPI level interrupt not triggering when enabled

Here's the illustration of capture, the second IRQ_FUSB (input to one of GPI) never triggers 8418's interrupt after reenable.

Feichen,

Can you elaborate on this statement? I am not sure I fully understand the problem. There is only 1 x /INT hardware interrupt pin. Is this being fed back into the TCA8418? 

Feichen Shen said:

One of the interrupt is active low input to GPI. It is possible this signal gets asserted (pulled low) before interrupt is enabled.

GPIO_INT_ENx registers enable the interrupt on GPI's only. The default value in this register is "0" meaning that interrupts are turned OFF for each GPI. A change on a GPI cannot trigger /INT LOW. 

Feichen Shen said:

We tried setting bit 4 (INT_CFG) in the config register(0x01) but there's no effect.

Setting bit 4 in the config register only adjusts the characteristics of pending interrupts. If there are multiple interrupts occurring at the same time, and bit 4 = 0, /INT will remain LOW until all interrupts have been serviced. If Bit 4 = 1, then /INT should de-assert for 50us before re-asserting again. 

Feichen Shen said:

I thought level interrupt should repeatedly trigger until interrupt deasserted.

It should repeatedly trigger if Bit 4 = 1 and multiple interrupts exist in the GPIO_INT_STATx registers. To clear the interrupts associated with pins configured with GPI's (not keypad), a read of GPIO_INT_STATx registers must occur. For example, if there is an interrupt triggered on registers 0x11, 0x12, and 0x13, and only 0x11 is read, then the interrupt on /INT should de-assert and re-asserted after 50 us if bit 4 = 1 in the config register (0x01). 

It is possible that the digital analyzer did not catch the 50us window. What is the sampling rate of the analyzer? 

Regards,

Tyler

Tyler Townsend said:

Can you elaborate on this statement? I am not sure I fully understand the problem. There is only 1 x /INT hardware interrupt pin. Is this being fed back into the TCA8418? 

No, the TCA8418 is used as interrupt expander. The interrupt signal from another IC is sent to one of the GPI pin of TCA8418. This interrupt is also active low.

Tyler Townsend said:

Setting bit 4 in the config register only adjusts the characteristics of pending interrupts. If there are multiple interrupts occurring at the same time, and bit 4 = 0, /INT will remain LOW until all interrupts have been serviced. If Bit 4 = 1, then /INT should de-assert for 50us before re-asserting again. 

OK, so this might not be what we want. The driver I created essentially reads all three GPI_INT_STAT 0x11~0x13 in one I2C read and process all nested interrupt before clears the INT_STS 0x02 and exit the ISR function. We are not using the keypad event function. Only for GPIO and GPI interrupt expander.

Tyler Townsend said:

It is possible that the digital analyzer did not catch the 50us window. What is the sampling rate of the analyzer? 

I'm sampling at 8MSPS on my logic analyzer and I2C (400kHz) is captured fine. So no issue on this.

My primary question is for a level interrupt how is it handled if it is asserted before this GPI interrupt line is enabled. Because the IC that generates this interrupt can assert before it's enabled. Usually this is OK for most SoC's internal GPIO interrupt controller. If signal is low and INT type is level-low, then it will trigger immediately when that GPI line interrupt is enabled/unmasked. But I do not see the same behavior on this TCA8418. If you look closely on my capture at the end, the IRQ_FUSB from that IC pulls low and the driver of that IC enables the level-low interrupt on TCA8418 through Linux's interrupt handling framework (marked in red box. Write 0x26 0 0 0 active low and 0x1A to enable the corresponding bits). But TCA8418 never triggers its INT afterward. So it became a edge sensitive instead of level-sensitive.

Thanks!

Feichen