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.

TMS570LS1114: PLL fault of TMS570LS1114CZWTQQ1

Part Number: TMS570LS1114

Hi Sunil,

   Thanks for your great support for my PLL fault of TMS570LS1114CZWTQQ1 as below link:

e2e.ti.com/.../736020

   

     We modified and tested the code according to the workaround of the SSWF021#45 problem in the TMS570ls1114 errata (SPNZ218C). The modified TMS570 did not have any more problems, but we still have doubts about the cause of the problem. We want to know why. The processing in the workaround can avoid the problems we have? In other words, what is the root cause of our problem?

Details are as follows:

In our program, since the boot is used, the _c_int00 function is called three times, so the PLL is configured three times, but the output frequency of the three configurations is the same, that is, the PLL configuration register values ​​are the same, and the last two configurations are only Equivalent to re-shutdown and enable the PLL;

We try the following:
Increase the workaround code when calling the _c_int00 function for the third time, and the fault does not happen again;
Change the configuration PLL 3 times to one time, and the fault will still occur;
Change the configuration PLL 3 times to increase the workaround code, and the fault does not happen again;

Therefore, it can be judged that the workaround code can avoid the problems we encountered, but in the debugging of the workaround code, it has not found that the PLL loses lock and thus locks multiple times.

In addition, it is mentioned in the errata and workaround document (spna233a) that the PLL only needs to lock once during power-on, and then there will be no loss of lock (as shown below), and our problem occurs in the PLL. After working for a while, this is also inconsistent with TI's description.

  • Hi Martin,

    The root cause is that a bug in the design of the PLL(s) could cause the PLL to not start-up / acquire lock within the allotted time. The software workaround significantly increases the probability of the PLL starting correctly. Also, increasing the number of retries allowed in the workaround also affects the chances of the PLL starting correctly, with a minimum of 5 retries suggested in the documentation.

    The workaround code configures the PLL control registers, enables the PLL, waits for it to acquire lock, measures the frequency if the PLL output becomes valid, and then disables the PLL. If the PLL was unable to start-up correctly, this process is retries a minimum of 5 times.

    Do let me know if you have any other question that I may have missed answering.

    Regards,
    Sunil