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.

AM263P4: Should `SOC_controlModuleUnlockMMR` be called before using `SOC_rcmEnablePeripheralClock`?

Part Number: AM263P4

Tool/software:

Hi, 

In the following SDK code from `am263px/source/drivers/soc/am263px/soc.c` it appears that the SDK is not unlocking/locking the registers before enabling/disabling the the peripheral clocks.  I think its necessary b/c the MSS_RCM block is controlled with a lock register.  Can you verify?

Also, can you provide a recommendation on a synchronization mechanism so that multiple cores unlocking/locking don't result in locking out writes?  E.g. core 0 unlocks, core 1 unlocks, core 0 writes a reg A, core 0 locks, core 1 tries to write reg B (write fails) 

-Colin

int32_t SOC_moduleClockEnable(uint32_t moduleId, uint32_t enable)
{
    int32_t status = SystemP_SUCCESS;

    status = SOC_rcmEnablePeripheralClock((SOC_RcmPeripheralId)moduleId, enable);

    return status;
}

int32_t SOC_moduleSetClockFrequency(uint32_t moduleId, uint32_t clkId, uint64_t clkRate)
{
    int32_t status = SystemP_SUCCESS;

    SOC_controlModuleUnlockMMR(0, MSS_RCM_PARTITION0);

    status = SOC_rcmSetPeripheralClock((SOC_RcmPeripheralId)moduleId, (SOC_RcmPeripheralClockSource)clkId, (uint32_t)clkRate);

	SOC_controlModuleLockMMR(0, MSS_RCM_PARTITION0);

    return status;
}

  • Hi Colin,

    I have received your query. I will check this with the team and get back to you with an update by Monday. Thanks for your patience.

    Best Regards,
    Aswathi

  • Hi Colin,

    Sorry for the delay in response.

    In the following SDK code from `am263px/source/drivers/soc/am263px/soc.c` it appears that the SDK is not unlocking/locking the registers before enabling/disabling the the peripheral clocks.  I think its necessary b/c the MSS_RCM block is controlled with a lock register.  Can you verify?

    Yes, this is a miss in the SDK. I've add an internal bug to get this fixed. 

    This was not caught because the values being written was the default value. 

    Also, can you provide a recommendation on a synchronization mechanism so that multiple cores unlocking/locking don't result in locking out writes?  E.g. core 0 unlocks, core 1 unlocks, core 0 writes a reg A, core 0 locks, core 1 tries to write reg B (write fails) 

    Typically, the control registers (i.e. the ones that require locking/unlocking) such as clock configuration, pll configuration, pinmux configuration etc are controlled by one core in order to avoid this issue.

    Do you have a usecase for any specific register in MSS or TOP CTRL or RCM that you would be setting from multiple cores?

    Thanks and Regards,

    Nikhil Dasan

  • Nikhil,

    Thanks!  We can address it in our code as well.

    Regarding the control registers synchronization.  One example is when we are disabling / enabling the CLKSYNC bit in EPWM_CLKSYNC.

    We combine different functionalities (sometimes written by different teams) into different cores.  So its easier if each core is responsible for initializing their own clocks.

    -Colin

  • Understood. 

    From the HW perspective, there is no way to synchronize the lock/unlock between multiple cores. You could use Spinlock to achieve this synchronization.

    Thanks and Regards,

    Nikhil Dasan