AM2634-Q1: [MCAL]stable PLL value in MCAL

Their PLL values are as below.

Thanks and Best Regards,

SI.

Hi SI,

Does it mean it is working at lower temperatures? Which SBL api is used to configure PLL? 

Thanks And Regards,

Sunil

Hi Sunil,

Yes. there is no issue at lower temperatures.  

Thanks and Best Regards,

SI.

Hi Sunil,

I compared between SBL and MCU_init of MCAL for PLL setting and found only 'soft reset PLL' was deleted in MCU+SDK SBL.

Could you please check if below 'soft reset PLL' should be deleted or not?

In MCU+SDK v8.6.0 and v9.1.0, 'soft reset pll' was deleted as below in SBL.

Thanks and Best Regards,

SI.

Hi SI,

I will check this and get back to you. Meanwhile you also mentioned via email that after they call GetCounter Api the register values are changed?Ideally that should not be the case?Can you confirm? Also can you please share the implementation of GetCounter Api?

BR,

Sunil

Hi Sunil,

Before calling GetCounter() API, they found the register values were changed. 

e.g. when jump to GetCounter() API calling, customer found the PLL values were broken and changed to wrong values.

They tested again by removing 'Soft reset pll' line in above, they found they can pass this region and loaded application successfully, but failed to start CAN communication as below. The CAN communication also failed at room temperature test.

e.g. when they removed 'Soft Reset PLL' line in above, they can succeed booting at both low & high temperature test, but booting time was to be longer than before and they can not start CAN communication.

So, I'm worrying it is needed to have more time after 'Soft reset pll' and would like to request if there is any debug/change history in SBL for this.

Thanks and Best Regards,

SI.

Sunil,

Unfortunately there was no improvement when adding timing after 'soft reset pll' as below. When they added 'wait loop' after 'soft reset pll' as below, they still faced boot fail issue and the code was stuck at the same point.

Please let me know if you have any idea on this.

Thanks and Best Regards,

SI.

Hi Sunil,

This solution works!

Could you please clarify what should be modified? Could you please release patch for this?

When I checked Mcu_Platform.c(Mcu_Priv.c) file, there are 2  Mcu_ClockSetSourceSYSCLK(); called. should all these removed?

Should '(void)regWriteReadback(&toprcmREG->PLL_PER_FRACDIV, M_THIRTY_ONE, M_TWENTY_FOUR, pllClk2.sdDiv); /* sigma Delta divider */' be removed? When I checked SBL, I found similar function still existed in SBL as below. So, I would like to have double check with you..

Please check and clarify this.

Thanks and Best Regards,

SI.

Hi SI,

Can you please let us know which 1 of these suggestion worked?

BR,

Sunil

Hi Sunil,

They applied all of 1,2,3 items you suggested as below.

For below suggestion, 

1. Can you comment Mcu_ClockSetSourceSYSCLK()?
2. Can you comment below line from Per PLL? I do not see SDK setting it.
   (void)regWriteReadback(&toprcmREG->PLL_PER_FRACDIV, M_THIRTY_ONE, M_TWENTY_FOUR, pllClk2.sdDiv); /* sigma Delta divider */

They comment as below,

For below suggstion,

3. In do-while loop waiting for PLL to be modified like below as there is a bug.

They modified their code as below.

difference:

modified:

Thanks and Best Regards,

SI.

Hi SI,

Can they modify only 2nd suggestion and revert 1 and 3 and see if this issue still exists?1 and 3 are minor changes and I feel should not affect much.

I do not think all the 3 suggestions causing this issue. Wanted to narrow down to 1 issue.

BR,

Sunil

Hi Sunil,

I'm sorry. It is hard to request it before providing details because it may be our issue and it can be reproduced in our EVM as well. To request this, we need to provide more details for each item to explain why this test need to be required. Please understand this situation.

And also, for item2, do you mean PER PLL setting - sigma delta divider?

As I mentioned in above, it seems there is same setting in SBL as below.

In \\mcu_plus_sdk_am263x_08_06_00_34\source\drivers\soc\am263x\soc_rcm.c

So, I think item 1 - Mcu_ClockSetSourceSYSCLK() - would be more possible thing causing this issue. I could not find similar code in SBL.

Or could you please check this issue in your side  using AM263 EVM? I think you can easily reproducing this issue by using heat gun. When you warm device using heat gun with 100C setting in heat gun and doing on/off test over 5 min, you can find this issue easily.

Please check this and release patch.

Thanks and Best Regards,

SI.

Hi SI,

I understand that, please note that I do not have setup to reproduce, that's why I suggested. I completely understand and apologies for that.

Regarding item 2, I was mentioning in this API SOC_rcmProgPllPerDivider. PerPll divider and not Corepll

Item 3 is a bug and the solution I have provided is correct.

I need some time to get this setup and check. We are working on another release this week and will have a vacation next week. I will check this on Jan 1st week and revert back to you.

BR,

Sunil Kumar M S

Sunil,

Thanks for your understanding and letting me your status.

Jan 1st week should OK and please let me know if you find some clues in Jan 1st week.

They should get our patch before Jan/15.

Thanks and Best Regards,

SI.