CCS/TMS320F28377S: Clock frequency difference for 2 custom boards with same software

Hi Pat,

I think the issue could be with PLL configuration, and not with PLL since you are seeing 100Mhz.

Can you let me know what PLL settings are you using?

Thanks,

Nirav

Hello,

We use a 10Mhz external  oscillator which is stable.

For PLL: MULT is 80 and DIV is 2, in order to have a DSP clock to 200Mhz.

We observed a frequency unstability, switching from good frequency to half frequency.

We changed of board and problem has disapeared.

My question are:

- is this problem is typically the one observed when PLL workaround is not applied (or not correctly) ?

- why on 3 boards, 2 are executing correctly and one not, is a a functional limit ? what to expect during production ?

Hi Pat,

Did you configure IMULT as 80? If it is, then it violates the max PLLRAWCLK frequency spec of 400MHz.

PLLRAWCLK = foscclk * IMULT = 10*80 = 800MHz, this is outside the datasheet spec.

Can you please dump the CLK_CFG_REGS?

You should use IMULT=40 and SYSCLKDIV=1 (which internally is Div/2).

Regards,

Nirav

In fact we decreased IMULT until 10 and we also observed this unstability with a clock switching between two frequencies (expected one sometimes and half other one)

Sorrt but you did not answer my two previous questions:

- is this unstability exactly the result of a non application or bad application of the  PLL workaround ?

- why with the same software, 2 boards have no problem and the thirs yes ?

Thank you to explain me in details the cause and effects for my understanding.

Hi Pat,

Please find answers to your questions below:

- is this unstability exactly the result of a non application or bad application of the  PLL workaround ?

Based on the PLL configuration used i.e. IMULT=80, VCO is out of spec range, hence PLL being unstable is possible, you did mention that you had decreased the frequency and you saw the same results, we need to step by step debug this in order for me to confirm where the problem is. First we need to put the PLL configuration within valid range, and then run it on different boards to see if we still same issue.

- why with the same software, 2 boards have no problem and the thirs yes ?

If the VCO frequency is outside the spec, then instability is expected. Like I said in above point, we can debug once we put the PLL configuration in valid range.

Regards,

Nirav

Hello,

I'm actually working with Pat.

To be conforming to the Workaround of PLL initialization erratum, I use F2837xD_SysCtrl.c source file from C2000Ware.

See the following folder:

C:\ti\c2000\C2000Ware_Version\device_support\f2837xd\common\source

In F2837xD_SysCtrl.c, there are many functions and a macro.

The function InitSysPll calls SysXtalOscSel to use an external Crystal oscillator.

In C2000Ware version 2.01.00.00, the function SysXtalOscSel is the following:

In C2000Ware version 3.02.00.00, the function SysXtalOscSel is the following:

With the macro:

I do not implement the last version (3.2.00.00) of C2000Ware but the version 2.1.00.00.

With the last version, I can now modify CPU1.SYSCLK and see XCLKOUT in GPIO73 in an oscilloscope with the correct frequency and stable.

Thank for your help.

 Philippe