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