Hi everybody,

Well, i have a problem with FreeRTOS 5.0.0 running on a ARM9 STR912, compilation GCC Yagarto /Eclipse (GCC Port provided by Richard, thanks to him).

After a long time of running (could be 3-4-6 hours), my processor reset by itself.
I m (fairly) sure it's not a problem of stack overflow because i'm monitoring periodically the free memory available via the "water level" (0xa5 in the stack) and i m always with at least 300 bytes free for each task running (5 in fact).


Inside my application, I m using the timer 0 to tick FreeRTOS (1KHz) and i m using also the RTC interrupt.

In my RTC interrupt event, I m NOT using following function, Is it right ?

portSAVE_CONTEXT, portRESTORE_CONTEXT
(save /restore context is done directly in the assemblary file just before / after branch the interrupt)
taskENABLE_INTERRUPTS, taskDISABLE_INTERRUPTS
taskENTER_CRITICAL, taskEXIT_CRITICAL


Note : Nothing is defined with the keyword __naked__.


Thanks in advance.





My interrupt :

void RTC_IRQHandler(void)
{
portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE;

/* Not necessary to save context-> done in assemblary file*/

/* disable interrupt */
RTC_PeriodicIntConfig(RTC_Per_DISABLE);
RTC_ClearFlag(RTC_FLAG_Per);

/* "Unblock" the task of analog measurement */
xSemaphoreGiveFromISR( xSemaphoreAnalogMeasurement, &xHigherPriorityTaskWoken );

/*new interrupt*/
RTC_PeriodicIntConfig(PULS_ANALOG_RTC_PERIDOCITY_MEASUREMENT);

/* Not necessary to restore context -> done in assemblary file*/
/* Not necessary to write in VIC, done in assemblary*/

}

I suspect the saving and restoring of the context will be done within a single IRQ interrupt entry point, before calling the individual handler. This is how the IAR version works. Hence the handler itself is just a standard C function without the naked attribute.

Regards.

Thanks for your reply Richard.

Yes, you are true, the GCC Port is the same construction than the IAR port.


BUT Yesterday i disabled my RTC interrupt (for polling FreeRTOS kernel tick), and my software is able to run without crash during a full day.

I except I have a problem when my RTC Interrupt fire and the RTOS is already in the TIM0 interrupt (this timer is used by RTOS to generate kernel tick). Or the opposite : TIM0 fire when i m in the RTC interrupt.


Any idea is welcome !


Damien

Hi Damien,

The interrupt management on the STR912 is a little bit tricky. I advice you to have a look at an application note on the stmcu website which is " STR912 interrupt management".

The implementation of the interrupt controller on the STR9 is very particular: it is based on 2 daisy chained ARM VICs and you have interrupts which are mapped to VIC0 and other to VIC1 with VIC0 interrupts having higher priority.

I don't like to enter too much in details ( you can have a look at the AN), but I think what you are seeing is the result of a bad interrupt management.

Regards,
Anis

Hi Anis, and others


Thanks for your repplies,

I found the problem : Anis was half right, this is a problem of interrupt but not in my RTC interrupt or Timer interrupt but with SPURIOUS interrupt.
Answer is given in the document: (thanks Anis)
http://www.st.com/stonline/products/literature/an/13715.pdf, page 11.

Because I hadn't assigned a new default vector in the VIC0-1, during a spurious interrupt my software was branching to 0x00000000 means reset vector.

Just by adding following lines: everything seems fixed.

VIC0->DVAR = (u32)Dummy_Handler;
VIC1->DVAR = (u32)Dummy_Handler;

Thanks all.

Damien