I am working with an AVR32 AT32UC3A0512, where three GPIOs are connected to a hall sensor (it's a sensor with 6 states depending on the direction of a motor). When one of the 3 GPIOs change state, an IRQ is generated, I save the value of the 3 GPIOs as the "previous hall state", then the motor keep turning and the next time an IRQ is generated I can compare the new value of the 3 GPIOs to determine in which direction the motor is turning, among other things.
This "works" 99% of the time, however sometimes, I can see that the IRQ is triggered and the value of 3 GPIOs compared with the last state is such that it seems that one IRQ was missed (for instance current state is "3" and previous state is "1", and there should have been an IRQ for state "2"). For this reason, I suspect that something is keeping the interrupt handler busy and that one IRQ is missed.
I tried to debug this by setting a static boolean to true when entering the IRQ and setting to false when exiting the IRQ and checking if sometimes the IRQ is entered while the boolean is already true, but I found out later this is not a valid test, because as long as the IRQ handler (declared with compiler directive "interrupt" so it has special assembly at the end) is not exited, the interrupts are not re-enabled.
To give some context the IRQ is triggered with a frequency of 1kHz, the MCU is clocked at 48MHz, FreeRTOS is running on it, and the IRQ handler contains about a thousand assembly instructions with -O0, (the problem is much easier to reproduce when compiling with -O0, but it can be reproduced after several hours with -O3). There is no obvious other interrupt which would starve the system.
Is there some way just with software changes to detect such an IRQ starvation? If not I will debug this with some GPIOs and an oscilloscope.