• State Answer Suggested
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 2187 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.

Clocking problem (oscillation failure on TMS570LS3137-PGE)

Andre Schreiter
Prodigy 55 points
Other Parts Discussed in Thread: TMS570LS3137

Hi,

I have a clocking problem on a custom board which is equipped with TMS570LS3137 (i.e. TMX570LS3137PGE).

The input clock is not derived from a crystal oscillator, instead a 50MHz square wave clock is input into OSCIN pin (KELVIN_GND and OSCOUT are left unconnected).

When running the system initialization I am able to setup FMzPLL successfully (VALID bit in SYSREG1.CSVSTAT gets set for PLL1 clk source). But my program is actually not executed with the expected processor speed - it is much slower.

Debugging showed me that the OSCFAIL bit in SYSREG1.GBLSTAT is set after reset and before system init (PLL setup, etc.) is started. In ESM module the "clock monitor" error is also signalled. I guess this problem has something to do with clock detection/monitoring feature on OSCIN signal, the resulting frequency would then be the frequency of HF LPO clock source (which is indeed much slower than the desired one..). But trying to fix this problem, did not lead to any success yet.

Is there any recommendation how to initialize a system that uses a square wave clock on OSCIN input instead of crystal oscillator?

Thanks in advance for any advice!

  • 0
    TI__Mastermind 23000 points

    Andre,

    As per the datasheet (section 4.6.1.1.1), the input clock frequency is limited to 20 MHz maximum (50ns) when driving in a square wave.  I suspect the clock monitor circuit has detected an invalid input clock and has reverted operation to the internal LPO clock source (~10 MHz).  You will need to use an input clock frequency which is supported by the datasheet limits.

    Regards,

    Karl

  • 0 in reply to KGreb
    Prodigy 55 points

    Karl,

    thanks for your answer. I agree with you when the controller is connected to a crystal oscillator (as shown in figure 4-4 (a) in the datasheet section 4.6.1.1). Then the maximum frequency is limited to 20MHz as stated in section 4.6.1.1.1 - parameter "tc(OSC)". In my case the controller is supply by an external clock signal as shown in figure 4-4 (b). In that case I assume that parameter "tc(OSC_SQR)" is applicable. If so, the maximum frequency would then be 80MHz. Is that assumption correct?

    Regards,

    Andre

  • 0 in reply to Andre Schreiter
    TI__Mastermind 22715 points

    Andre,

    The number in Figure 4.4 only indicates the limit of input signals the clock input circuit can handle electrically. Inside the clock input circuit, there is a clock monitor. It will set the OSCIN fail flag once the input frequency is beyond 3 - 30MHz..  The clock monitor is enabled after reset. As suggested by Karl, you should use a clock input about 20 MHz. If you really want to use this 50 Mhz input, you can use software to first disable the clock monitor and clear the OSC fail flag. My personally preference is to use a lower frequency clock.

    Thanks and regards,

    Zhaohong

  • 0 in reply to Zhaohong Zhang
    Prodigy 55 points

    Zhaohong,

    thanks for your answer. Changing the hardware is not an option as the current prototype is equipped as described. Luckily the next prototype run will then be equipped with a 20MHz crystal oscillator.

    Disabling the clock monitor did not work for me. I tried to follow the instructions given in the users guide (section 10.4.5.1).

    1. set RANGE DET ENA SSET (CLKTEST.24) to 1
    2. set RANGE DET CTRL (CLKTEST.25) to 0

    After that I tried to clear the OSCFAIL bit in SYS1.GLBSTAT following the procedure given in section 10.4.3 of the users guide. But the OSCFAIL remained set.

    But finally the good news:

    With your hint to the clock monitor I managed to find a solution for my problem. The frequency range in which HF LPO is trimmable is big enough to move the clock monitor window up to also cover the 50MHz input frequency (section 10.4.1). I changed my init sequence to do the following:

    1. load trim values from OTP to LPOMONCTL
    2. increase the trim value for HF LPO step-by-step until its maximum value is reached
    3. perform "recovery from oscillator failure" as described in section 10.4.3 (-> now the clearing of OSCFAIL bit worked)
    4. setup PLL
    5. ...

    With that my system now runs at the expected speed.

    Again, Karl and Zhaohong, thanks for your support.

    Regards,

    Andre