I discovered the cause is multiple generated interrupts from GPIO module. This condition in the beginning of ISR fixes the issue: #define GPIO_INT_STAT_2 (*(volatile uint32_t *) (ZYNQ7K_GPIO_BASE + 0x00000298)) [...] if (!(GPIO_INT_STAT_2 & 0x4)) { /* Not interrupt from IRC */ return; } However, I still wonder where are these others interrupts come from. To be sure, I disabled interrupts from all GPIO banks in irc_init() function, but there are still many of them. Had anyone else problems with it? Besides, the irc_init() on the web [1] sets interrupt polarity on falling instead of rising edge according to Zynq TRM, 14.2.4 [2], but it shouldn't matter. The problematic line of code is this: *(volatile uint32_t *) (ZYNQ7K_GPIO_BASE + 0x000002a0) = 0x0; /* rising edge (polarity), should be set to 0x4 */ [1] http://rtime.felk.cvut.cz/psr/cviceni/semestralka/#irc-sensor-irq-handling [2] https://rtime.felk.cvut.cz/hw/index.php/Zynq Cituji beranj25@fel.cvut.cz:
In IRC interrupt routine I sometimes get values of IRC_A_MON and IRC_B_MON which are the same as in the interrupt that follows. So the status changes of IRC_{A,B}_MON are like this:
[...] 0 2 2 3 3 1 1 0 2 2 3 3 1 1 0 0 2 2 3 3 1 1 0 0 2 3 1 1 0 0 2 2 [...]
However, absolute position computed from such status changes seems to be correct. Spin in one direction for a given time then spin in the opposite direction at the same speed for the same time returns to roughly initial value. The difference from initial value is only about tens (one step in absolute position corresponds to one interrupt).
Besides, in some cases (tens of hundred thousands interrupts) I read zero from IRC_IRQ_MON, but interrupt source is setup to rising edge, so I'd expect '1' every time.
Have anyone encountered similar issue or do you have any explanation for this behavior?
Thanks
Jaroslav Beran
_______________________________________________ PSR mailing list PSR@rtime.felk.cvut.cz You can unsubscribe from the list at https://rtime.felk.cvut.cz/mailman/listinfo/psr