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.

Timer source difference on C6000, C5000 and AM1x

Anonymous
Anonymous

Other Parts Discussed in Thread: AM1806

Hi All,

 

I would like to ask some questions on timer module.

 

I notice that there are differences in the reference signal for timer module on different TI chips.

 

 

For DM6437, according to page 8 of SPRU989, the timer has source from within the chip and is fixed, which does NOT change with the speed of external oscillator used to drive the DSP.

 

 

 

 

For C5510, according to page 12 of SPRU595c, the timer uses CPU clock, which is therefore subject to change.

 

 

 

For AM1806, according to page 8 of SPRUFV9a, its Real-Time clock module requires an external crystal with fixed 32,768-KHz frequency, which RTC uses as the base for time and calendar counting.

 

 

 

 

So are these difference just design choices to suit different needs? For ARM chips, the RTC module even has calendar in addition to normal timing interrupts/(periodical signal) functionality, together with the requirement on 32,758 KHz external clock, should be all designed for ease of programming as a general purpose processor.

 

For 6437, if the chip has within itself a fixed frequency clock, then the use timing functionalities is also made easy. For example, for a chip whose maximum clock rate is 700MHz, not matter what actual clock rate it is running at (400, 500, 600MHz), code relating to timing doesn’t need to be changed.

 

And for C5510 whose clock signal changes with CPU clock, then once the CPU clock changes, either due to change in internal PLL or external oscillator, all timing functions needs to be updated to accord with the new clock cycle period. This made programming harder and more prone to clock cycle period counting error.

 

So this comparison shows that DM6437 and AM1x are has timing module that are easier to use than C5510. Between DM6437 and AM1x, DM6437 is even more stable in the sense that no additional caution needs to be taken on timing crystal.  For AM1x, if we supply a wrong crystal oscillator, say 75,536-KHz which is two times of 32,768-KHz, then its timing module runs two times faster than it should, hence will give the wrong timing.

 

Are these correct?

 

 

In this post (Different clock rate, different count?) Brad Griffis suggested that

Brad Griffis said:
You mentioned in one of your other posts that xdctools platform wizard specifies the frequency as 594 MHz for DM6437.  That's because the OS has its own internal time base and so it needs to know how fast it is being clocked.

But for DM6437, since CPU clock rate doesn’t affect timer clock rate, supplying the wrong clock rate information in the Platform Wizard, say, 594MHz to a DSP running at 700MHz, actually will NOT cause any error in timing functions.

 

Is this correct?

  

 

 

Sincerely,

Zheng

 

 

  • Zheng Zhao said:
    In this post (Different clock rate, different count?) Brad Griffis suggested that
    You mentioned in one of your other posts that xdctools platform wizard specifies the frequency as 594 MHz for DM6437.  That's because the OS has its own internal time base and so it needs to know how fast it is being clocked.

    But for DM6437, since CPU clock rate doesn’t affect timer clock rate, supplying the wrong clock rate information in the Platform Wizard, say, 594MHz to a DSP running at 700MHz, actually will NOT cause any error in timing functions.

    [/quote]

    That info is still relevant because there are APIs like CLK_cpuCyclesPerHtime that will perform a calculation based on the time you have entered.  Also, you still need to tell what the input clock frequency is to the timer.  That statement about an on-chip 27 MHz clock source is not correct.  The real statement should be that it uses the CLKIN frequency which often will be 27 MHz.  So in this case you still need to specify that the external clock source is 27 MHz, as it could be anything from 20-30 MHz.

    Here's a screenshot from the System Reference Guide showing the clock tree:

     

    And here's one more screenshot showing what "AUXCLK" is from the same guide:

     

  • Anonymous
    0 Anonymous in reply to Brad Griffis

    Dear Brad,

    For

    1. CLK_cpuCyclesPerHtime()
    2. CLK_cpuCyclesPerLtime()

    On their difference:

    1. If TCR.CP is set to clock mode, regardless of inversion setting, these two function differ at most 1.

    2. If TCR.CP is set to pulse mode, then the return value of these two functions can differ widely. Quantitatively, if there is no inversion (pulse is high and reset after PWID+1 cycles), the ratio between CLK_cpuCyclesPerHtime() and CLK_cpuCyclesPerLtime() should be:

    PWID+1

    ------------------------------------------------- (division symbol)

    (PRDn+1) - (PWID+1) = PRDn-PWID

     

    PRDn +1 is because timer counts from 0, 1, ..., PRDn, so total PRDn+1 cycles.

    Is this correct?

     

    BTW, where can the document for CLK_cpuCyclesPerHtime() and CLK_cpuCyclesPerLtime() be found?

     

     

     

    Sincerely,

    Zheng

  • Anonymous
    0 Anonymous in reply to Brad Griffis

    I wasn't careful enough. Oscillator should be made of piezoelectric material and they contain metal, oxygen and other type of atoms. Silicon chips might not be able to embed them.

     

    Zheng