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.

Timer Interrupt issue when in while (1);



Dear all,

I have tried LM4F232 evaluation board to develop my application, registered the interrupt for timer0A & UART in startup_ccs.c

UART interrupt is triggered when receive data from PC.

Timer0A is listening the peripheral devices such as usb, keyboard, mouse move,...

I write down the following code for Timer0A , and then UART cannot receive any interrupt anymore.

How could I receive UART interrupt when Timer0A do the following code? I know is while loop issue, is there any method to solve this issue? Thank you :)

void timer_main_initial(void)
{
    SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER0);
    TimerLoadSet(TIMER0_BASE, TIMER_A, (SysCtlClockGet()));
    TimerConfigure(TIMER0_BASE, TIMER_CFG_16_BIT_PAIR | TIMER_CFG_A_PERIODIC);
    IntMasterEnable();
    TimerIntEnable(TIMER0_BASE, TIMER_TIMA_TIMEOUT);
    IntEnable(INT_TIMER0A);
    TimerEnable(TIMER0_BASE, TIMER_A);
}

void timer_main_closing(void)
{
    IntDisable(INT_TIMER0A);
    TimerIntDisable(TIMER0_BASE, TIMER_TIMA_TIMEOUT);
    TimerIntClear(TIMER0_BASE, TIMER_TIMA_TIMEOUT);
}

void timer_main(void)
{
    while (1){
        //Listen peripheral devices
        
    }
    TimerIntClear(TIMER0_BASE, TIMER_TIMA_TIMEOUT);
}

  • You should not have a while(1) in your interrupt handler.  That causes the code to stay in the interrupt handler forever, so no other interrupts are ever processed.

    What you should do in your timer interrupt is check for inputs from your peripheral devices once, then return.  The next time the timer fires, you will check again.

  • Beyond posters "while(1)" advice note this:

    void timer_main_initial(void)
    {
        SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER0);
        TimerLoadSet(TIMER0_BASE, TIMER_A, (SysCtlClockGet()));

    We're told that "enabling a peripheral" requires 5 System Clocks to complete.  Code shown may be in violation - inserting a very brief delay after "SysCtlPeripheralEnable()" should resolve.  Note that this "rule" seems not to always hold but safety/sureness should trump "good fortune/hope," - methinks... 

    Perhaps the incorporation of such delay w/in tail-end of "SysCtlPeripheralEnable()" could be considered.