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.

PROCESSOR-SDK-AM65X: Sciclient_pmGetModuleClkFreq() fails to modify clock frequency unless PLL registers are manually unlocked

Part Number: PROCESSOR-SDK-AM65X

Dear TI team,

we're trying to change the frequency of our OSPI reference clock within our application (still using SDK 06.03).

   retval = Sciclient_pmSetModuleClkFreq(248U, 0U, ospiRecClk, TISCI_MSG_FLAG_CLOCK_ALLOW_FREQ_CHANGE, SCICLIENT_SERVICE_WAIT_FOREVER);

   retval = Sciclient_pmGetModuleClkFreq(248U, 0U, &ospiFunClk, SCICLIENT_SERVICE_WAIT_FOREVER);

The Sciclient returns "success" but is still returning the previous frequency when we query the clock.

We found out that changing the clock works if we first manually unlock the PLL registers by writing to the kick/lock registers:

   *(volatile uint32_t *) (CSL_MCU_PLL0_CFG_BASE + CSL_MCU_PLL_MMR_CFG_PLL0_KICK0) = KICK0_UNLOCK_VAL;
   *(volatile uint32_t *) (CSL_MCU_PLL0_CFG_BASE + CSL_MCU_PLL_MMR_CFG_PLL0_KICK1) = KICK1_UNLOCK_VAL;

It seems that the Sciclient doesn't unlock the PLL registers.

  • I guess it is not intentional that this works only if I unlock the PLL registers first?
  • has this been fixed in the newer SDK 7.0? I haven't found a reference to this issue in the release notes.
  • What is the intended way to modify clocks?

Regards,

Dominic

  • It seems that the issue still exists in SDK 7.0.

    The DMSC tries to write to the MCU_PLL0_HSDIV_CLKDIV register at 40D00120h (mapped via RAT as A0D00120h), but the MCU_PLL0 registers are still locked (MCU_PLL0_KICK0 reads 0x0, i.e. bit[0] cleared, which means locked). I've verified that the Sciclient actually tries to write a new value to MCU_PLL0_HSDIV_CLKDIV using a hardware watchpoint. A different watchpoint set on the kick/lock register didn't trigger.

    If I manually unlock the registers, then call Sciclient_pmSetModuleClkFreq, the frequency gets changed just fine.

    Is this a bug in the DMSC firmware?

    Is there some other call to Sciclient_* that should be performed prior to trying to change the frequency?


    Regards,

    Dominic

  • Thanks Dominic. This does not reflect intended behavior and we'll investigate the SYSFW and SciClient.

    Best regards,

    Dave

  • Dave,

    Dominic posted a new thread: https://e2e.ti.com/support/processors/f/791/t/949793. I requested him to continue discussion on this thread instead.

    Here is the post from Dominic:

    Unfortunately my old thread https://e2e.ti.com/support/processors/f/791/p/929205/3435392 has been locked.

    Is there any update on this issue? Can we expect this to be fixed in the upcoming SDK 07.01.?

    Regards,

    Dominic

  • Dominic,

    I suspect this is due to the default PLL and clock configurations and how they are set in the board_init function. For the AM65 please refer the function Board_PLLInitAll in pdk_jacinto_07_00_00\packages\ti\board\src\evmKeystone3\board_pll.c. Most initialization will occur through the system firmware via TISCI call, though there are three which still leverage pllcConfigs[] via the Board_PLLConfig() function:

    >>>
    Board_PLLConfig(&pllcConfigs[CSL_PER0_PLL]);
    Board_PLLConfig(&pllcConfigs[CSL_MCU_PLL]);
    Board_PLLConfig(&pllcConfigs[CSL_CPSW_PLL]);
    <<<
    These refer to the pllcConfigs[] defined in pdk_jacinto_07_00_00\packages\ti\board\src\am65xx_evm\am65xx_evm_pll.c and pdk_jacinto_07_00_00\packages\ti\board\src\am65xx_idk\am65xx_idk_pll.c

    So being done outside of the system firmware it is not aware of the lock. I have a request filed with the team on the initial clock configuration. This will not be updated for 7.1 but will add your observations, and note for future.

    But for now, stick to the explicit unlock.


    Best regards,
    Dave