TMS570LS1114: PLL lock-out problem of TI chip TMS570LS1114?

1. You mentioned the technical reference manual of TMS570LS111 4, which we have read before, including 10.5.3 and 10.5.4. We have also studied and operated Recover form a PLL failure according to 10.5.4, but there are still failure problems. Because our product is a product in the field of safety function and has particularity, PLL failure is absolutely not allowed, that is to say, Recover form a PLL failure operation can not be carried out, so what is the fundamental reason why we pay more attention to this problem?

2. PLL failure means that PLL output is either too fast or too slow, and it is true that the external output frequency of CPU and the value of GLBSTAT state register are captured by FPGA. See Fig. 1 and Fig. 2. For easy observation, the frequency of CPU_eclk is divided into 9 sub-frequencies and output to the FPGA. But why is PLL output too fast or too slow?

3. Our operation of PLL is as follows:

In our program, because boot is used, a total of three times _c_int00 function is called, so PLL is configured three times, but the output frequency of three times configuration is the same, that is to say, the value of PLL configuration register is the same. The last two configurations simply re-shut down and enable the PLL, and after the third enablement, the PLL registers are no longer operated on.

The following two figures are shown in Figs. 1 and 2 above. Fig. 1 shows how fast the output frequency of the CPU is when the CPU_ECLK is detected by the FPGA. Fig. 2 shows that the output frequency of the CPU changes from 180 Mhz to 10 Mhz.

The configuration frequency of our main oscillator is 180MHZ, which is obtained from the external crystal oscillator 10MHZ through PLL frequency doubling.

Manage oscillator failure: PLL is unlocked for bypass and no other operation is performed, as shown in the red box in Figure 1; the specific configuration is shown in Figures 1, 2 and 3.

Part Number: TMS570LS1114

The PLL of TI chip TMS570LS1114 is out of lock. Please look at the product line BU for help. The first discovery of PLL lockout problem is called 1 # board, and the second discovery of PLL lockout problem is called 2 # board. The PLL is normally 180M. The external crystal oscillator acts after the PLL is unlocked, and the external crystal oscillator is 10M. The details are as follows:

1, 1# board

Problems: PLL will be out of lock after a period of normal operation (time may be several hours, days).

Fault testing and correction process:

According to the workaround of SSWF021 # problem in the SPNZ218C Corrigendum Table of TMS570ls1114, the code was modified and tested. No PLL lock failure occurred in the modified TMS570. But we burned back our original code, that is, no work around code was added, and no PLL lockout failure occurred again. Therefore, it is not possible to determine whether adding workaround code is valid.

Existing doubts:

According to the explanation of the error sheet, adding workaround is mainly to solve the problem of PLL start-up when power is on. The errors in Fig. 1 and Fig. 2 illustrate that it is not to solve the problem of PLL lock-out. We want to confirm whether SSWF021 # 45 in Corrigendum SPNZ218C can solve PLL lock-out problem? According to the previous situation, it is presumed that adding workaround code may not solve the PLL lockout problem, but the cause of PLL lockout failure is unknown. According to the error statement, once the PLL power is locked, there will be no PLL lock-out problem. Our problem is that after the PLL works normally for a period of time, there will be PLL lock-out, which is not in line with the TI instructions.

Corrigendum table SPNZ218C is the first picture, and Corrigendum table spna133a is the second picture.

2, 2# board

Existing problems: the first problem is that the board can not start, the second problem is that PLL will be out of lock.

Fault testing and correction process: Under the condition of confirming the system reset and power supply are normal, the data is not printed during boot, and it is inferred that PLL is not started. The code is modified according to the workaround of SSWF021 # in the SPNZ218C Corrigendum Table. The code of workaround is added to the first boot of power-on operation, which can be operated on power. 2 # boards can be operated on power-on. To start. However, PLL lockout still exists.

Questions: The above operation shows that the workaround code solves the problem of PLL startup, which is consistent with the error statement. The APP code of 2 # board is the same as that of 1 # board, but there is no PLL start-up problem in 1 # board. Please help to analyze the cause of this phenomenon, and PLL of 2 # board will lose lock for a period of time (several hours, several days, up to 13 days), which can not solve the PLL lock problem of 2 # board for the time being.

3.PLL Loss Lock Phenomenon and Recovery

We have also studied and operated Recover form a PLL failure according to 10.5.4, but there are still failure problems. Because our product is a product in the field of safety function and has particularity, PLL failure is absolutely not allowed, that is to say, Recover form a PLL failure operation can not be carried out, so what is the fundamental reason why we pay more attention to this problem?

3.2PLL failure means that PLL output is either too fast or too slow, and it is true that the external output frequency of CPU and the value of GLBSTAT state register are captured by FPGA. See Fig. 1 and Fig. 2. For easy observation, the frequency of CPU_eclk is divided into 9 sub-frequencies and output to the FPGA. But why is PLL output too fast or too slow?

3.3 Our operation of PLL is as follows:

In our program, because boot is used, a total of three times _c_int00 function is called, so PLL is configured three times, but the output frequency of three times configuration is the same, that is to say, the value of PLL configuration register is the same. The last two configurations simply re-shut down and enable the PLL, and after the third enablement, the PLL registers are no longer operated on.

3.4 PLL registers are configured without any further operations

The following two figures are shown in Figs. 1 and 2 above. Fig. 1 shows how fast the output frequency of the CPU is when the CPU_ECLK is detected by the FPGA. Fig. 2 shows that the output frequency of the CPU changes from 180 Mhz to 10 Mhz.

Please help to analyze the above phenomena to confirm 1. Is the work around of SSWF021 # in the Corrigendum List (SPNZ218C) helpful to PLL lock-out problem? 2. How to solve the PLL lock-out problem? What is the cause of PLL lockout failure

Previous posts were not effectively answered

Hello,

The workaround for SSWF021#45 addresses the issue where the PLL on some parts fails to start. It does not address the issue where the PLL loses lock during operation. The PLL can lose lock if an oscillator fault is detected, or if the PLL configuration is changed significantly versus the one that is being used for operation (NR, NF or ODPLL settings).

Some suggestions for further debug:

1. You can configure the debugger to halt upon a write to the PLL control register 1. This will help you identify all the places in software where the PLLCTL1 register is being written. Then you can compare the values being written to make sure that these are as expected.
2. You can use the "Clock Test Mode" to output different clock sources and domains on to the ECLK pin. Please output the HF LPO to make sure that it is around 9.6MHz (typically).
3. Enable response to an oscillator fault detected. e.g. reset on oscillator fault. Then monitor the nRST pin to see if it is asserted signaling an oscillator fault.

Regards,

Sunil

HI sunil

I read the status of GLBSTAT,  The bit0  is  oscillator fault detected, but the value I read is always zero,so I make sure it do'not appear oscillator fault ,

HI Sunil

1. PLL configuration in the system.c function configured, before entering the main function has been configured, There is no more operation of the PLL register in the main function. Next I will check the PLL register to see if there is any change.
2. I will confirm whether HF LPO is about 9.6MHZ
3. By reading the status of the GLBSTAT register, BIT0 is the fault mark of the oscillator, and BIT0 equals to 1 is not found; However, FBSLIP or RFSLIP has been equal to 1 is found
4. I will change the failure configuration of PLL.

Change the configuration from figure 1 to figure 2, and try again

                                                                                                                      figure 1

figure 2

Hello,

Do you have any update on the debug? Did you find all the writes to the PLL control registers?

Regards,

Sunil