• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 78 subscribers
  • Views 264 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

LP-MSPM0G3507: MSPM0G3507

Ulysses Fonseca
Prodigy 60 points
Part Number: LP-MSPM0G3507

I did notice that the timer has an delay. I set the TIMG8 to trigger on 4ms, but I'm getting interrupts on 4,013ms. I'm using ULPCLK as clock source at 40Mhz with 8 of divider, so getting 5Mhz. My ULPCLK is derivate from SYSOSC (32Mhz) and PLL getting an CPUCLK of 80Mhz. I did measured ULPCLK and I'm getting 39,96Mhz, so with this clock error the timer should trigger on 4,0038ms. So I have an error of 10us.

I'm using A14 to measure the clock and A0 to measure the TIMG8 trigger, and an oscilloscope (100Mhz 1GSa/s) to measure the frequency

  1. This MCU has an delay between reach the timer counter and call the IRQ handler? even using an standalone project just with this timer an using it on the highest priority.
  2. The pins I'm using could cause this delay?
  3. I'm measuring this delay on a standalone project and on the final project that has many timers running, adc, freertos and much more, the error still the same. What could be the root cause of this error?
  • 0
    TI__Mastermind 28070 points

    HI Ulysses,

    Ulysses Fonseca said:
    This MCU has an delay between reach the timer counter and call the IRQ handler? even using an standalone project just with this timer an using it on the highest priority.

    There is some delay when going from thread mode to handler mode, its worse when you are waking from a low power state. Is your device going to sleep or shutting off the CPU? How are you toggling this pin? Is this timer in compare mode and changing the state of the pin automatically? It sounds to me more like you are toggling the pin manually inside the ISR.

    Ulysses Fonseca said:
    The pins I'm using could cause this delay?

    There could be different propagation delay for different pins, but nothing on the order of uS.

    Ulysses Fonseca said:
    I'm measuring this delay on a standalone project and on the final project that has many timers running, adc, freertos and much more, the error still the same. What could be the root cause of this error?

    Well at the very least that test tells us its not an issue related to the loading of the CPU. If you are measuring time the the execution of an ISR then the processing of other interrupts (assuming uniform priority), can certainly prevent another interrupt from being serviced immediately.

    Best Regards,
    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    Prodigy 60 points

    Hi Brandon,

    1- My device is on RUN1 and I'm not changing this during my tests. Yes, I'm toggling manually inside the ISR using DL_GPIO_togglePins. What you suggest for my test to check this?

    2- Yes, I was expecting some pin delay on nS order.

    3- Yes, on our final project most of the interrupts use the same priority, just few cases we use the interrupt with higher priority. But on my tests I did check this just running one interrupt TIMG8.

  • 0 in reply to Ulysses Fonseca
    TI__Mastermind 28070 points

    Hi Ulysses,

    Do you have the debugger enabled during these tests?

    If the goal is just to check the accuracy of the timer, they can directly toggle a pin when in compare/pwm mode. That would eliminate the cycles spent to get into the ISR and toggle the GPIO.

    You could also use a timer event publisher to a gpio subscriber to toggle a pin.

    Best Regards,
    Brandon Fisher

**Attention** This is a public forum