[PSR] IRC_SR register values in interrupts

beranj25 at fel.cvut.cz beranj25 at fel.cvut.cz
Tue Jan 16 11:24:46 CET 2018


Cituji Pavel Pisa <pisa at cmp.felk.cvut.cz>:

> 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
>

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






More information about the PSR mailing list