MSPM0G3507-Q1: Unstable Clock -->> PLL Problems?

Part Number: MSPM0G3507-Q1

Tool/software:

Hello,

we have integrated the MSPM0G3507-Q1 for a custom design. We added a 24 MHz external Crystal (load capacitance 8 pF --> we use 12 pF capacitance on XTAL). We verified the crystal with the scope and its in the specified tolerance range.

We got some samples and flashed these with our SW. Our SW creates a simple PWM Timer with a clock of 5 MHz. If the PCB gets hotter then the clock gets more instable (PLL active), the timer clock fluctuates around some khz and thats not in the tolerance range.

Originally Clock tree configuration

I made some tests and I used a simple example GPIO_toggle_output and modfified this. I just modified the Clock tree and added a pwm timer with 5 MHz, no gpio pins are toggling.

The aim was to identifiy the origin of the instability, I made 4 tries:

First try:

Only usage of internal Clock SOSC with this Clock tree configuration

--> 4 MHz clock output stable

Second try:

Only usage of internal Clock SOSC with PLL active

-->4 MHz clock ist not stable when PLL is active--> It's probably due to the PLL

Third try:

External 24 MHz Crystal without PLL--> 4MHz clock output stable

Fourth Try:

External 24 MHz Crystal with PLL (original clock tree)--> 5MHz clock outptut not stable

Picture from scope (std deviation >6 kHz increases until 30 kHz)

If i reduce enlarge the clk2x_Div from 6 to 8 --> CPU_CLK has 

60 MHz instead of 80 MHz --> output clock of timer (5 MHz) is also stable!

scope picture (std deviation <200 Hz)

So it seems that there is a problem with PLL configuration. 

In SYSCTL "Enable Check for Clock Stabilization" is always on. We use CCS 20.0 but it doesn't matter which version we use. We have also samples where we have no problems with the 80 MHz output PLL configuration.

We are not sure if some of our MCUs has a temperature problem, a soldering problem is not visible. Sometimes we change the IC and then it works with the original configuration. Is there any known problem with PLL config or clock config or timer config, which can cause a unstable clock with a temperature increase (any prescaling settings or something else)?

  • I check datasheet SYSPLL section, there is no temperature related spec.

    Could you please share me the amount of PCB that you have test?

    We got some samples and flashed these with our SW. Our SW creates a simple PWM Timer with a clock of 5 MHz. If the PCB gets hotter then the clock gets more instable (PLL active), the timer clock fluctuates around some khz and thats not in the tolerance range.

    What's the temperature you have test? Just 50C or increase to 80C or 120C?

    It seems there are 0.1% error.

    ----------------------------------------

    Could you please help me test these condition?

    Since HFXT 24MHz can not use SYSPLL0 to generate 80MHz for CPU, we can try to use SYSOSC.

    1. SYSOSC 32MHz -> PDIV /4 -> QDIV *20 -> VCO 160MHz -> CLK0_DIV /2 -> SYSPLL0 80MHz -> CPU

    2. SYSOSC 32MHz -> PDIV /4 -> QDIV *20 -> VCO 160MHz -> CLK0_DIV /4 -> SYSPLL0 40MHz -> CPU

    1 and 2 is to check whether this is related to SYSPLL0 and SYSPLL2X, or it's related to 80MHz or not 80MHz.

    Want to check your use case, do you need CPU 80MHz?

  • We have tested approximately 20 PCBs with the same software, and in about 30% of them, the generated timer clock is unstable. We would rule out a manufacturing problem for the time being.

    I made your suggested tests and i did not saw a difference between SYSPLL0 an SYSPLL2X. If I reduce the CPU Clock to 40 MHz the deviation is a bit better.

    I have created a very simple piece of software that only initialises a timer and generates a 2.66 MHz clock. I am using the external crystal, and measured the frequency of it which appears to be very stable.
    The behaviour is not always the same. Sometimes the clock frequency is very unstable, up to 10 kHz deviation, and sometimes it is a few hundred hertz. It seems to me that sometimes the initialisation of the PLL does not work, which causes the deviation. Is there any SDK version or CCS version where the driver library has changed and such behaviour can occur? I use MSPM SDK Version 2.5.1 and CCS 20.0 and I also used it with SDK version 2.3.7. I had the same problem.