• State Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 687 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.

TMS320F28377S: PLL locking/relocking

Phanumart koksri
Prodigy 15 points

Part Number: TMS320F28377S
Other Parts Discussed in Thread: C2000WARE

There is one unit that we use internal OSC2 as a clock source of the PLL and it seems the cannot locks when power on the unit.

The code that I think it is stuck at is in  InitSysPll function at the while loop to check if the PLL is locked

while(ClkCfgRegs.SYSPLLSTS.bit.LOCKS != 1)

I use a C2000Ware 4.01 version.

But this issue is not occur when configure the unit using OSC1 as PLL clock source.

And I did not see the watchdog reset so I think the code is stuck at PLL lock not waiting when there is a clock diff which is checked after the PLL is locked already.

This issue is not occurs when using Jtag to do debugger reset. It seems works after do a reset using Jtag. The issue does appears only when power on the unit.

There are 2 questions I have.

1. Are there any workaround that I can follow to make PLL locked using OSC2? I think this should possible since I see debugreset can make the PLL lock using OSC2. (I have tried WD reset but after reset the PLL is not locked using OSC2)

2. Is it ok to use OSC1 instead of OSC2 since the OSC1 has no problem?

  • 0
    TI__Guru* 95315 points

    As shown in page 17 of www.ti.com/lit/SPRZ412, PLL: May Not Lock on the First Lock Attempt, this is a known issue. The workaround has been implemented in C2000ware. Unfortunately, I am unable to verify if the workaround has been implemented in v4.01, since I lost access to my old copies of C2000ware when my laptop was replaced. Note that this issue pertains to the PLL and is independent of the input clock source. See code snippet from sysctl.c in the C:\ti\c2000\C2000Ware_5_00_00_00\driverlib\f2837xd\driverlib directory:

    Phanumart koksri said:
    1. Are there any workaround that I can follow to make PLL locked using OSC2? I think this should possible since I see debugreset can make the PLL lock using OSC2.

    The workaround has been implemented in the Driverlib function in C2000ware.

    Phanumart koksri said:
    2. Is it ok to use OSC1 instead of OSC2 since the OSC1 has no problem?

    Yes, it is OK. However, as I said earlier, this problem pertains to the PLL and is not tied to a specific clock source.

  • +1 in reply to Hareesh Janakiraman
    Prodigy 15 points

    Per my understanding if the PLL is not lock it will wait in the while loop forever. Could you explain how the work around is going when the PLL is not lock at the first attempt?

  • 0 in reply to Hareesh Janakiraman
    Prodigy 25 points

    Not clear to me if the issue can happen with OSC1 also since the problem is on PLL side, not in OSC1 nor OSC2 side.

  • 0 in reply to Hareesh Janakiraman
    Prodigy 61 points

    Hi Hareesh

    It is unclear how the proposed "for" loop works. As apparently MCU hangs with i=0 in the inner "while". MCU stucked here if the PLL is not locked.

    In the other hand if you manage to get out of the  "while" loop (PLL locked) what is the purpose of repeating the process 5 times?

    Thanks in advance

    Maria

  • 0 in reply to Maria J Perez
    TI__Guru* 95315 points
    Phanumart koksri said:
    Per my understanding if the PLL is not lock it will wait in the while loop forever. Could you explain how the work around is going when the PLL is not lock at the first attempt?

    If this happens, the WD would reset the device and the PLL locking process will begin again. 

    Mike Cappiello said:
    Not clear to me if the issue can happen with OSC1 also since the problem is on PLL side, not in OSC1 nor OSC2 side.

    If the issue is indeed with the PLL, I agree it can happen with OSC1 as well. I mentioned this in my first reply. If you indeed don't see the issue with OSC1, perhaps OSC2 is the source of the problem and not the PLL. 

    Maria J Perez said:
    It is unclear how the proposed "for" loop works. As apparently MCU hangs with i=0 in the inner "while". MCU stucked here if the PLL is not locked.

    If this happens, the WD counter would reset the device and pull the device out of that condition.

    Maria J Perez said:
    In the other hand if you manage to get out of the  "while" loop (PLL locked) what is the purpose of repeating the process 5 times?

    Valid question. PLL lock is forced 5 times. Once locked, it doesn't hurt to re-lock. Based on empirical data, a value of 5 was deemed effective.

  • 0 in reply to Hareesh Janakiraman
    Prodigy 15 points
    Hareesh Janakiraman said:

    If this happens, the WD would reset the device and the PLL locking process will begin again. 

    I downloaded the version 5 and did not see the Watchdog is enable before entering the LOOP (it is the same with version 4.01), so to work around we have to enable WD before configure the PLL, right?

  • +1 in reply to Phanumart koksri
    TI__Guru* 95315 points

    By default, WD is enabled. i.e. upon reset, it comes up enabled. If any function disables it (as part of device initialization), it must be re-enabled before PLL configuration.

  • 0 in reply to Hareesh Janakiraman
    Prodigy 15 points

    Thank Hareesh, the WD does not enable by default on the C2000Ware example code, but it is clear to me that the WD must be enable before PLL configuration.