• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 35 subscribers
  • Views 2053 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

No interrupts generate from timer

Pelle Windestam
Intellectual 620 points


I have just received a Stellaris LM4F232H5QD evaluation board and I'm trying to set up a simple timer interrupt. When debugging I can see that the timer is enabled and counting by monitoring the TIMER1A value register. I can also look at the NVIC registers and see that the interrupt is enabled. The problem is that my ISR never seems to be executed. I have copied startup_ccs.c from an example file in the StellarisWare project, and defined by ISR there. 

This is the code used to initialize the interrupts etc.

SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER0);
TimerConfigure(TIMER0_BASE, TIMER_CFG_PERIODIC);
TimerLoadSet(TIMER0_BASE, TIMER_A, SysCtlClockGet() / 50);
TimerIntEnable(TIMER0_BASE, TIMER_TIMA_TIMEOUT);
IntEnable(INT_TIMER0A);
TimerEnable(TIMER0_BASE, TIMER_A);
IntMasterEnable(); 

and from startup_ccs.c (my ISR is loop_20ms, and it is declared as external void loop_20ms() at the top of startup_css.c):

 

IntDefaultHandler,               // Watchdog timer
loop_20ms,                       // Timer 0 subtimer A
IntDefaultHandler,               // Timer 0 subtimer B

Am I missing something?

  • 0
    Intellectual 620 points

    I have done some more investigating and it seems like either I'm doing something wrong with the NVIC, or the vector table isn't getting properly set up. I added some code to poll the timer interrupt in the main loop,

     

    int_status = TimerIntStatus(TIMER0_BASE, TIMER_TIMA_TIMEOUT);
    if (int_status & TIMER_TIMA_TIMEOUT) {
        ++no_of_interrupts;
        TimerIntClear(TIMER0_BASE, TIMER_TIMA_TIMEOUT);
    }

    and the counter successfully increases at what appears to be a correct rate. Any suggestions what I can try? I have tried setting up an interrupt handler using TimerIntRegister(...) but that was unsuccessful.

     

  • 0 in reply to Pelle Windestam
    Guru 86765 points

    Pelle,

        Can you also post your loop_20ms timer interrupt handler code. Its also a good idea to check how the sample program on timers work, at your stellarisware.

    - kel

  • 0 in reply to Markel Robregado
    Prodigy 250 points

    From your tests it would appear that the timer device is configured correctly

    What compiler do you use?

    You can check the map file to control the interrupt table address.

    Read also the NVIC register VTOR content

    http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/BABEDCBC.html

    I forget..

    TimerIntRegister(...) assume you use a RAM vector table

    The first call to IntRegister automatically copy vevctor table to RAM but linker must know this and you must delcaler the VTABLE segment in ram area

     

  • 0
    Guru 47900 points

    Note that you "SysCtlPeripheralEnable(Timer0)" immediately before "TimerConfigure(Timer0)."  Such is not best practice - may not be causative but, "It takes five clock cycles after the write to enable a peripheral before the the peripheral is actually enabled."  (this - direct quote from Stellaris DRL_UG_8264)  Even though one can sometimes "get away" with spec non-compliance - over time, temperature, aging, model tweaks - you "press" your luck.  We've seen cases where such violations appear to work w/in debugger - yet fail often (perhaps always) when run in the final application.

     

     

     

  • 0 in reply to cb1
    Intellectual 620 points

    It seems like it was the lack of a delay after SysCtlPeripheralEnable(...) that caused my problems. I have now added delays after each enabled peripheral, and now it successfully jumps into my interrupt handler. Thank you for all your help!

     

  • 0 in reply to Pelle Windestam
    Expert 1360 points

    Hi , 

    I am having the similar issue ... 

    Actually I am starting the timer in between the GPIOPin Q1 interrupt routine.

    int timerdone = 0;

    void GPIOPIntHandler(void) // interrupt handler for GPIO event

    { 

    ROM_IntEnable(INT_TIMER2A);
    ROM_TimerIntEnable(TIMER2_BASE, TIMER_TIMA_TIMEOUT);
    ROM_TimerEnable(TIMER2_BASE, TIMER_A); // enable the timer in the routine

    while(timerdone == 0) {UARTprintf("waiting for timer interrupt");  ......}

    }

    the Timer interrupt doesnot execute in between the GPIOINT routine ..

    void Timer2IntHandler(void)

    {

    UARTprintf( "in timer routine \n";

    timerdone = 1;....

    }

    Please suggest.

    The GPIO Interrupt is not getting pre-empted. by the high priority timer interrupt.  I have given the following priorities ...

    ROM_IntPrioritySet(INT_GPIOP1,0x42); // low priority
    ROM_IntPrioritySet(INT_TIMER2A,0x00); // high priority

     

    is there anything i am missing out ?

     

    Thanks,

    Sanchit

  • 0 in reply to Sanchit Mehra
    Expert 1360 points

    Hi, 

    I just printed the following things:

    UARTprintf("\nPriority of Timer 2A is %d\n",ROM_IntPriorityGet(INT_TIMER2A));
    UARTprintf("\nPriority of GPIOQ1 is %d\n",ROM_IntPriorityGet(INT_GPIOQ1));
    UARTprintf("\npreemtable priority bits is %d \n",ROM_IntPriorityGroupingGet());
    UARTprintf("\n Priority Masking : %d \n",ROM_IntPriorityMaskGet());

    Priority of Timer 2A is 0

    Priority of GPIOQ1 is 128

    preemtable priority bits is 7

    Priority Masking : 0

    Masking is 0, So Will there be any effect on Interrupt prioritization ?

     

     

     

  • 0 in reply to cb1
    Intellectual 920 points

    It seems to me that it would make the most sense for the TivaWare function SysCtlPeripheralEnable( . . . ) to actually verify that the peripheral has been enabled before returning.  Is there any reason that this peripheral driver library function does not do this?  I understand that some applications might be time-sensitive and do things in a way that doesn't require this check, but I would assume that such an application would likely not use TivaWare anyway.  My two cents.

  • 0 in reply to Jim Gavin
    TI__Guru**** 244400 points
    Hello Jim,

    Unfortunately, we should have pushed the same in the peripheral library but for reasons of granularity of the TivaWare it was rejected and instead kept as a separate API.

    Regards
    Amit