VIDEO1PLL Status of AM3874

Michi,

Michi Yama said:

1) Is it possible to happen the above status? And if it is posssible, please let me know its condition.

From what I understand, the strange thing here is that you have the PHASELOCK bit set to 0x0 (which means you loose the phase lock) but FREQLOCK bit is still set to 0x1 (which means the frequency is still locked)?

To sum up, first VIDEO1PLL is working fine, after that at some point it looses its phase lock (PHASELOCK=0) and indicates that in needs recalibration (RECAL_OPPIN = 1 and RECAL_BSTATUS3 = 1), but it indicates its frequency is still locked (FREQLOCK=1), is that the case?

Usually the loss of lock in the PLL is due to large temperature change or voltage supply change since the last lock request.

Michi Yama said:

2) If RECAL flag is asserted, is ADPLLJ recalibrated by hardware?

I think NO. Only the ADPLLS (MPU_DPLL) can be configured for auto-recalibration by the hardware through setting the MPUPLL_CLKCTRL[11] DRIFTGUARDEN bit to 0x1. VIDEO1PLL_CLKCTRL does not have such bit.

Best regards,
Pavel

Michi,

The feedback from the PLL expert:

Dear Pavel-san,

Thank you for your support.

Please see the below. These are register dump for VIDEO1PLL  registers.

M3 means VPSS module

Cortex-A8 BOOT (26M)
　0x481C51D0   00000030 0711080F 00000000 00000000
　0x481C51E0   00140013 00000208 08000000 00000000
　0x481C51F0   00000000 C0000638 00000000 00000000

 M3 INIT(148M)

　0x481C51D0   00000030 0711080F 00000000 00000000
　0x481C51E0   00020013 00000252 08000000 00000000
　0x481C51F0   00000000 C0000630 00000000 00000000

M3 LCD(31.36M) NG --- LCD does not display anything.　　　　　　　　　　　　　　　　　　　　　　　　

　0x481C51D0   00000030 0711080F 00000000 00000000　
　0x481C51E0   00190018 00000310 08000000 00000000　
　0x481C51F0   00000000 D8000238 00000000 00000000　

M3 LCD(31.36M) OK --- LCD displays correctly.

0x481C51D0   00000030 0711080F 00000000 00000000
0x481C51E0   00140013 00000208 08000000 00000000
0x481C51F0   00000000 C0000638 00000000 00000000

As you see from the above, when M3 is configured for LCD (This is 2nd configuration for M3), strange case(Phase lock =0, Freq lock =1, Recal=1) happens.

 Please give me some advise.

Best regards,

Michi

Michi,

Michi Yama said:

As you see from the above, when M3 is configured for LCD (This is 2nd configuration for M3), strange case(Phase lock =0, Freq lock =1, Recal=1) happens.

This does not answer the question that our PLL expert asked:

To help me, can you let me know what is the output clock observed under RECAL=1, PHASELOCK=0, FREQLOCK=1 condition. Is it bypass clock or the at-speed clock?

Best regards,

Pavel

Michi,

Other things I noticed are:

Michi Yama said:

M3 LCD(31.36M) OK --- LCD displays correctly.

Michi Yama said:

0x481C51E0   00140013 00000208

This configuration is for 26MHz, not for 31.36MHz.

Michi Yama said:

M3 LCD(31.36M) NG --- LCD does not display anything.

Michi Yama said:

0x481C51E0   00190018 00000310

This configuration is for 25.088MHz, not for 31.36MHz.

If you need to clock the LCD with floating point number (in example 25.088MHz) you should try with programming the PLL fractional multiplier (Frac M) to have the 088 fractional part! VIDEO1PLL_FRACDIV[17:0] FRACTIONALM

Best regards,
Pavel

Dear Pavel-san,

Thank you for your support.

>To help me, can you let me know what is the output clock observed under RECAL=1, PHASELOCK=0, FREQLOCK=1 >condition. Is it bypass clock or the at-speed clock?

Do you mean this symptom occurs when PLL enters bypass mode? If yes, my answer is no. When this symptom occurs, PLL does not enter to bypass mode. It is normal clock mode.

> 0x481C51E0  00140013 00000208

>This configuration is for 26MHz, not for 3.136MHz.

Yes. 26MHz is OK at this point. Because PLL is configured three times. First configuration of PLL is set by Cortex-A8(In WEC7).  In this point,  VIDEO1PLL is configuraed to 26MHz.

> 0x481C51E0 00190018 00000310

> This configuration is for 25.088MHz, not for 3.1.36MHz

Sorry for few information. As you said, configuration is for 25.088MHz. But in actual, 31.36MHz is measured on board.Becuase N parameter could not be changed. N parameter keeps "0x13", not "0x18". Because N parameter is allowed to change in bypass mode. This time.

For configuration, floating point number is not needed. But your adivice is very helpful for me.

Could you concern this symptom (PHASE LOCK =0, FREQLOCK =1, RECAL =1)? If you need more information, please let me know.

Best regards,

Michi

Michi,

This is the feedback from the PLL experts:

Pavel-san,

Thank you for your support.

This phenomenon happens once 5times WEC7 OS booting. And the frequency of this phenomenon increases at high temperature than room temperature.

According to our analysis,

1) First Cortex-A8 configures PLL rejisters to case1.

2) Second VPSS-M3 configures PLL registers for 297MHz( M2=2, N=19, M=594) as intialization. But actual clock is 148MHz.

3) Third VPSS-M3 configures PLL registers to case 2 ( this is customer's requirement ).

At third step, customer set their LCD requirement as parameters of function. The function pass the data to M3. M3 decides parametes(N, M, M2)  by calcuration.

But at first, parameter N never changed (N=19 is keeped). For this reason, output clock is not changed. The phenomenon happens at this point.  So we inserted " force action for bypass mode transition " before the function call. The parameters "N" could change by this modification.

Could you understand my explanation of the above?

Best regards,

Michi

Michi,

Could you please provide me your mail or your TI local FAE mail?

Best regards,
Pavel

Dear Pavel-san,

Thank you for your support.

You can see my email address in my profile.

BTW, I would like to know regarding "RECAL" flag.

1) When can I use RECAL flag? after PLL is locked? or before PLL is locked?

2) If I try to lock the PLL in bypass mode, and PLL can not be locked, in this case, is RECAL flag asserted?

3)If RECAL flag is asserted in case of 2),  what is used as monitor  for RECAL flag assertion? timeout?

I appreciate your support.

Best regards,

Michi

Michi,

Michi Yama said:

1) When can I use RECAL flag? after PLL is locked? or before PLL is locked?

After PLL is locked.

Per my understanding, the PLL should be active and locked, to be able to assert the RECAL flag. The PLL should be locked, then if PLL loss the lock it will assert the RECAL flag. Usually the loss of lock in the PLL is due to large temperature change or voltage supply change since the last lock request.

Michi Yama said:

2) If I try to lock the PLL in bypass mode, and PLL can not be locked, in this case, is RECAL flag asserted?

I think no.

I will double check this with our PLL experts.

Best regards,
Pavel

The feedback from the PLL experts:

RECAL will only be asserted after PLL lock.

Regards,
Pavel

Dear Pavel-san,

Thank you for your support.

>RECAL will only be asserted after PLL lock.

This comment takes me to my first question in this thread.

>RECAL lfag : set,  FREQLOCK flag : set, PHASELOCK flag : clear

> Is it possible to happen the above status?

How do you think about this?

I could not reproduce this status in EVM.

Best regards,

Michi

Michi,

Michi Yama said:

>RECAL will only be asserted after PLL lock.

This comment takes me to my first question in this thread.

>RECAL lfag : set,  FREQLOCK flag : set, PHASELOCK flag : clear

> Is it possible to happen the above status?

This case is not documented. Can you check if there is any change in the operating condition for this case? Large temperature change or voltage supply change?

Michi Yama said:

I could not reproduce this status in EVM.

Then it might be a custom board hardware design issue. I mean if the same software is running fine on the EVM and fail on the custom board, this is usually indication of custom board hardware malfunction.

Regards,
Pavel

Dear Pavel-san,

Thank you for your support.

We succeeded to reproduce this phenomenon with TI AM3874EVM.

This issue is not for only customer board. Please confirm this phenomenon in your side.

We confirmed this with the below three conditions.  Probably, threre are many other conditions, I think.

pixel clock (clock out) : 29.088MHz,  M: 909, N:24, M2:25   (value is decimal) 

                                         28.504MHz,  M: 891, N: 24, M2:25   

                                         28.608MHz,  M: 894, N: 24, M2: 25

The value of VIDEO1PLL_Status register is "0xD800 0238".

Also the below is debug message on serial port when this happens.

PID: 00400002 TID: 04690006  set pll failed.

PID:  0040002 TID: 04690006 failed to set pll

PID:  0040002 TID: 04690006 failed to int display controller

PID:  0040002 TID: 04690006 vps init failed

Could you explain me why PLL can't do PLL lock?

I appreciate your quick reply.

Best regards,

Michi

Michi,

I have check/test this on the DM814x/AM387x EVM - http://www.ti.com/tool/tmdxevm8148

Michi Yama said:

pixel clock (clock out) : 29.088MHz,  M: 909, N:24, M2:25   (value is decimal) 

Even that the math calculations reports 0 for the ref_clk and clkout, the VIDEO1PLL hardware actually is working fine and produce the 29.088MHz frequency.
By math calculations, I mean:

ref_clk = CLKIN/(N+1), the u-boot that I am using reports bad value of 0 instead of the expected 0.8 value! And thus clkout reported value is 0, not 29.088. But the wrong math calculations does not prevent the VIDEO1PLL hardware to work fine with these parameters!

After my system boot up and load the u-boot + kernel, I check the actual frequency with the Clock Framework:

root@dm814x-evm:/sys/kernel/debug/clock/osc0_clkin_ck/video1_dpll_clkin_ck/video1_dpll_ck# cat rate
29088000

Michi Yama said:

The value of VIDEO1PLL_Status register is "0xD800 0238".

The value of the VIDEO1PLL_STATUS in my side looks fine (0xC0000638):

root@dm814x-evm:# devmem2 0x481C51F4
/dev/mem opened.
Memory mapped at address 0x40236000.
Read at address  0x481C51F4 (0x402361f4): 0xC0000638

By all this, I want to note you that pure calculation of the expected ref_clk and clkout values does not work (I am not sure why), but the VIDEO1PLL hardware seems to work fine. These calculations does not impact the VIDEO1PLL hardware, these calculations are only for user information.

Regards,
Pavel

Michi,

I also check this with CCS/JTAG and GEL file.

The result is the same. The user info calculations are bad (reports ref_clk is 0), but actually the PLL works fine, all the PLL registers have the correct values.

cmdVIDEO1PLL(CLKIN,24,909,25);

cmdVIDEO1PLL(int CLKIN,int N, int M, int M2)
{
         
           PLL_Clocks_Config(VIDEO_1_PLL_BASE,CLKIN,N,M,M2,ADPLLJ_CLKCRTL_HS2);  
           GEL_TextOut("\t VIDEO-1 ADPLLJ CLKOUT  value is  = %d \n",,,,,CLKOUT); --> report 0 for CLKOUT, which is not true
          
}

PLL_Clocks_Config(UWORD32 Base_Address,UWORD32 CLKIN,UWORD32 N,UWORD32 M,UWORD32 M2,UWORD32 CLKCTRL_VAL)
{
    UWORD32 m2nval,mn2val,read_clkctrl,clk_out,ref_clk,clkout_dco = 0;
    m2nval = (M2<<16) | N;
    mn2val =  M;
    ref_clk     = CLKIN/(N+1);
    clkout_dco  = ref_clk*M;
    clk_out     = clkout_dco/M2;

GEL_TextOut("\t ref_clk  value is  = %f \n",,,,,ref_clk);  --> reports 0.0, which is not true
GEL_TextOut("\t clkout_dco  value is  = %f \n",,,,,clkout_dco); --> reports 0.0, which is not true
GEL_TextOut("\t clk_out  value is  = %f \n",,,,,clk_out); --> reports 0.0, which is not true
     
    
 
    WR_MEM_32(Base_Address+CLKCTRL, RD_MEM_32(Base_Address+CLKCTRL)|0x00800000);
    while (( (RD_MEM_32(Base_Address+STATUS)) & 0x00000101) != 0x00000101);
    WR_MEM_32(Base_Address+CLKCTRL, RD_MEM_32(Base_Address+CLKCTRL)& 0xfffffffe);
    //wait_delay(3);
    WR_MEM_32((Base_Address+M2NDIV    ),m2nval);
    WR_MEM_32((Base_Address+MN2DIV    ),mn2val);
    //wait_delay(3);
    WR_MEM_32((Base_Address+TENABLEDIV),0x1);
    //wait_delay(3);
    WR_MEM_32((Base_Address+TENABLEDIV),0x0);
    //wait_delay(3);
    WR_MEM_32((Base_Address+TENABLE   ),0x1);
    //wait_delay(3);
    WR_MEM_32((Base_Address+TENABLE   ),0x0);
    //wait_delay(3);
    read_clkctrl = RD_MEM_32(Base_Address+CLKCTRL);
    //configure the TINITZ(bit0) and CLKDCO BITS IF REQUIRED
    WR_MEM_32(Base_Address+CLKCTRL,(read_clkctrl & 0xff7fe3ff) | CLKCTRL_VAL);
    read_clkctrl = RD_MEM_32(Base_Address+CLKCTRL);
    // poll for the freq,phase lock to occur
    while (( (RD_MEM_32(Base_Address+STATUS)) & 0x00000600) != 0x00000600);
    //wait fot the clocks to get stabized
    //wait_delay(10);
    CLKOUT    = clk_out;   --> reports 0.0, which is not true
}

You see that all these calculations (ref_clk, clkout_dco, clk_out, CLKOUT) are only for user info and does not impact the PLL! The PLL finally is locked and active.

After these settings, the VIDEO1PLL registers values looks fine:

VIDEO1PLL_PWRCTRL = 0x30;
VIDEO1PLL_CLKCTRL = 0x08110811;
VIDEO1PLL_TENABLE = 0x0;
VIDEO1PLL_TENABLEDIV = 0x0;
VIDEO1PLL_M2NDIV = 0x00190018;
VIDEO1PLL_MN2DIV = 0x0000038D;
VIDEO1PLL_FRACDIV = 0x08000000;
VIDEO1PLL_BWCTRL = 0x0;
VIDEO1PLL_FRACCTRL = 0x0;
VIDEO1PLL_STATUS = 0xC0000638;

Regards,
Pavel

Dear Pavel-san,

Thank you for your support.

Sorry. 29.088 MHz pxel clock is timeout error by cortex-A8 software in WEC7.

Please check the below condition.

Pixel clock : 35.640MHz (M:891, M2:25, N:19)

The above condition is not timeout error. This is the condition that happens unlock of PLL.

I would like to know why this condition is not lock.

I appreciate your support.

Best regards,

Michi

Michi,

Michi Yama said:

Sorry. 29.088 MHz pxel clock is timeout error by cortex-A8 software in WEC7.

What do you mean by "clock is timeout error"? The VIDEO1PLL STATUS register does not have timeout error status bit!

Michi Yama said:

Pixel clock : 35.640MHz (M:891, M2:25, N:19)

I will check these settings on the DM814x/AM387x EVM with EZSDK (u-boot and linux kernel) and with OS-independent (nor Linux, nor Windows, nor Android, nor QNX, nor BIOS) method, which is through CCS JTAG and GEL file.


Best regards,
Pavel

Michi,

Michi Yama said:

Please check the below condition.

Pixel clock : 35.640MHz (M:891, M2:25, N:19)

This configuration also works fine (CLKIN=20MHz, M=891, M2=25, N=19, clkout=35.640MHz) with the linux based EZSDK. This is what I have when I check the new VIDEO1 PLL frequency.

root@dm814x-evm:/sys/kernel/debug/clock/osc0_clkin_ck/video1_dpll_clkin_ck/video1_dpll_ck# cat rate
35640000

The VIDEO1PLL_STATUS register value also looks correct: 0xC0000638.

Regards,
Pavel

Michi,

Michi Yama said:

Please check the below condition.

Pixel clock : 35.640MHz (M:891, M2:25, N:19)

The above condition is not timeout error. This is the condition that happens unlock of PLL.

This configuration (CLKIN=20MHz, M=891, M2=25, N=19, clkout=35.640MHz) works fine also in the non-os method (CCS JTAG with GEL file). The VIDEO1PLL is active and locked. The VIDEO1PLL registers are:

VIDEO1PLL_M2NDIV = 0x00190013

VIDEO1PLL_MN2DIV = 0x0000037B

VIDEO1PLL_STATUS = 0xC0000638

Regards,
Pavel