• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 436 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.

TMS570ls3137 oscillator issue

Johnson John
Intellectual 640 points
Other Parts Discussed in Thread: TMS570LS3137

Hi,

We are using TMS570LS3137 processor in custom board and using 20MHz oscillator for clkin input. In two boards (some boards are working fine), we are facing oscillator failure status flag issue. But the oscillator is at 20MHz and don't see any issue. So we programmed the ECLK output to OSC option and measured frequency is 4.79MHz frequency and oscillator fail status bit is also set. I would like to know why we are getting 4.79MHz instead of 20MHz in ECLK output and also why the oscillator fail flag bit is set when the oscillator is within the range? How to resolve this issue?

regards 

  • 0
    TI__Guru 59540 points

    Hello Johnson,

    Most likely, there is some anomaly happening at startup or the external oscillator is not starting/stabilizing fast enough causing the clock monitor in the device to detect a failure on the oscillator. I would suggest checking/capturing the oscillator startup on a scope and comparing between a "good" board and the "bad" ones. This should help narrow in on the issue.

    In regard to the 4.79MHz output on ECLK, when the clock monitor detects a clock failure, the device enters a limp mode and the HFLPO is used in place of OSCIN. Dependent PLL settings and/or ECLK dividers, this could be why you are seeing 4.79MHz.

  • 0
    TI__Mastermind 20090 points

    Hi Johnson,

    4.79MHz seems too low for the LPO. The LPO is typically higher frequency. With 4.79MHz, there is little doubt as to why the oscillator is failing -- the crystal frequency is too fast compared to the LPO.

    What I would suspect is that you have some software problem in trimming the LPO. Check to see if you are changing the lpo trim. I think that you'll find that you are writing a low value (like 0) rather than the expected value from the OTP.

     

    Best regards,

    Kevin

  • 0 in reply to Kevin Lavery
    Intellectual 640 points

    Thank you Kevin.

    I did not understand your last two lines in your reply and how to check? Can you please elaborate?

  • 0 in reply to Johnson John
    TI__Mastermind 20090 points

    Hello Johnson,

    I'll try to expand on my previous statement:

    The LPOMONCTL register at 0xFFFF_FF88 contains bits that control the frequency of the LPO clock. These bits are referred to as TRIM bits since they move the LPO frequency from its default frequency. The bit field that you will be concerned about is HFTRIM (LPOMONCTL.12:8). Check to see if you are writing this bit-field.

    You can check whether you are writing this field in a variety of ways:

    1.) Probably the most direct way to see if (and where!) you are writing the vlaue is to place a watchpoint on a write to the address.

    2.) Secondarily, you can connect the debugger to the part. and drive the HFLPO (clock source 5, I think) to the ECLK pin. Then you can vary the bit fields in LPOMONCTL.12:8 to measure the frequency range of the LPO. The default value for the HFTRIM bit field is 10000b; typically this default value gives you a frequency in the 8 - 11MHz range. If you find this default value for the bit field gives you the typical frequency range, then you know that the 4.8MHz frequency you are measuring results from an errant trim in your software.

    Note: It is expected that you write to this register, so the write, itself, is NOT a problem. The issue arises from the value written. Typically, the value is taken from OTP so it may take a few more iterations to get to the bottom of this problem. 

    Note also that the variation in LPO frequency means that a systematic error in trim may result in some parts that fail the oscillator and other parts that do not fail the oscillator. So, even though I am suggesting a systematic root cause, the same cause may well show itself differently on different pieces of the same silicon design.

    Best Regards,

    Kevin