Cituji Pavel Pisa <pisa@cmp.felk.cvut.cz>:
Dear students,
On Tuesday 16 of January 2018 09:38:44 beranj25@fel.cvut.cz wrote:
Multiple HW components are connected to interrupt #52 [1]. If you would like to enable only one GPIO to generate interrupt it should be sufficient to disable all by writing 0xffffffff to INT_DIS bank control in irc_init():
*(volatile uint32_t *) (ZYNQ7K_GPIO_BASE + 0x00000294) = 0xffffffff;
Maybe reset them too:
*(volatile uint32_t *) (ZYNQ7K_GPIO_BASE + 0x00000298) = 0xffffffff;
And then enable only the desired one:
*(volatile uint32_t *) (ZYNQ7K_GPIO_BASE + 0x00000290) = 0x4;
Yeah, that's exactly what I've done.
To be sure, I disabled interrupts from all GPIO banks in irc_init() function, but there are still many of them.
What you mean?
I mean that disabling and resetting interrupts (in this order) wasn't enough to prevent triggering other interrupts on IRQ #52 (GPIO's).
The interrupts from all four GPIO banks are ORed and passed to the GIC. You can disable interrupts from all banks by writting 0xffffffff to all four INT_DIS registers.
INT_DIS_0 0x00000214 INT_DIS_1 0x00000254 INT_DIS_2 0x00000294 INT_DIS_3 0x000002D4
It doesn't work.
But described behavior is strange anyway. Because your proposed solution is correct - respond only to your (IRC) interrupt and ignore all others
if (!(GPIO_INT_STAT_2 & 0x4)) { /* Not interrupt from IRC */ return; }
But the interrupts are level sensitive and if there is not processed and confirmed (write 1 to the corresponding INT_STATUS_x bit) interrupt from GPIO then the system should stuck, block in interrupt processing. At least one CPU core should be lost in infinite loop. If VxWorks uses both then another core can continue to work.
But if you you ignore interrupt and system still works that means that there is registered another handler on given interrupt which clears corresponding status or spurious interrupts are caused by some problem in central interrupts processing code in VxWorks. Anyway, this behavior is waisting of CPU time but if your solution works then I suggest to ignore it. It is not your problem. It is possible that some other GPIO pin is used for USB device or other functionality.
I see only SDcard detect signal SD_CD routed to PS_MIO46_501 as usesfull candidate for monitoring over GPIO interrupt. But it is strange that this signal would alternate and cause interrupts.
Values of GPIO status registers at the time interrupt occur are: STS0:0x00000000 STS1:0x00000000 STS2:0xffffff8f STS3:0x00000000 Even resetting all bits of GPIO_INT_STS_2 reg at the end of IRC interrupt handler doesn't prevent firing those other interrupt: // GPIO_INT_STS_2 = 0x4; // reset only IRC int GPIO_INT_STS_2 = ~0U; // reset all GPIO2 ints - even this doesn't work!
Best wishes,
Pavel Pisa