TMDSIDK437X: AM437x - spurious RTC operation when using internal clock source

Hi David,

You can use the RTC compensation capability to compensate the clock drift. Please refer to this thread.

Regards,

Jianzhong

Hi Jianzhong,

Many thanks for your response.

I have read the thread that you have linked to - it appears that I'm experiencing the identical issue as the author of the linked thread when using the internal clock source (derived from the Peripheral PLL). The error we are observing is huge - the RTC is losing in the order of 4 minutes per hour. I believe the magnitude of this error is in excess of what the compensation capability can remove. I have confirmed that the Peripheral PLL is set-up correctly as I have measured the derived 192MHz via the CLKOUT2 pin.

Using an external crystal is not an option for us (as we do not have the site on our board) - so we need to source the RTC clock from the Peripheral PLL.

Kind regards,

David

Hi David,

This error is indeed very large (about 66667 PPM). That seems to me indicating configuration error in peripheral PLL. Let me loop in our HW expert for help. 

Meanwhile, I quote here the HW expert's comment from the reference thread:

"The Peripheral PLL must be configured to produce a 192 MHz clock for the internal clock signal named PER_CLKOUTM2. For example, if they configured the Peripheral PLL to use a 26 MHz reference, but actually connected a 24 MHz crystal, the error would be about 76923 PPM."

Meanwhile, please examine your peripheral PLL configuration.

Thanks for your patience.

Jianzhong

Hi Jianzhong,

Many thanks for continued assistance with this query.

Using the IDK, the peripheral PLL is configured via GEL for a CLKIN of 24MHz:

ARM_OPP100_Config(int EVM)
{
UWORD32 CLKIN;
CLKIN = GetInputClockFrequency();
if(CLKIN==24)  
{
	GEL_TextOut("****  AM43xx OPP100 with CLKIN=24MHz is in progress ......... \n");
	MPU_PLL_Config(  CLKIN, 0, 25, 1);	//600MHz
	CORE_PLL_Config( CLKIN, 2, 125, 10, 8, 4); //L3=200MHz
	PER_PLL_Config(  CLKIN, 9, 400, 5);
	EXT_PLL_Config(  CLKIN, 9, 375, 18);  //50MHz output
	DISP_PLL_Config( CLKIN, 1, 50, 6);  //example, 100MHz CLKOUT

This gives the peripheral PLL CLKOUT = [400/(9 + 1)] * 24MHz * [1/5] = 192MHz

Using our custom board, the peripheral PLL is configured via bootloader (modification of PDK starterware bootloader) for a CLKIN of 25MHz:

    // Per
    uint32_t perDpllDiv = 9U;
    uint32_t perDpllMult = 384U;
    uint32_t perSigmaDelatDiv = 4U;
    uint32_t perDpllPostDivM2 = 5U;
    SblPlatformPllPerInit(perDpllMult, perDpllDiv, perSigmaDelatDiv, perDpllPostDivM2);

This gives the peripheral PLL CLKOUT = [384/(9 + 1)] * 25MHz * [1/5] = 192MHz

I have verified the configuration of the peripheral PLL at run-time by examining the value of register CM_WKUP.PRCM_CM_CLKSEL_DPLL_PER (0x44DF2800 + 0x5EC) which returns a value of 0x04018009 (which is as expected).

Further, I have measured the output of the peripheral PLL using an oscilloscope connected to the CLKOUT2 pin on our custom board and verified that the clock output is exactly 192MHz.

Code used to verify clock output:

    CONSOLEUtilsPrintf("Outputting PER_CLKOUT_M2 to CLKOUT2 (pin C24)\n");

    CONSOLEUtilsPrintf("Configuring CLKOUT2 PINMUX...\n");
    HW_WR_REG32(0x44E10A74, 0x3);

    CONSOLEUtilsPrintf("Configuring CLKOUT2...\n");
    HW_WR_REG32(0x44DF4108, 0x00010003);

    CONSOLEUtilsPrintf("CLKOUT2 configuration complete.\n");

As far as I can see, our peripheral PLL is configured and is functioning correctly. Please advise if there is anything further I should check.

Kind regards,

David

Hi David,

We're consulting internal systems/design team on what could cause this kind of issue when using the internal clock source. I hope we can get back to you early next week.

Thanks for your patience.

Regards,

Jianzhong

Hi Jianzhong,

Do you have any further updates on this issue? It would be useful to know whether you have been able to re-create my issue on the IDK using PDK v1.0.17.

Kind regards,

David

Hi David,

Sorry for the delay. Our internal design team are still investigating. I haven't reproduced this issue myself, but the other customer I referred to earlier experienced a similar problem.

Thanks for your patience.

Jianzhong

Hi David,

Our internal design team would like to see your problem reproduced by us. Would you please provide all the details how you built the testing code and did the measurement? I'll try to reproduce the problem on my IDK board.

Thank you.

Jianzhong

Hi Jianzhong,

It should be reasonably straight forward to re-create this issue on the IDK using either the rtc_test diagnostic application (C:\ti\pdk_am437x_1_0_17\packages\ti\board\diag\rtc) or the starterware rtc_app_clock example application (C:\ti\pdk_am437x_1_0_17\packages\ti\starterware\examples\rtc\clock). In each case, the source code needs to be modified to use the internal clock source instead of the external clock source (enumerated value in configuration structure). I built the applications from the makefile.

Regards,

David

Hi David,

Thanks for the information. I'll try it on my AM437x IDK next week.

On the other hand, I would recommend you to consider adding external oscillator to your system, in case this issue is a HW problem and we can't solve it using software. In the other thread I provide earlier, the customer successfully made RTC work using external oscillator with compensation.

Best regards,

Jianzhong

Thanks Jianzhong.

We will consider the external oscillator feature in future, however our current hardware does not include provision for an external oscillator and therefore are seeking a resolution using the internal clock source.

Kind regards,

David

Hi David,

I was able to reproduce the problem that you reported. In one hour period, the RTC on my AM437x IDK lagged a reference clock by 4 minutes 37 seconds. Our internal HW team will be looking into this issue.

Thanks for your patience.

Best regards,

Jianzhong

Hi David,

We're investigating this issue. Just to clarify, when you did the testing on the IDK, did you observe consistent behaviors when using the internal clock source, i.e. RTC is 7.7% slower than real-time? Did you have problems with starting the RTC on the IDK?

In my testing on the IDK, I never had problems with starting RTC.

Thanks,

Jianzhong