Race condition with palWaitPadTimeout

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome. This forum is NOT for support.
Posts: 127
Joined: Tue Dec 24, 2013 1:42 pm
Has thanked: 10 times
Been thanked: 2 times

Race condition with palWaitPadTimeout

Postby avrhack » Sun May 19, 2019 4:47 pm

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

while (1)
   if (!palReadPad(GPIOA, GPIOA_PAD))

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

User avatar
Site Admin
Posts: 13074
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 758 times
Been thanked: 637 times

Re: Race condition with palWaitPadTimeout

Postby Giovanni » Sun May 19, 2019 5:49 pm


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.


Return to “Development and Feedback”

Who is online

Users browsing this forum: No registered users and 5 guests