• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 225 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.

EK-TM4C123GXL: Timer seems wrong at low load counts

John Hite
Intellectual 370 points
Part Number: EK-TM4C123GXL


Using the code below, the clock is set for 80 MHz. Here are some results for the interrrupt interval for various values in  MAP_TimerLoadSet(). Have I setup something wrong? 

Load Measured      Expected

320   249.25 KHz   250 KHz

160   497 KHz        500 KHz

 80   823 KHz        1 MHz

40    821 KHz        2 MHz


#include <stdint.h>
#include <stdbool.h>
#include "inc/hw_ints.h"
#include "inc/hw_memmap.h"
#include "inc/hw_types.h"
#include "driverlib/debug.h"
#include "driverlib/fpu.h"
#include "driverlib/gpio.h"
#include "driverlib/interrupt.h"
#include "driverlib/pin_map.h"
#include "driverlib/rom.h"
#include "driverlib/rom_map.h"
#include "driverlib/sysctl.h"
#include "driverlib/timer.h"
#include "driverlib/uart.h"
#include "utils/uartstdio.h"

#define SYSTEM_TICKS_PER_SECOND 1000000UL

volatile static uint64_t ticks;

void Timer0IntHandler();
uint64_t    getTicks();



void
Timer0IntHandler()
{
    static bool toggle = 1;
    TimerIntClear(TIMER0_BASE, TIMER_TIMA_TIMEOUT);
    ticks++; // Microseconds since power up.
    GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_2, GPIO_PIN_2); //Blue
    GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_2, 0);
    toggle = !toggle;
    //Tickle scheduler...
}


int
main(void)
{
    volatile uint32_t loops = 0;
    volatile uint64_t t;

    MAP_SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);

    // LED debugging setup
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);
    MAP_GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_2 | GPIO_PIN_3);

    //Timer 0 setup.
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER0);
    MAP_IntMasterEnable();
    MAP_TimerConfigure(TIMER0_BASE, TIMER_CFG_PERIODIC);
    MAP_TimerLoadSet(TIMER0_BASE, TIMER_A, 40UL); //(SysCtlClockGet() / SYSTEM_TICKS_PER_SECOND));
    MAP_IntEnable(INT_TIMER0A);
    MAP_TimerIntEnable(TIMER0_BASE, TIMER_TIMA_TIMEOUT);
    MAP_TimerEnable(TIMER0_BASE, TIMER_A);

    while(1)
    {

    }
}

  • 0
    TI__Guru**** 191906 points

    Hi John,

      I think the explanation is very similar to where I answered you in the other post. https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1088930/ek-tm4c123gxl-unexpected-performance-limit

      The timer you configure uses the system clock as the clock source running at 80Mhz. You have the preload value equal to 40. This means every 40 system clock cycles it will generate an interrupt. In your interrupt, you perform several operations. Below is the disassembly code of Timer0IntHandler(). As you can see it take quite some instructions to execute the ISR. There is also some latency from the time the interrupt is triggered by the timer module until the processor enters the ISR. All of these will exceed 40 cycles. In your measurements, you measure about the same for both 40 and 80 as the preload value. You can try 4Mhz or higher and you will be measuring similarly as in 2Mhz and 1Mhz because the number of cycles to execute the ISR and the latency to enter the ISR is independent of the interrupt interval you configure. Normally, you would like to keep the ISR as simple as possible. This is what RTOS does for the interrupt handling. You can try to just set a flag in the ISR. In the main code, base on the flag to process your inputs (e.g. set and clear the LED) and then clear the flag. 

  • 0 in reply to Charles Tsai
    Intellectual 370 points

    Hello again and thanks for the quick reply. Will definitely try your suggestions. 

    Off to Zoom scrum now...

  • 0 in reply to John Hite
    Intellectual 370 points

    Once again, your detailed answers are much appreciated. 

    I noticed one thing I thought peculiar, I commented out the TimerIntClear() in the ISR and it seemed to have no effect.

  • +1 in reply to John Hite
    TI__Guru**** 191906 points
    John Hite said:
    I noticed one thing I thought peculiar, I commented out the TimerIntClear() in the ISR and it seemed to have no effect.

    It will clear the flag. It is just that by the time the flag is cleared, it is set again before you exit the ISR because the interrupt comes in so quickly. 

    You can try to comment out TimerIntClear for the 250Khz scenario. Without clearing the flag, it will re-enter the ISR as soon as it exits the ISR. The behavior now will be similar to 1Mhz or 2Mhz. I will expect you to measure close to 823Khz instead of 250Khz expected. 

  • 0 in reply to Charles Tsai
    Intellectual 370 points
    Charles Tsai said:
    You can try to comment out TimerIntClear for the 250Khz scenario.

    Doh me, of course. Just call me Homer. I made that observation last night and just parroted this morning. I am going to blame it on being older than dirt and being up past my bedtime. Works as described by you...