Hi,

I'm using FreeRTOS on an ATmega128 AVR. I have a problematic IRQ routine. Since this routine may cause a task switch, I've put an ASM wrapper around it like this:

SIG_TIMER1_CAPT_Entry:
portSAVE_CONTEXT
call SIG_TIMER1_CAPT
tst r16
breq _no_context_switch
call vTaskSwitchContext
_no_context_switch:
portRESTORE_CONTEXT
reti

In case of a task switch, it does not return with the I flag set, so IRQs remain disabled (in spite of the RETI at the end), neither my timer capture IRQ nor the scheduler IRQ will be triggered anymore.
Anyway, if I modify the code just like it is in the preemptive scheduler call:

SIG_TIMER1_CAPT_Entry:
rcall SIG_TIMER1_CAPT_Proc
reti

SIG_TIMER1_CAPT_Proc:
portSAVE_CONTEXT
call SIG_TIMER1_CAPT
tst r16
breq _no_context_switch
call vTaskSwitchContext
_no_context_switch:
portRESTORE_CONTEXT
ret

It works absolutely fine when calling it via a second stage.
Can you tell me what the problem is here, why it is not working when there's no extra call?

Thanks and best regards,
Geza Balazs

I've just taken a quick look at the FreeRTOS WEB pages for the AVR and the source code for the AVR demo and cannot see that either the IAR or GCC ports use assembly wrappers for interrupts. Which compiler are you using? Is there a reason why you cannot write your interrupts as per the serial port example in the demo?

The AVR demos are some of the original demos, so maybe the compiler requires something different now?

Also there was a long explanation of the interrupt flag status during a context switch for the AVR ports on this forum a few months back, you might like to try searching for that.

Dave,

I'm using IAR EWAVR 4.20A. The reason why I'm using an ASM wrapper is that the main IRQ handler may cause a task switch and since this timer capture IRQ needs to be as fast as possible, and the context switch would save and restore all context data anyway, I'd like to get rid of saving and restoring context data at the beginning and the end of the service routine. The main handler function is written in C, with the __task directive. It returns the need of the context switch in R16, and the wrapper handles the request appropriately.

Regarding the IF status I'm gonna look it up right away.

Thanks,
Geza

I don't know if this is the problem, but one thing to remember is that vTaskSwitchContext assumes that all paths after it are identical, and may not actually return to your function until the task that was interrupted gets started again.(I think this may depend on the port).