Periodic Reset - Interrupt Problem ?

damienhoyen wrote on Monday, July 07, 2008:

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

rtel wrote on Monday, July 07, 2008:

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.

damienhoyen wrote on Tuesday, July 08, 2008:

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

anisba wrote on Sunday, July 13, 2008:

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

damienhoyen wrote on Monday, July 14, 2008:

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