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.

TMS320F28375D: Is CPUTimer0 and 1 could syncronous countor operation?

Genius 3186 points
Part Number: TMS320F28375D
Other Parts Discussed in Thread: C2000WARE

Hi

May I have question about F28375D CPU Timer?

My customer set as this:

CPU Timer 0

・interrupt every 100 ns

・not set prescaler 

・In interrupt function, GPIO is high (for debug)

CPU Timer 1

・interrupt every 4 us

・set prescaler 4 (countor clock will be 1/4)

・If interrupt 125 times, GPIO will be high (for debug, see High every 500 ns)

--

In this setting, I think GPIO high timing must be same every 500 ns.

(Strictly speaking, they don't overlap, but I think they don't change at almost the same time.)

However My castomer's test was not.

First GPIO high timeing was same every 500 ns, but the timing gradually slipped.

Do you have any infornamation of this issue?

Thanks,

GR

  • Hello,

    I'm not sure I understand the issue, the customer is seeing that the CPU timer having inconsistent timing? Can you provide more details and/or a screenshot of some GPIO toggle for the interrupt? Also, are they running in a debug session or on Flash? These situations will both inherently cause a slight delay in the trigger of the counter being observed.

  • Hello Omer,

    Thanks for supporting.

    I'm not sure I understand the issue, the customer is seeing that the CPU timer having inconsistent timing? Can you provide more details and/or a screenshot of some GPIO toggle for the interrupt?

    This is screenshot of GPIO toggle.

    Also, are they running in a debug session or on Flash? These situations will both inherently cause a slight delay in the trigger of the counter being observed.

    I will check to my customer,

    But I think if there is slight delay, both timer will be delay, So interrupt timing will be not off.

    Best regards,

    GR

  • This is screenshot of GPIO toggle.

    Okay, so based on my understanding the issue is that the GPIO toggle for the timer appears to be fine at first, but after some time it shows deviation based on the initial timing diagram, correct? Can you tell how much the toggle has deviated by from what it was originally? The ISR always takes some extra amount of clock cycles to execute because it has code within it, so this may be why there is some deviation.

    I will check to my customer,

    But I think if there is slight delay, both timer will be delay, So interrupt timing will be not off.

    I see what you mean, I agree that the timing would still be off (although the delays between toggles might be longer).

  • Hi Omer,

    Thanks for your supporting,

    Okay, so based on my understanding the issue is that the GPIO toggle for the timer appears to be fine at first, but after some time it shows deviation based on the initial timing diagram, correct? Can you tell how much the toggle has deviated by from what it was originally?

    Yes, First Timing was fine. but after some time, it show deviation.

    I will check with the customer how much the deviation is.


    Also, the deviation is increasing in proportion to the time.

    The ISR always takes some extra amount of clock cycles to execute because it has code within it, so this may be why there is some deviation.

    Is this mean, the count will be stop in the ISR function?

    My understand was Countor will be reload at zero event instantly.


    Best regards,

    GR

  • P.S.

    I will check with the customer how much the deviation is.

    First, There is small devision,

    And after 45-60 second, the division was about 0.1 mili second.

    The deviation increases over time.
    Rather than deviating in a linear fashion, the deviation appears to accumulate at random.

    Also, are they running in a debug session or on Flash?

    My customer test was standalone and code was wrote in flash memory.

    Thanks,

    GR

  • My customer test was standalone and code was wrote in flash memory.

    The Flash has wait states and will cause a delay in timing, especially in executing code like an ISR, but this should be a consistent delay not something that's random.

    The deviation increases over time.
    Rather than deviating in a linear fashion, the deviation appears to accumulate at random.

    Can you provide the ISR that the customer has? Also, can they provide some numbers or a plot for the 'random' increases in delay? The 0.1 ms delay is a lot for unexpected deviation in the timer interrupt, this is thousands of clock cycles. Are there any other interrupts in the code which could take priority over the timer interrupt?

    Also, has the customer already tried programming one of the timer examples from C2000Ware to see if that works as expected?

  • Hi Omer,

    Thanks for supporting.

    Can you provide the ISR that the customer has? Also, can they provide some numbers or a plot for the 'random' increases in delay? The 0.1 ms delay is a lot for unexpected deviation in the timer interrupt, this is thousands of clock cycles. Are there any other interrupts in the code which could take priority over the timer interrupt?

    Also, has the customer already tried programming one of the timer examples from C2000Ware to see if that works as expected?

    We have asked the customer to check and are currently checking.
    We would appreciate it if you could wait a moment.

    Thanks,

    GR