• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 103 subscribers
  • Views 825 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.

C5535 PLL multiplier anomoly

John Atkins96586
Prodigy 100 points

I'm seeing strange behaviour with the C5535 PLL multiplier. I noticed a small error in my output frequency, so tried a range of configuration values and got a dodgy result. I'm using the RTC as the system clock source,  with a 32.768 kHz oscillator. My PLL register settings are:

CGCR2 0x8000  (RD BYPASS = 1)

CGCR3 0x080E  (default)

CGCR4 0x0201 (OUT DIV ENABLED, OD = 1 (so pll out gets devided by 2))

I have tried a range of values for M in CGCR1 and  measured the corresponding frequency at CLKOUT. results are:

M vs f (hz)

2006 : 32916050

2005 : 32932450
2004 : 32899710
2003 : 32883310
2002 : 32850540
2001 : 32866910
2000 : 32834180
1999 : 32817750
1998 : 32784970
1997 : 32801370
1996 32768610

If you plot this it looks like a sawtooth instead of a straight line (see below).    

Am I missing something, or is this a hardware bug?

  • 0
    TI__Mastermind 35645 points

    Hi,

    Team is working on and will address your request shortly.

    Thanks & regards,

    Sivaraj K

  • 0
    TI__Mastermind 23785 points

    The default value for 0x1C22 is 0x0806. Please confirm.

    "Initialization bits for the DSP clock generator. These bits are used for testing purposes and
    must be initialized with 0x806 during PLL configuration for proper operation of the PLL."

    Regards.

  • 0 in reply to Steve Tsang
    Prodigy 100 points

    I can confirm that 0x1C22 (CGCR3) is initialised to 0x0806. This is done in the CSL PLL_reset  function.

    The value in my post is what 0x1C22  subsequently changes to (by hardware) when the CSL PLL_config function sets the top bit in CGCR1 (line 173 csl_pll).

    To verify this bug, set the PLL M in CGCR1 to 2001. This should give a multiple of M+4 = 2005, but instead gives 2006.  Then increase M to 2002, and your multiple actually drops to 2005.  

     

  • 0 in reply to John Atkins96586
    TI__Genius 12575 points

    Hi,

    Please see my responses marked in "blue" for your inputs.

    The value in my post is what 0x1C22  subsequently changes to (by hardware) when the CSL PLL_config function sets the top bit in CGCR1 (line 173 csl_pll).

    Could you let us know which CSL version you are refering to ? The line 173 you are refering to points to the following CSL code in CSL version 3.04 .

     173:    if(NULL == pconfigInfo)
     174:    {
     175:       status = CSL_ESYS_INVPARAMS;
     176:       return status;
     177:       }

    To verify this bug, set the PLL M in CGCR1 to 2001. This should give a multiple of M+4 = 2005, but instead gives 2006.  Then increase M to 2002, and your multiple actually drops to 2005.

    I Believe you had set 0x87D1 in CGCR1 to get the value 2001.

    Could you let us know, where & how you capture the value of 2006  instead of 2005. 

    Regards

     Vasanth

     

  • 0 in reply to Vasantha K
    Prodigy 100 points

    Hi Vasanth,

    Thanks for your reply. I am measuring the output of the PLL multiplier by enabling the CLK_OUT pin and measuring the frequency on that pin with a frequency counter.

    I'm not sure which version of the CSL I have - I cant find the version stated anywhere. But line 173 reads : 

    CSL_FINST(hPll->sysAddr->CGCR1, SYS_CGCR1_CLR_CNTL, SET);

    Looking forward to your reply,

    John

     

  • 0 in reply to John Atkins96586
    TI__Genius 12575 points

    Hi John,

       There should be a release notes which comes with the CSL package. Could you refer and let us know the CSL version.

       Also, Its suggested to move to the latest version of CSL. Latest CSL version will have some of the bug fixes.

    Regards

     Vasanth