Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


vEMAC Semaphore

Posted by Nobody/Anonymous on August 16, 2006
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.

RE: vEMAC Semaphore

Posted by Richard on August 16, 2006
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.


RE: vEMAC Semaphore

Posted by Nobody/Anonymous on August 16, 2006
With you, it blocks itself - d'oh moment.

which explains why my interrupt based driver for my external ethernet chip doesn't work....


RE: vEMAC Semaphore

Posted by Nobody/Anonymous on August 17, 2006
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.

RE: vEMAC Semaphore

Posted by Nobody/Anonymous on August 17, 2006
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?

RE: vEMAC Semaphore

Posted by Nobody/Anonymous on August 17, 2006
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....

[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

Version 10.1.0 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers


STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner