Periodic Reset – Interrupt Problem ?

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*/        }

Periodic Reset – Interrupt Problem ?

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.

Periodic Reset – Interrupt Problem ?

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

Periodic Reset – Interrupt Problem ?

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

Periodic Reset – Interrupt Problem ?

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