[PSR] IRC_SR register values in interrupts

[Pavel Pisa]

Dear students,

On Tuesday 16 of January 2018 09:38:44 beranj25 at 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

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.

Best wishes,

Pavel Pisa