• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 511 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.

TMS320F28375S: PLL lock

Aaron Spaete
Expert 4597 points
Part Number: TMS320F28375S
Other Parts Discussed in Thread: CONTROLSUITE, C2000WARE

Team,

My customer is running into the following issue:

We finally have our first prototype boards with this processor. We’re using an external 16 MHz clock and desire to run the software from the internal PLL at 180 MHz. This required an IMULT of 11 and an FMULT of 0.25. Despite following the workarounds in the Errata SPRZ422 Ref F, we are still having a problem getting the PLL to lock consistently. We did not see this issue on the dev boards which were using a 10MHz oscillator and an IMULT of 18 and FMULT = 0. When we changed the FMULT from 0.25 to 0 on our board, the PLL seemed to lock right away every time (@ 176 MHz). Do you know if this issue is specifically related to using an FMULT other than 0? Do you think that should be added to the errata as a possible workaround?

We had a similar issue with an older processor (TMS320C6711) where the PLL would not lock and we had to drain the power supplies with every reset. Is the TMS320F28375 issue related to power supply or supply sequencing/timing?

They are going to run a few more experiments so any detailed or background information you can provide may help us understand the issue and come up with a reliable workaround.

Regards,

Aaron

  • 0
    TI__Mastermind 38740 points

    Hi Aaron,

    I've validated PLL locking using 16Mhz external oscillator and different values of IMULT and fractional FMULT and do not see any issues with locking the PLL.  Can you please get additonal information from the customer on the following whenever possible:

    - Which version of SW was used as basis to generate the PLL locking routine (C2000Ware / ControlSUITE / driverlib)?

    - Did the customer qualify PLL locking by bringing the PLL output externally and observing the frequency and if they do not see an output or the expected signal, they classified this as lock failure as in the case for their prototype boards?  Just wanted to know how failure to lock the PLL was confirmed.

    - Not sure how many prototype boards this issue is seen.  Is it only observed on a particular board or is it observed on all their proto boards?  Reason for asking is that the PLL issue covered by errata SPRF422F applies only to very, very few parts and that the occurence of the specific conditions that lead to the PLL not locking for the first time is very slim.  Hopefully we can isolate the issue with the locking routine implementation.  The latest version of C2000Ware using InitSysPll() function to lock the PLL has the latest SW changes as stated in the errata.

    Thanks and regards,

    Joseph

  • 0 in reply to Joseph Casuga
    TI__Expert 4597 points
    Joseph,

    I think we were able to track down the problem and get consistent results. We were not writing the IMULT and FMULT registers simultaneously (FMULT first followed immediately by IMULT). We may have copied some code from C2000WARE v2, but it looks like v3 has the simultaneous write.
    We were monitoring a GPIO which was some fractional frequency of the SYSCLK so we could indirectly measure the internal frequency. We were also performing a reset when the timer check failed – this was the leading indicator that the lock to the correct frequency was not successful.

    Thanks for looking into this.

    Regards,
    Aaron
  • 0 in reply to Aaron Spaete
    TI__Mastermind 38740 points

    Hi Aaron,

    Glad to hear this was resolved.  Let me know if you still have issues or question on PLL locking.

    Thanks and regards,

    Joseph