AM2634: Dpl_init() Fails To Set Clock Source On First Execution

Kier

Part Number: AM2634
Other Parts Discussed in Thread: SYSCONFIG

Hello,

I have a four core project in DevBoot mode. Each core uses RTI0 to RTI3 respectively for its OS ticker. Sometimes on first execution after power up, the code in Dpl_init() fails to set to clock source. This often occurs Core2 (RTI2) but sometimes Core3 (RTI3).

In other words, it does not change the value of MSS_RCM_RTI2_CLK_SRC_SEL from 0x222* to 0.

If I do a Reset, Restart, Resume, the problem does not occur. However, the first execution after power-up is the the most important so this must be made to work every time.

1) *The reset value of MSS_RCM_RTIx_CLK_SRC_SEL is 0x0 according to the register addendum however something sets the value to 0x222 before main(). Am I right in saying it is the RBL setting the value to 0x222?

2) What could be the reason that line 252 is ineffective on first execution?

3) If the cause is that the code cannot unlock the register, what could cause the unlock to fail?

Thank you.

over 1 year ago

0 Aakash Kedia over 1 year ago

TI__Mastermind 26145 points

Hi Kier,

Let me check on this and come back. I think this is because the MSS_RCM requires unlocking before changing the values. I suspect there is a race condition in your setup.

Try commenting out the code in SOC_controlModuleLockMMR, rebuild the library and test -

Do let me know if this works.

Best Regards,
Aakash

0 Kier over 1 year ago in reply to Aakash Kedia

Mastermind 9470 points

Many thanks Aakash.

In the time since I raised the question, I came to the same conclusion: There is a race condition between cores to unlock and lock the SOC common MSS_RCM registers.

Sometimes CoreA unlocks the MMR, but before it can write to its allocated RTI clock source register, Core B locks it again.

My approach was to comment out the call to SOC_controlModuleLockMMR() in the clock_init.c.xdt template and regenerate the code. The problem then goes away.

I only noticed this problem because of an obvious difference in pin toggling frequencies controlled by separate cores. There could be other less obvious MMR protection race conditions that go unnoticed.

So how will you implement a permanent solution? In my application I will solve it by staggering the call to System_init() using a software spinlock mechanism such that each core must wait its turn to call System_init() -> Dpl_Init().

However, I think TI needs to think how to solve this in SYSCONFIG generated code.

By the way please can you answer Q1?

0 Aakash Kedia over 1 year ago in reply to Kier

TI__Mastermind 26145 points

Hi Kier,

We are also analyzing the spinlock and IPC based mechanism to solve this. We are tracking this for 10.00 release but due to complexity in testing we may officially support it even later.

Kier said:
1) *The reset value of MSS_RCM_RTIx_CLK_SRC_SEL is 0x0 according to the register addendum however something sets the value to 0x222 before main(). Am I right in saying it is the RBL setting the value to 0x222?

RBL does not configure this. Maybe GEL script or the SBL Null or SBL QSPI is doing the same.

Best Regards,
Aakash

0 Kier over 1 year ago in reply to Aakash Kedia

Mastermind 9470 points

Hi Aakash,

Aakash Kedia said:
We are also analyzing the spinlock and IPC based mechanism to solve this.

Thank you. Yes, my colleague is looing into a similar solution. Good to know we may be on the right track. My colleague's thread: AM2634: Spinlock Lock Register is presumably read by two cores simultaneously - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

Aakash Kedia said:
Maybe GEL script or the SBL Null or SBL QSPI is doing the same.

You're right. I looked again and found the GEL function Program_RTIx_Clocks() sets these registers.