Race condition with palWaitPadTimeout

[avrhack]

I'm processing "interrupts" from an external SPI Ethernet MAC/PHY using the PAL events subsystem on the main thread, but after a while things stop. I'm 99% sure the issue is with a race condition which I can't see how to correct, but can't believe Giovanni hasn't got covered as otherwise the PAL events subsystem would be pretty worthless in real life.

Code outline is:

Code: Select all

palEnablePadEvent(GPIOA, GPIOA_PAD, PAL_EVENT_MODE_FALLING_EDGE);
while (1)
{
   palWaitPadTimeout(GPIOA, GPIOA_PAD, TIME_INFINITE);
   if (!palReadPad(GPIOA, GPIOA_PAD))
      ProcessInterrupt();
}


After a few hundred interrupts this gets stuck in the palWaitPadTimeout with the interrupt line asserted ie low. The issue I'm sure is that when interrupts are processed in ProcessInterrupt() and are then enabled again, an interrupt occurs BEFORE the code loops around to the palWaitPadTimeout which then waits for the NEXT interrupt as it's edge triggered.

One solution, which I've always used in the past with 'real' interrupt handlers is that these should be level triggered rather than edge triggered, but I can't see that option in the PAL handler (this is on an STM32L4xx to be clear).

Surely there must be some way to ensure that if this race occurs, the palWaitPadTimeout call will still return?

If not, then palWaitPadTimeout is pretty worthless in real life use......

[Giovanni]

Hi,

This is probably more an EXTI limitation, the pad state can change before you read it after the falling edge, the race condition probably is there. You should not rely on reading a pad after getting an event, you could assume it is low after a falling edge.

Another potential issue is: if the signal is fast enough the driver continues processing events continuously.

Giovanni