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.

Compiler/TM4C123GH6PM: TIMER0 can't count any thing less than 1.7 usec !!

Part Number: TM4C123GH6PM

Tool/software: TI C/C++ Compiler

I am using a timer to generate a pulse with different periods. The timer is working fine when counting from 80 to 16M counts (TIMER0->TAILR). But when I go below 80, it always give the same period (1.7 usec). 

Here is my code: 

#include <lm4f120h5qr.h>
#include <string.h>
#include <stdlib.h>
#include <stdint.h>

void TIMER_INIT(){
  SYSCTL->RCGCTIMER |= (1<<0); 
  //1: Disable the timer (clear the TnEN bit in the GPTMCTL register)
  TIMER0->CTL &= ~(1<<0);
  //2: Write the GPTMCFG with a value of 0x00000000
  TIMER0->CFG = 0x00000000;
  //3: Configure the TnMR field in the GPTMTnMR. 0x2 for Periodic
  TIMER0->TAMR |= (0x2<<0);
  //4:Count up timer
  TIMER0->TAMR &= (1<<4);
  //5: Load the value that you will count down/up to
  TIMER0->TAILR = 16000000; //0x00F42400 16,000,000 this corresponds to the clk speed of this microcontroller
  //6: If interrupts are required, set the appropriate bits in the GPTMIMR
  //7: Set the TnEN bit in the GPTMCTL register to enable the timer and start counting
  TIMER0->CTL |= (1<<0);
}
int main() 
{
 TIMER_INIT(); 
  while (1){
     while((TIMER0->RIS & 0x00000001) != 1){} // Wait if TIMER0 has not timed out. 
     TIMER0->ICR |= (1<<0);
     GPIOC->DATA ^= (1<<5); //trigger C5
                  
    }
}

Note: I am using a logic analyzer to measure the pulse period. 

  • Hello Abdel

    If you indeed want the timer to generate a pulse out, then use PWM rather than relying on the counter value and interrupt status bits.
  • Thanks for your respond.
    The PWM will not work for me, since I am not generating a regular signal.
    So if you can help me figure out the problem here, I will appreciate it.
  • Hello Abdel

    What is the resolution of the signal you are expecting? Please note that the entire loop requires a minimum number of operations to be done. Did you check the number of instructions being used in the loop?
  • That's a good point. No I didn't consider the number of instructions.
    How can I know the maximum instructions that can be used inside the loop ?
  • Abdelrahman Tarief said:
    That's a good point. No I didn't consider the number of instructions.

    It's worse than that, it's also any wait states needed to access the peripherals, the overhead of the pointer indirection and the effects of compiler optimization. Code placement can even play a role.

    There's really no good way to know in advance and because of the placement and wait state issues even counting cycles is problematic. Really the only reliable method is measurement and then then you will have to accept that there will be a fair margin of error at smaller periods.

    I would suggest you not use an xor operation for measuring, it's too easy to mess it up. Once you have your data and plot it you are likely to find increasing error at smaller periods showing granularity of your loops and the minimum loop time.

    Finally on your specific measurement you don't appear to set your output pin anywhere. You seem to be relying on some implicit setup somewhere. This is problematic.

    Robert

  • Hello Robert, All,

    On the TM4C123x device there is not wait state below 40MHz. So if the system clock is less than 40MHz, the wait state will not come into play. Peripheral access is one cycle path.
  • This code is just to fix the problem I am having, I didn't post my main code.
    May be increasing the clock frequency of the MCU, and taking account for the delay times that will be taken by the other instructions inside the loop, that could solve the problem.
  • Abdelrahman Tarief said:
    This code is just to fix the problem I am having, I didn't post my main code.

    Not doing the needed initialization will make it harder to find and fix the problem.

    Abdelrahman Tarief said:
    May be increasing the clock frequency of the MCU,

    Measure first, then change. Otherwise you do not know how much difference (if any) the change produces.
    There's a very deep rabbit hole here, I've been down it myself being too eager to changes and not disciplined enough to see what effect my changes had.

    You may find that some changes make things worse, contrary to expectations. If you make a lot of changes at once you may miss chances for understanding and improvement.

    Robert

  • BTW, one of the first tests I would run would be to toggle the output as quickly as possible, that will give a rough bound to the access time to the output pins (including instruction overhead).

    Robert