This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSPM0G3507: SYSPLL sporadically wrong output frequency

Part Number: MSPM0G3507
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hello all,

we use the internal SYSOSC and the SYSPLL to generate 80MHz for MCLK and CPUCLK:

DL_SYSCTL_SYSPLLConfig gSYSPLLConfig;

  gSYSPLLConfig.rDivClk2x = 1;
  gSYSPLLConfig.rDivClk1 = 0;
  gSYSPLLConfig.rDivClk0 = 0;
  gSYSPLLConfig.enableCLK2x = DL_SYSCTL_SYSPLL_CLK2X_ENABLE;
  gSYSPLLConfig.enableCLK1 = DL_SYSCTL_SYSPLL_CLK1_DISABLE;
  gSYSPLLConfig.enableCLK0 = DL_SYSCTL_SYSPLL_CLK0_DISABLE;
  gSYSPLLConfig.sysPLLMCLK = DL_SYSCTL_SYSPLL_MCLK_CLK2X;
  gSYSPLLConfig.sysPLLRef = DL_SYSCTL_SYSPLL_REF_SYSOSC;
  gSYSPLLConfig.qDiv = 4;
  gSYSPLLConfig.pDiv = DL_SYSCTL_SYSPLL_PDIV_2;
  gSYSPLLConfig.inputFreq = DL_SYSCTL_SYSPLL_INPUT_FREQ_16_32_MHZ;

  /* SYSOSC / PDIV * QDIV = 32MHz / 2 * 5 = 80MHz */
  DL_SYSCTL_configSYSPLL((DL_SYSCTL_SYSPLLConfig *)&gSYSPLLConfig);

  DL_SYSCTL_setULPCLKDivider(DL_SYSCTL_ULPCLK_DIV_2);

  DL_SYSCTL_switchMCLKfromSYSOSCtoHSCLK(DL_SYSCTL_HSCLK_SOURCE_SYSPLL);

  // With MCLK=80MHz 2 flash wait states are required
  // For details see datasheet section 7.3 Recommended Operating Conditions
  DL_SYSCTL_setFlashWaitState(DL_SYSCTL_FLASH_WAIT_STATE_2);

  while ((DL_SYSCTL_getClockStatus() & DL_SYSCTL_CLK_STATUS_SYSPLL_GOOD) !=
         DL_SYSCTL_CLK_STATUS_SYSPLL_GOOD) {
    ;
  }

This works approximately 9 out 10 power-ups fine, but one time the PLL output frequency seems to be wrong for the whole operation cycle. In the faulty cases I measured 72.8MHz or 39.5MHz instead of the expected 80Mhz. I tested on two different hardwares and failure occurs on both (with different faulty frequencies though).

With above configuration VCO frequency is 80Mhz (valid range according to data sheet 60...400MHz) and SYSPLLCLK2X output frequency also 80MHz (valid range according to data sheet 4...800MHz). In my opinion this is a valid configuration, also the TI tool SysConfig does not show any warnings or errors and I saw that these values are used as example in the RM.

However, I noticed that with a following different PLL configuration the issue seems not occurring:

  gSYSPLLConfig.rDivClk2x = 3;
  gSYSPLLConfig.qDiv = 9;

With qDIV = x10 VCO frequency is 160MHz and CLK2X_DIV = 4, the PLL output frequency is 80MHz as in above configuration. I tested 250 power-up cycles without any wrong frequency.

Currently we use MSPM0 SDK 1.20.1.6 (I did not notice relevant changes in sysctl in SDK version 2.00.01.00).

Do you see an issue with the used initialization sequence of the clock configuration?

Is there a known issue in the driver lib?

If not, could you please try to reproduce this issue?

Thank you in advance!

Best regards,

Holger

  • Hi, 

    We recommend setting the VCO to 160MHz, which is trimmed in factory.

    Other frequencies will cause frequency inaccuracy.

    Regards,

    Helic

  • Hello Helic,

    thank you for your reply.

    It is a bit surprising that a VCO frequency of 80MHz shall lead to the observed behavior when this value is suggested for the initialization sequence in the reference manual in chapter "2.3.1.3.1 Configuring SYSPLL Output Frequencies" and it is well within the allowed VCO frequency range in the data sheet of 60MHz to 400MHz.

    For me, the observed behavior is not just an inaccuracy when the observed frequency is less than half of the expected frequency.

    We are considering this MCU for series production, but have serious doubts that using VCO of 160MHz will completely solve the issue when 80MHz is in the range which is specified by TI.

    Please give us more insight how VCO of 80MHz can cause this issue and why you are sure that 160MHz will solve it.

    Does it mean that the DS and RM will be corrected in this regard?

    Thank you in advance.

    Best regards,

    Holger

  • Hi,

    There is no problem with 160MHz, and other frequencies have not been trimmed.

    We will consider to change TRM SYSPLL Usage Example to 160MHz.

    Regards,

    Helic