• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 473 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

PLL1 failed !

Tan Dat Tran
Intellectual 680 points
Other Parts Discussed in Thread: HALCOGEN

I have a problem with clocking, PLL1 does not work, PLL2 is not working correctly.

Can anybody recommend me some tips to design OSC circuit and PCB for the clocking module.

By the way, what the difference between normal GND and Kelvin_GND. Do I have to connect it to normal GND ?

What kind of crytal should I use and the compensate capacitor for the crytal.

If I use a 25Mhz crytal, what value of compensate capacitors should I use ?

Should I use a 4-pins crytal ?

 

  • 0
    TI__Guru**** 197306 points

    Hi Tan,

    Can you tell us what the problem with PLL1/2 are? Are those problem from your from own PCB board or from TI HDK or MDK? 

    Regarding the circuit, please refer to Figure 4-4 on Page 59 of spns162.pdf (http://www.ti.com/lit/ds/spns162/spns162.pdf)

    The values of C1 and C2 should be provided by the resonator/crystal vendor. Kelvin_GND should not be connected to any other GND.

    You can use either 2 pin or 4pin crystal, but the maximum crystal frequency is 20MHz., so you can not use 25MHz for our current TMS570LS31x/LS2x device.

    Regards,

    QJ

  • 0 in reply to QJ Wang
    Intellectual 680 points

    It's a custom board. It seems there's no problem in the circuit and the PCB but when I set up PLL2/PLL1 for RTI, it does not work. I thought that they both failed. When I set PLL2 for the clock source, VCLK for RTI and counter is set for 1 seconds interrupt, it works nearly 2s. That was a serious problem because if PLL1 and PLL2 both failed, what was the clock source like 80Mhz ?? All code was generated by HALCOGEN.

  • 0 in reply to Tan Dat Tran
    TI__Prodigy 110 points

    Hi,

    Can you please sanity check if your c code generates the expected (prescaler) values for the PLL configuration registers (PLLCTL1 and PLLCTL2 for the 1st PLL, and PLLCTL3 for the 2nd PLL). It may be that the HalCoGen version you are using does not generate proper code in this case. I have already asked the Software department to check the HalCOGen for the proper code generation.

    May be you have a similar problem as reported on Nov 9th "Clocking problem" (Thread ID: 145155); please see my comments I gave for this post.

    Kind Regards,

        Rainer

  • 0 in reply to Tan Dat Tran
    TI__Mastermind 49120 points

    Hello Tan,

    It appears that an oscillator fail condition is being detected. Can you confirm by reading out the contents of the system exception status register (SYSESR @ 0xFFFFFFE4) and the system global status register (GLBSTAT @ 0xFFFFFFEC)? The system.c file generated by HCG trims the internal Low Power Oscillator (LPO) such that the clock monitoring base frequency is as close to 10MHz as possible. This allows an oscillator range of 2.5MHz up to 40MHz. Please also note that an oscillator frequency of 25MHz is not supported, as someone indicated earlier.

    Do you intentionally cause a system reset in your application, or is there another reason for a reset to occur? You can check this by reading the SYSESR. A system reset causes the LPO trim settings to go back to the default value. We have observed some overshoots and undershoots in the clock monitoring base frequency when this happens. This has shown to cause an oscillator failure detection in some cases (as the clock monitor base frequency drops below 25MHz / 4, which has been observed before).

    Once an oscillator failure is detected, the oscillator input to the PLL is switched to the clock monitoring base frequency, which gets trimmed again to 10MHz once the code restarts after the reset is released. This gets scaled to 80MHz by the PLL as per your configuration (I assume that you are trying to get 200MHz from a 25MHz oscillator).

    In order to further assist in the debug, you will have to provide your PLL configuration information, the oscillator information, values of SYSESR and GLBSTAT when the issue occurs, and information about whether you see the system reset (nRST) pin get driven low before you see the issue.

    Regards, Sunil

  • 0 in reply to Rainer Troppmann
    Intellectual 680 points

    I used the latest version 2.11. And HALCOGEN was fine, I did check the code in systemInit().

    It seemed there's no problem. What I'm trying to firgure out is why RTI work with VCLK and work with all prescale values set for 80Mhz, PLL2 was used for GLCK and the performance of a for loop is one half of an ARM CM3 (count = 160 000 000 for 160Mhz setting, count 100 000 000 for 100Mhz ARM CM3)

    It work well when I used HLPO.