FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [September 2008 Threads] Problems Resuming a Task from an ISR Posted by Eric Burkhart on September 6, 2008 I'm currently using FreeRTOS on Atmel's AVR32 UC3 Serieas and am trying to resume a task from an ISR. Here is my ISR:
Code: __attribute__ ((naked)) static void dataready_int_handler(void) { portENTER_SWITCHING_ISR() portBASE_TYPE xYieldRequired = pdFALSE;
portENTER_CRITICAL() //Tell the processing task to start xYieldRequired = xTaskResumeFromISR( xQuantumHandle ); portEXIT_CRITICAL() gpio_clear_pin_interrupt_flag(DATA_READY_PIN);
portEXIT_SWITCHING_ISR() }
This code gets to the switch context once, and then on every subsequent call of xTaskResumeFromISR, it says no context switch is necessary because prvIsTaskSuspended says xQuantumHandle is not suspended (but I'm quite sure it's not running, and there is always one item in the xSuspendedTaskList).
The suspicious code is in prvIsTaskSuspended:
Code: /* Is the task we are attempting to resume actually in the suspended list? */ if( listIS_CONTAINED_WITHIN( &xSuspendedTaskList, &( pxTCB->xGenericListItem ) ) != pdFALSE ) { /* Has the task already been resumed from within an ISR? */ if( listIS_CONTAINED_WITHIN( &xPendingReadyList, &( pxTCB->xEventListItem ) ) != pdTRUE )
It gets past the first check that the task is in the suspended list, but after this pxTCB changes to 0x00. Any thoughts on what might cause this or something I could be doing wrong?
Thanks!
RE: Problems Resuming a Task from an ISR Posted by Dave on September 6, 2008 First thing is, is it valid to call ENTER_CRITICAL() EXIT_CRITICAL() in an interrupt on an AVR32. I don't know anything about the port so maybe it is but this would not be normal for most port.
Second, if you are using the task suspension mechanism to control an event handler task by unsuspending the task in the interrupt then having the task suspend itself, I would recommend switching to use a semaphore instead. The task suspension mechanism will not work because interrupt occurring before the task has suspended itself will simply be lost because the interrupt is trying to unsuspend a task that is not yet suspended. When the task next suspends itself it will not be unsuspended until the following interrupt.
From the documentation http://www.freertos.org/taskresumefromisr.html "vTaskResumeFromISR() should not be used to synchronise a task with an interrupt if there is a chance that the interrupt could arrive prior to the task being suspended - as this can lead to interrupts being missed. Use of a semaphore as a synchronisation mechanism would avoid this eventuality."
Look at the example on this page instead http://www.freertos.org/a00124.html. You might even want to use a counting semaphore depending on the characteristics of you application.
RE: Problems Resuming a Task from an ISR Posted by Eric Burkhart on September 8, 2008 You're right, I don't know that it is valid to call ENTER_CRITICAL() EXIT_CRITICAL() in an interrupt, but on second thought other interrupts are automatically masked anyways in an ISR here.
I was thinking about using a semaphore, but I was concerned that it would be much slower. This application has a periodic interrupt to tell it to read data from another chip. The window to read data is very small (and missing a read occasionally is tolerable) so I thought this may be a bit faster. Other than missing some interrupts, is there any fundamental reason that this mechanism doesn't work?
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|