For the life of me, I’m looking at the code for the vEMAC lwIP demo and I cann see where the ISR gives the semaphore which wakes the processing task, but I cannot find where the semaphore is given back. Maybe my short-sightedness is getting worse, but I’ve even tried searching in the files in the directory and cannot find it. This leads me to believe that once the task is woken, it never goes back to sleep.

The lwIP task will block on the semaphore if there is nothing to do.  The ISR will ‘give’ the semaphore, causing the lwIP task to ‘take’ the semaphore as it is woken.  Now the semaphore is empty again. If the semaphore were being use to guard access to a device, the task would now access the device then give the semaphore back. However, in this case the semaphore is used for synchronisation only.  It never gives the semaphore back so the semaphore remains ’empty’.  When it tries to ‘take’ the semaphore it will again block.  When the ISR executes again, writing to the semaphore again causes the lwIP task to wake. Regards.

With you, it blocks itself – d’oh moment. which explains why my interrupt based driver for my external ethernet chip doesn’t work…. Thanks!

Is there an issue with portENTER_CRITICAL() and an FIQ interrupt? My interrupt code for the ethernet driver was jumping off to data abort when I accessed the web server.  The link register showed it was the FIQ interrupt that caused it, and that the address that caused it was inside this macro. I got my boss to tie the FIQ line to the IRQ0 line and changed over the interrupt source and it all works fine, no jumping off to data abort. Again, this is with the SAM7S256.  It’s all working fine from the IRQ0 interrupt but goes very pear shaped from the FIQ interrupt.

Check the definition of your port to see if enter/exit critical macros disable just the IRQ or both the IRQ and FIQ.  If you allow FIQ interrupts within critical sections then you must ensure the FIQ does not access any of the queue or scheduler structures that are being protected by the critical section. A quick solution would be to disable FIQ within a critical section also, but this may not be suitable for your application depending on the response you require for the FIQ interrupt. Some time back there was a user that used the FIQ for fast motor commutation, and the IRQ for anything used by the scheduler.  The critical section code then left the FIQ enabled. What is the FIQ being used for?

We were using the FIQ line because of a lack of other interrupt lines (2 woohoo!), but one of them I can live without, so on the next prototype the interrupt has been moved to a regular interrupt. Problem solved.  At least I know it’s intended behaviour….