MSPM0-SDK: SYSCONFIG does not allow VCO more than 160 MHz

A work around would be to set whatever it allows, and then go in to main() and drill down from the SYSCFG_DL_Init() function (or whatever it is called) and make manual changes to want you want. Note you have to do this everytime you change your project.syscfg file.

Hi Keith

SYSCFG_DL_Init() function regenerated on every build. Manual changes not allowed on this function. 

I can work around this problem. But it needs a lot of work and manuel synchronization between clocks. I can not use clock tree again.

I think, It is a major problem and need to be fixed.

Thanks

Note that the functions are declared weak - I think - I believe this means that you can replace it with one of the same name and the system will use that one. Like the interrupt vectors.

SYSCONFIG_WEAK void SYSCFG_DL_init(void)
{
    SYSCFG_DL_FLASH_init();
    SYSCFG_DL_initPower();
    SYSCFG_DL_GPIO_init();
    /* Module-Specific Initializations*/
    SYSCFG_DL_SYSCTL_init();
    SYSCFG_DL_TIMER_0_init();
    SYSCFG_DL_HSADC0_init();
    SYSCFG_DL_VREF_init();
    SYSCFG_DL_DMA0_init();
    /* Ensure backup structures have no valid state */
	gTIMER_0Backup.backupRdy 	= false;

}

I am not saying the problem should not be fixed, I clearly said this was a work around.

Hi Keith

Thanks for your support. I don't want workarounds. I think this problem should be fixed on the root. I actually found the problem root and fixed on my machine. But it should be fixed on MSPM0 SDK releases.

At the datasheet of MSPM0G3519 on Section 7.9.3 "System Phase Lock Loop (SYSPLL)" it clearly says f_VCO max is 400 MHz. 

After MSPM0 SDK 2.10 VCO max is reduced to 160 Mhz.

  SDK version    SYSCTLMSPM0.syscfg.js    clockTree/multiplier.js
  -------------  -----------------------  -----------------------
  2.04.00.06     400 MHz                  400 MHz
  2.05.01.00     400 MHz                  400 MHz
  2.09.00.01     400 MHz                  400 MHz
  2.10.00.04     160 MHz  <-- regression  160 MHz  <-- regression
  2.11.00.07     160 MHz                  160 MHz

I applied this fixes 

1) source/ti/driverlib/.meta/sysctl/SYSCTLMSPM0.syscfg.js  (around line 409)

    -   if(inst.SYSPLL_VCOFreq > 160000000) {
    -       validation.logError("... VCO above maximum possible value (160 MHz) ...", inst, "SYSPLL_VCOFreq_disp");
    +   if(inst.SYSPLL_VCOFreq > 400000000) {
    +       validation.logError("... VCO above maximum possible value (400 MHz) ...", inst, "SYSPLL_VCOFreq_disp");
        }

2) source/ti/clockTree/.meta/multiplier.js  (around line 22)

   Note this one is in MHz, not Hz, and has two logError calls that both need
   updating:

    -   else if(inst.PLL_QDIV_OUT > 160) {
    -       validation.logError("... VCO above maximum possible value (160 MHz) ...", inst, "PLL_QDIV_OUT");
    -       validation.logError("... VCO above maximum possible value (160 MHz) ...", system.clockTree.net_vco);
    +   else if(inst.PLL_QDIV_OUT > 400) {
    +       validation.logError("... VCO above maximum possible value (400 MHz) ...", inst, "PLL_QDIV_OUT");
    +       validation.logError("... VCO above maximum possible value (400 MHz) ...", system.clockTree.net_vco);
        }

QUESTIONS FOR TI
================

1. Was the 160 MHz limit introduced in 2.10.00.04 intentionally? If so, which
erratum or datasheet revision does it correspond to? Section 7.9.3 of the
MSPM0G3519 datasheet still specifies 80 MHz to 400 MHz for the VCO.

2. If the limit is real, is it device-specific? The current implementation
applies it to the whole MSPM0 family with no per-device branching, which
would be wrong for parts whose datasheet specifies the wider range.

3. Is there a supported way to override this without editing the SDK metadata?

Thanks

Hi Mesut,

If you want to enable SYSPLLCLK2x, then your fvco should not be over than 200MHz, this is due to the middle clock of SYSPLLCLK2x will over 400MHz under this case.

But I agree if SYSPLLCLK2x is disabled, then 200-400MHz fvco should work, I have already reported this issue to the team. This requires a fix for the  Sysconfig tool. Thanks for the report.

B.R.

Sal