TMS320F280049: Clock and PLL Dysfunction Leading to DSP Functional Failer

I don't know if this issue is caused by this errata

But it's no use if we do some changes based on this workaround

Hello,

Many combinations of multiplier and divider can produce the same output frequency. However, the product of the reference clock frequency and the multiplier (known as the VCO frequency) must be in the range specified in the TMS320F28004x Real-Time Microcontrollers Data Sheet, 7.9.3.2.2 Internal Clock Frequencies

There could be multiple things giving an issue. To debug, I suggest following the Example-1: Validating PLLRAWCLK frequency from TRM, page 899: https://www.ti.com/lit/ug/sprui33h/sprui33h.pdf

Hi Stevan

Stevan Duraskovic said:

Many combinations of multiplier and divider can produce the same output frequency. However, the product of the reference clock frequency and the multiplier (known as the VCO frequency) must be in the range specified in the TMS320F28004x Real-Time Microcontrollers Data Sheet, 7.9.3.2.2 Internal Clock Frequencies

First, the PLL failure issue occurred in customer's mass-produced products. Only one sample out of 100 exhibited the PLL failure phenomenon, and the issue persisted after re-energizing the MCU or re-flashing the program into the MCU. Secondly, based on the register configuration during debugging, it is confirmed that the clock frequency is within the range specified in "TMS320F28004x Real-Time Microcontrollers Data Sheet, 7.9.3.2.2 Internal Clock Frequencies."

Stevan Duraskovic said:

There could be multiple things giving an issue. To debug, I suggest following the Example-1: Validating PLLRAWCLK frequency from TRM, page 899: https://www.ti.com/lit/ug/sprui33h/sprui33h.pdf

The clock source configured for our module is the internal clock INTOSC2 (visible from the register configuration during debugging). Following the above suggestions, we entered debug mode and added a breakpoint at the end of the SysCtl_isPLLValid() function, where we can observe the relevant register values when DCC succeeds and fails:
Normal module:

Abnormal module:

Cause this issue is pending for a long time, please help give some advice ASAP, thanks in advance.

Best regards

Ethan

Hello,

To debug further, you could run DCC (Dual-clock Comparator) examples in C2000ware based on your application, they are also mentioned in TRM: 6.4.1.1 DCC Single shot Clock verification and so on. 

When it comes error conditions, they are generated by any of the following:

1. Counter1 counts down to 0 before Counter0 reaches 0. This means that Clock1 is faster than expected, or Clock0 is slower than expected. This error includes the case when Clock0 is stuck at 1 or 0.

2. Counter1 does not reach 0 even when Counter0 and Valid0 have both reached 0. This means that Clock1 is slower than expected. This error includes the case when Clock1 is stuck at 1 or 0.

Any error freezes the counters from counting. An application can then read out the counter values to help determine what caused the error.

Hi Stevan

In fact, the count values of Counter0 and Counter1 in the case of PLL failure have been intercepted from the previous reply. It's just that customer is using their own project. Now the customer directly uses the original routine of C2000ware for testing, and hopes that BU can carry out in-depth testing on the samples.

Following your suggestions, we imported the original project "C:\ti\c2000\C2000Ware_3_04_00_00\driverlib\f28004x\examples\can\can_ex3_external_transmit" from C2000Ware_3_04_00_00 for testing. Since our module uses an internal clock, we modified the clock configuration as follows:
In the file device.h:
Original configuration:

#define DEVICE_SETCLOCK_CFG         (SYSCTL_OSCSRC_XTAL | SYSCTL_IMULT(10) |  \

                                     SYSCTL_FMULT_NONE | SYSCTL_SYSDIV(2) |   \

                                     SYSCTL_PLL_ENABLE)

Modified to:

#define DEVICE_SETCLOCK_CFG         (SYSCTL_OSCSRC_OSC1 | SYSCTL_IMULT(20) |  \

                                     SYSCTL_FMULT_NONE | SYSCTL_SYSDIV(2) |   \

                                     SYSCTL_PLL_ENABLE)

In Debug mode, we added a breakpoint at the end of the SysCtl_isPLLValid() function to observe relevant register values when DCC succeeds or fails.
Test results:

For normal samples, Counter1 and Counter0 count down to 0 simultaneously, and Dcc0Regs.DCCSTATUS.DONE = 1;

For abnormal samples, Counter1 counts down to 0 before Counter0, and Dcc0Regs.DCCSTATUS.ERR = 1;

Hello Ethan,

I have not suggested importing CAN project from C2000Ware, but DCC example. TRM describes the examples and suggests debug mechanisms. Please refer to the device TRM DCC chapter.

Hi Stevan

From my tests, the clock initialization of all routines in "C:\ti\c2000\C2000Ware_3_04_00_00\driverlib\f28004x\examples" will perform DCC calibration, whether for CAN, PWM, timer, etc. We installed C2000Ware 5.04 as per your suggestion and tested it using DCC examples. The test results are as follows:

Similarly, we used the internal clock and entered Debug mode. A breakpoint was added at the end of the SysCtl_isPLLValid() function, where we could observe the relevant register values when DCC calibration succeeded or failed.

Test Results:
For normal samples, both Counter1 and Counter0 counts reached 0 simultaneously, and Dcc0Regs.DCCSTATUS.DONE = 1.

For abnormal samples, Counter1 reached 0 before Counter0, and Dcc0Regs.DCCSTATUS.ERR = 1.

I believe no further tests can be conducted locally. The issue is chip-dependent, occurring with a probability of 1%. It can be easily reproduced on problematic chips. I'm not sure if this is related to the PLL locking failure mentioned in the errata of 280049, but please provide a clear response and a workaround.

Hello,

Adding more PLL experts so they give their insight.