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.

TM4C123GH6PM Timer Problem with Current Values

Other Parts Discussed in Thread: TM4C123GH6PM

1) I am using a precision pwm signal from another microcontroller to generate a digital input interrupt.

2) I am using wide timer 1, set for periodic mode and counting up. I load the value of the timer to 0xFFFFFFFFFFFFFFFF.

3) I am running the TM4C at 80mhz

4) Inside the digital interrupt routine I have tested reading the actual values of the timer using both driverlib calls and direct register calls. Most of the time my values are +8/-8 counts, interrupt to interrupt, which is what I expect. Periodically, my values are off by hundreds of counts and I cannot figure out why!

5) I have spent days testing my code for correctness and have even set up 3 timers the same way. All 3 timers exhibit this problem at the same instant in time so I suspect there is something occurring in the TM4C background that is causing this.

6) I am fully aware of the low value to high value transition and how to properly read using direct register calls.

7) I am using usb to send data out and have set the usb interrupt priority to higher than the digital input interrupt.

Does anyone know of any reported problems with reading actual timer values or what could be occurring in the background to affect reading timer values?

  • Hello Mark.

    When the value is off by hundreds of count, can you check if there is a rollover of the timer, by capturing the start and end counts?

    Regards
    Amit
  • I am accounting for the rollover. A rollover would only add three more value reads.
  • Hello Mark,

    Then we need to establish the "periodicity" of the failed capture. There are 3 things to be done

    1. Count the number of iterations after which the failure re-appears
    2. Get the start and end count value at the time of failure
    3. Toggle a GPIO on the output at time of the failure to capture the PWM input signal on a scope with the GPIO set as trigger.

    Regards
    Amit
  • Mark LoBuono said:
    7) I am using usb to send data out and have set the usb interrupt priority to higher than the digital input interrupt.

    Is the digital input interrupt allowed to preempt the USB interrupt?

    See Interrupt priority grouping for how the Cortex-M4 interrupt preemption is allowed.

  • I have turned off the usb to see if this is causing any problems. I am using internal arrays to trap bad timer values.
    As soon as I can prove that i have good timer values I will go back to using usb and get some spreadshheet data to show you what is happening.
  • Chester,

    Thanks for responding.

    Yes, the digital interrupt priority is lower than that of usb.

    //Set the interrupt priorities
    IntPrioritySet(INT_GPIOA, 0);
    IntPrioritySet(INT_USB0, 1);

    Have you ever tested for wide timer value reading and it's accuracy?
  • Mark LoBuono said:
    Most of the time my values are +8/-8 counts, interrupt to interrupt, which is what I expect. Periodically, my values are off by hundreds of counts and I cannot figure out why!

    Rather than using an input interrupt to trigger a timer read in software, could you use a timer in Input Edge-Time Mode to cause the timer to capture the time of an input edge on a Capture/Compare/PWM pin?

    If the timer hardware performs the capture of the input edge, I think the count variation due to software interrupt latency should be avoided.

    [My suggestion is based on a quick read of the TM4C123GH6PM datasheet, I haven't attempted to implement Input Edge-Time Mode]

  • I need to capture time values and measure elapsed time for a group of real world digital inputs.

    Amit,

    With the usb disabled I do not trap any timer rollovers or bad values, so the usb is causing my problem.
  • Mark LoBuono said:
    Have you ever tested for wide timer value reading and it's accuracy?

    Unfortunately, no.

    Mark LoBuono said:
    Yes, the digital interrupt priority is lower than that of usb.

    //Set the interrupt priorities
    IntPrioritySet(INT_GPIOA, 0);
     IntPrioritySet(INT_USB0, 1);

    A complication of the interrupt priority handling scheme in the Tiva C devices is that only the 3 most significant bits of the 8-bit interrupt priority get used by the NVIC. See the description of the IntPrioritySet TivaWare function or the TM4C123GH6PM datasheet for more details.

     This means the priority values 0 and 1 are actually the same priority.

    i.e. try:

    //Set the interrupt priorities
     IntPrioritySet(INT_GPIOA, 0);
     IntPrioritySet(INT_USB0, 0x20);

    The default value the PRIGROUP field in the Application Interrupt and Reset Control (APINT) register is 0, which means the the GPIOA and USB0 interrupts will then be in different groups, which should allow a GPIOA interrupt to preempt a USB0 interrupt.

  • Chester and Amit,

    That solved my problem. I guess I would have to read all of the datasheet to know all these details.

    Thanks to both of you.