I believe there is a bug in the avr23_uc3 gcc port. I am running on AT32UC3A0512 (evk1100).

The following is the exception handler for the "scall" instruction which is issued to perform a context switch:

__attribute__((__naked__)) void SCALLYield( void );
__attribute__((__naked__)) void SCALLYield( void )
{
/* Save the context of the interrupted task. */
portSAVE_CONTEXT_SCALL();
vTaskSwitchContext();
portRESTORE_CONTEXT_SCALL();
}

The problem, I believe, is that the AVR "scall" instruction/exception does not automatically disable interrupts as other exceptions/interrupts do. This means that interrupts are enabled during this critical context switch code. A poorly timed interrupt can potentially mess up FreeRTOS internal data structures. I fixed it as follows, and my problem went away:

__attribute__((__naked__)) void SCALLYield( void );
__attribute__((__naked__)) void SCALLYield( void )
{
/* Save the context of the interrupted task. */
vPortEnterCritical();
portSAVE_CONTEXT_SCALL();
vTaskSwitchContext();
portRESTORE_CONTEXT_SCALL();
vPortExitCritical();
}

Can someone please verify that this is correct?

Thanks!

-Mike

A few comments:

1:
Note that, as mentioned on the FreeRTOS website, the UC3 port in the FreeRTOS download targets the older first issue UC3 chips. If you are using production chips now you can get the code from Atmel which is in their ASF package (http://asf.atmel.com).

2:
Calling the enter critical function (as in your code snippet above) will change the MCU context *before* you have saved the context, which in nearly all cases is going to cause issues.

3:
Having looked at the code I'm note sure there is an issue because the portSAVE_CONTEXT_SCALL(); itself enters a critical section (but after the context has been saved).

Regards.

Hi Richard, thanks you for your reply... I am much obliged!

1. Just FYI, I downloaded the latest ASF package before posting here. (I figured this might be the best place to get an answer and it looks like I was right. ;-)

2. I'm not sure what you mean about enter critical function changing the MCU context. All it does is disable interrupts and increment the nesting count

3. I had not noticed the enter critical section in portSAVE_CONTEXT_SCALL(), so I was wrong in my assessment. Thank you for pointing that out!

There is still a mystery, however:

It so happens that I had an interrupt that wasn't being cleared properly and was interrupting almost constantly. The result, was an overflow of the idle task stack. The bigger I made the stack, the longer it would run, but it would always eventually overflow.

My *fix*, however misguided, did resolve the stack overflow problem. I have been running without issue for more than a week now.

Fixing the interrupt issue hides the stack problem, but I believe it still exists. It is rare for an interrupt to occur at precisely the right time but it seems, based on my experience, that it must still be possible. I have not been able to discover why, however, and I wonder if you might have any insight.

Thank you so much for your time and attention!

-Mike