TMS320F280041-Q1: Questions about PLL errata and its workaround

Will,

                I am unable to understand exactly what the issue is. It is important to distinguish the issue between a crystal oscillator problem and the PLL errata problem. In other words, is the customer having a crystal oscillator startup problem or the PLL errata?

Will Gao said:

They tested the RST pin and crystal pin waveform, and found that after several reset cycle then the crystal oscillator start to oscillation.

Why does it take "several" reset cycles for the crystal oscillator to start oscillation? The PLL erratum does not impact the crystal oscillator startup in any way.

Will Gao said:

but also when retry times (100 times) is reach, they will start the watchdog and reset the device. 

Are you saying sometimes it takes over 100 times for the PLL to lock?

Will Gao said:

1. what is the truly root cause for the errata- PLL May Not Lock on the First Lock Attempt?

PLL is an extremely complex analog peripheral. Unless someone is well versed with the theory of operation of PLLs, it would be hard to understand the root-cause. Regardless, we will not disclose/discuss design details outside of TI. 

Will Gao said:

2. why the device could recover from this errata after resetting itself several times?

That is due to the nature of the bug.

Will Gao said:

Can they add the retry times to recover?

First you need to determine whether this is a crystal oscillator startup issue or PLL lock issue. You are talking about both which is very confusing.

Will,

    Please have customer run a simple example that does not configure the PLL. It could be a very simple example like toggling GPIO pin, but the code should run off the crystal oscillator. Run this example multiple times. To take this debug forward, we need to absolutely isolate the issue to XTAL oscillator or PLL. Also let us know if there is any temperature dependency to the problem. 

Hi Hareesh, 

Thanks so much for the guidance.

Customer identified this issue is related to PLL but not the XTAL oscillator by using internal oscillator to do the similar tests and similar problem happened. 

Furthermore, they add the value of the macro of retry times, and found that the device will not reset again and response the monitor more quickly, which means the F280041's PLL can be locked by retrying more than 100 times. 

So there are 2 questions: 

1. How BU defines the PLL_RETRIES? Why default 100? Can customer define it to a larger value, like 5000, 10000, etc. 

2. Customer not request me to provide the root cause for PLL errata anymore, but they want to know the possibility for this errata. Do we have this kind of data? 

Regards, 

Will 

Will,

              Good to know the crystal oscillator is not issue, so we can focus on the PLL.

Will Gao said:

1. How BU defines the PLL_RETRIES? Why default 100? Can customer define it to a larger value, like 5000, 10000, etc. 

This was determined by analyzing the root-cause and also with empirical data. What is the number of retries needed as determined by the customer?

Will Gao said:

2. Customer not request me to provide the root cause for PLL errata anymore, but they want to know the possibility for this errata. Do we have this kind of data? 

It is in the very low PPM range. Please take a look at:

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1240884/tms320f28375s-errata---pll-may-not-lock-on-the-first-lock-attempt 

Hi Hareesh, 

They modified to 5000. But actual retry times number is not determined. 

Hareesh Janakiraman said:

This was determined by analyzing the root-cause and also with empirical data.

Could you please share me more details and the retry times number distribution? What is the coverage for 100 times? 

Regards, 

Will 

Will,

             I see that you have sent an email to the team. Let us continue the discussion there.