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.

AM/DM37x EVM (DPLL4 stay in bypass mode after system comes back from CORE OFF mode)

Hi Everyone,

Once I wake the system up from CORE off. DPLL4 remains in bypass stop mode.

Now after coming back from OFF I have tried to bring DPLL4 back to lock mode but it’s not working. It was not able to lock at the desired multiplier and divider value. However when I write some other value, let say 0x0 and then write the desired value in CM_CLKSEL2_PLL; It gets locked but serial driver is putting out garbage, which means that frequency being generated is not as programmed. Please note that the multiplier and divider values are correct verified using Linux and TI Clock Tree Tool.

CM_CLKSEL2_PLL = 0x0481b00c

I am also not sure about the AUTOIDLE bit against DPLL4 in CM_AUTOIDLE_PLL register. This bit is not having any effect on system. Do we need to enable this bit and also save it PRCM context save.

Also please note that I following the lock sequence. First I put the DPLL4 in bypass mode. Then after setting the desired multiplier and divider I wait for the DPLL4 to get locked. In my case if I do not write the  CM_CLKSEL2_PLL  register twice as mentioned above, DPLL4 never gets locked.

I can provide register dumps.

Thanks a lot for help,

Haider Miraj

  • Hi,

    Have you checked the AM37x Errata document for DPLL-related issues? There are a number of DPLL advisories there.
  • Hi,

    Yes I think I have tried all those. But if you can point me to the errata document I can definitely again verify.

    Thanks,
    Haider
  • I will ask the factory team to comment on this. They will reply directly here.
  • Haider,

    be sure you are following this advice from the TRM as well:

    DPLL4 requires 2 additional settings than the other DPLLs.
    • The user must select which one of the digitally controlled oscillators (DCO) of the DPLL4 is used,
    depending on the targeted lock frequency. This is done in CM_CLKSEL2_PLL[23:21] DCO_SEL.

    • The user must program the DPLL4 sigma-delta divider. This is done in CM_CLKSEL2_PLL[31:24]
    SD_DIV. This divider value is given by the following equation: SD_DIV = ceiling (CLKOUT/250), where
    CLKOUT Is in MHz

    Regards,

    James

  • Thanks James for your input.
    Yes I have considered these bits inorder to properly configure the DPLL4. I have also verified my settings using TI Clock Tree Tool.

    My SYS_CLK is 26Mkhz.

    DCO_SEL = 0x2 // 500Mhz to 1000Mhz

    SD_DIV = 4

    M = 432

    N= 12

    So, I am expecting CKOUT = 864Mhz

    M2 = 9 as I want 96Mhz

    Here is my code after I come back from CORE OFF. Code get stuck at last while loop as DPLL4 do not get locked.

    /* Put DPLL4 in bypass stop mode */
    WRITE32(CM_CLKEN_PLL , 0x00710007);
    while((ESAL_GE_MEM_READ32(CM_IDLEST_CKGEN) & 0x2));

    WRITE32(CM_CLKSEL2_PLL, 0x0441b00c);

    WRITE32(CM_CLKEN_PLL , 0x770077); //Put DPLL in lock mode.
    while((READ32(CM_IDLEST_CKGEN) & 0x2) == 0); // wait for DPLL to lock.



    With CORE ON or even in CORE RETENTION I am able to use DPLL4 programmed for these settings.

    Strangely, when the CORE comes back from OFF, DPLL4 is in bypass stop mode and never comes back to lock mode.

    Only one way it comes out of bypass mode, if I write some other values and then the desired multiplier and divider value. Even in this case frequency generated is not right.
  • Hello James,

    Just checking if you have reviewed Haider's response to your suggestions? We were also wondering if you could give us a pointer to the Linux code where PLL4 is being locked after returning from OFF mode. We could then compare your code with ours. We did not find anything being done specifically for PLL4 in your BSP but we may have just missed it.
  • Sorry for the late response.  Here are some more ideas:

    -What is the value of PRM_CLKSRC_CTRL.DPLL4_CLKINP_DIV (0x48307270)? 

    -Do you configure this PLL on power up in a similar fashion?  Have you seen any lock issues on power up?

    -Here is possibly another applicable note from the TRM:

    NOTE: The DPLL automatically enters locked mode on a power domain wakeup only if the DPLL is
    locked before the sleep transition and one of the automatic modes is enabled.

    Is the automatic mode in PRCM.CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL enabled when going to OFF mode?  It may be trying to lock prematurely. 

    -Are you setting any of the dividers for DPLL4 in PRCM.CM_CLKSEL3, PRCM.CM_CLKSEL_DSS _CAM

    -What is the value of PRM_CLKSRC_CTRL.SYSCLKDIV.  This can divide the system input clock by 2 before clocking the PLLs

    I will have to try to find the Linux code associated with PLL configuration

    Regards,

    James

  • Hi James,

    Applogies for the delay. I was on vacation.

    Following values are being used. Please let me know if you find something missing.

    PRM_CLKSRC_CTRL.DPLL4_CLKINP_DIV = 0
    PRM_CLKSRC_CTRL.SYSCLKDIV = 1
    PRM_CLKSRC_CTRL = 0x00000040

    I am using same values to lock it at power up, no issues there.

    Automatic mode is not enabled at present for DPLL4. But I have tried it with this mode enabled, same result.
    I have also saved these settings in CONTROL_SAVE_RESTORE_MEM.

    Following values are restored by rom code as I save them in CONTROL_SAVE_RESTORE_MEM before going OFF. I am not explicitly again writing these dividers after coming back from OFF, since its values are already right.

    CM_CLKSEL3_PLL = 0x09
    CM_CLKSEL_DSS = 0x00001009 that makes CLKSEL_DSS1 = 9 , CLKSEL_TV = 4

    CM_CLKSEL1_EMU= 0x03020a50 that makes DIV_DPLL4= 3

    I have verified my values by taking register dumps after LINUX wakes from OFF. I was not able to find any dicrepancies.

    The most strange thing about our problem is DPLL4 do gets locked after CORE OFF if I first write some random value in CM_CLKSEL2_PLL and then the desired value. Even with this, clock being generated is not right, as data being generated on COM port is garbage.

    I am under the impression that If DPLL4 is under Bypass stop mode and then I program the multitplier and divider under CM_CLKSEL2_PLL and enable the lock, I should be able to see status of DPLL4 as being locked. Is other divider values like CM_CLKSEL3_PLL or CM_CLKSEL_DSS can affect its ability to lock.

    Thanks,
    Haider
  • Hi James,

    Wondering did you get the chance to go through Linux code regarding DPLL4? Is there any Errata related to this that I might be missing?

    On my end, I have taken the register dump of Linux image after CORE goes to OFF state.
    processors.wiki.ti.com/.../DM37x_Low_Power_Standby_Support

    I am using same values as for registers related to DPLL4.

    How can I further investigate this problem?

    Regards,
    Haider
  • Hi Haider, sorry for the delay.  Below is a code snippet from our Linux SDK which configures DPLL4.  It writes bit fields individually, which may mimic your scenario of fixing the lock by writing a different value to CLKSEL2.  Other than the restrictions which i mentioned earlier, there should be no dependency on writing certain bit fields before/after others, so I'm not sure why your particular sequence doesn't work. 

    A couple of questions:

    -are you seeing this on many devices, or is this isolated to particular devices/boards?

    -Based on your registers, it looks like you are working with an external oscillator generating a square wave into AM37x.  Is this coming from a companion PMIC or other external device?  Just as a test, can you add a significant delay before configuring DPLL4 (instead of writing bogus values).  I just want to ensure there are no issues with the system clock after OFF mode.  Alternatively, it should be possible to add a while(1) loop and break in with JTAG to step through the configuration to see if you still get a failure.

    -ensure there are no stability issues with vdda_dpll_per on your board at the time DPLL4 is attempting to lock. 

    static void dpll4_init_36xx(u32 sil_index, u32 clk_index)
    {
        struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
        struct dpll_per_36x_param *ptr;

        ptr = (struct dpll_per_36x_param *)get_36x_per_dpll_param();

        /* Moving it to the right sysclk base */
        ptr += clk_index;

        /* EN_PERIPH_DPLL: CM_CLKEN_PLL[16:18] */
        clrsetbits_le32(&prcm_base->clken_pll, 0x00070000, PLL_STOP << 16);
        wait_on_value(ST_PERIPH_CLK, 0, &prcm_base->idlest_ckgen, LDELAY);

        /* M6 (DIV_DPLL4): CM_CLKSEL1_EMU[24:29] */
        clrsetbits_le32(&prcm_base->clksel1_emu, 0x3F000000, ptr->m6 << 24);

        /* M5 (CLKSEL_CAM): CM_CLKSEL1_EMU[0:5] */
        clrsetbits_le32(&prcm_base->clksel_cam, 0x0000003F, ptr->m5);

        /* M4 (CLKSEL_DSS1): CM_CLKSEL_DSS[0:5] */
        clrsetbits_le32(&prcm_base->clksel_dss, 0x0000003F, ptr->m4);

        /* M3 (CLKSEL_DSS1): CM_CLKSEL_DSS[8:13] */
        clrsetbits_le32(&prcm_base->clksel_dss, 0x00003F00, ptr->m3 << 8);

        /* M2 (DIV_96M): CM_CLKSEL3_PLL[0:4] */
        clrsetbits_le32(&prcm_base->clksel3_pll, 0x0000001F, ptr->m2);

        /* M (PERIPH_DPLL_MULT): CM_CLKSEL2_PLL[8:19] */
        clrsetbits_le32(&prcm_base->clksel2_pll, 0x000FFF00, ptr->m << 8);

        /* N (PERIPH_DPLL_DIV): CM_CLKSEL2_PLL[0:6] */
        clrsetbits_le32(&prcm_base->clksel2_pll, 0x0000007F, ptr->n);

        /* M2DIV (CLKSEL_96M): CM_CLKSEL_CORE[12:13] */
        clrsetbits_le32(&prcm_base->clksel_core, 0x00003000, ptr->m2div << 12);

        /* LOCK MODE (EN_PERIPH_DPLL): CM_CLKEN_PLL[16:18] */
        clrsetbits_le32(&prcm_base->clken_pll, 0x00070000, PLL_LOCK << 16);
        wait_on_value(ST_PERIPH_CLK, 2, &prcm_base->idlest_ckgen, LDELAY);
    }

    Regards,

    James

  • Thanks James,

    We are seeing this issue on all the boards we have.

    Yes, we are using PMIC to feed square wave to system. Although Oscilloscope is reporting the expected frequency, I am seeing wave more close to Sinusoid than a Square wave. Can that be an issue? Moreover, I have also noticed the same waveform with Linux.

    I will surely try your suggestions around system clock. To be on safe side, I am also not requesting PMIC to shut down the System Clock/CLKOUTwhen we go to Low Power mode.

    Is there any particular way to test vdda_dpll_per for stability?

    Regards,

    Haider

  • Hi Haider, the sinusoid input could be part of the issue.  PLL lock definitely depends on a proper input clock 

    I also notice something in the code sequence you sent:

    WRITE32(CM_CLKEN_PLL , 0x00710007);

    The bits in red are being written to reserved bit fields.  This might be affecting some part of the PLL programming in an unexpected way.  Typically we would say that reserved bit fields should be left in their default state.  As shown in the linux code, all configuration is done in a read-modify-write fashion, so that only the appropriate bit fields are altered.  Another experiment would be to try only performing read-modify-writes when configuring DPLL4. 

    As far as vdda_dpll_per, I'm just looking for any stability issues.  Improper decoupling on the board may result in noise issues, especially during PLL lock. Ensure Cvdda_dpll_per is close to the AM37x ball and around 100nF.  You can start with probing the voltage rail during config to see if there are any droops or other anomalies in the voltage level.  It should stay at a consistent voltage level throughout the configuration (1.8V +/-5%).  Max peak-to-peak noise should not be greater than 50mV.

    Regards,

    James

  • Hi James,

    I have tested voltage on J20 (pin VPLL_1V3_TAP). I believe it is the one going to vdda_dpll_per. It remains steady at 1.8V.

    I have tried read modify write for CM_CLKEN_PLL.

    I have also attempted to put delay before trying to lock again.

    I have also tested the Linux programming sequence. I think I am attempting the right programming sequence because this is working in other CORE power states.

    Nevertheless, I don't see this issue when I am putting CORE in RETENTION mode (OSWR) and this issue only appears with CORE going to OFF. 

    I don't know Finite State Machine of DPLL4 comes under Retention Flip Flop logic of CORE domain. Because it seems that only RFF are kept ON in CORE OSWR state and system is working fine in that case.

    Is there any baremetal source specifically tested on this platform that I can look into? or try to reproduce my issue with that. I already have this one.

    http://processors.wiki.ti.com/index.php/Power_Management_CCS_project_for_OMAP35x_and_AM-DM37x

    However by looking at the DPLL4 lock funciton in this source it appears it is tested on different platform as DPLL4 multiplier and divider values are being set for half frequency. I am not sure how it is tested on DM37x.

    If I provide you baremetal C code that can you reproduce this issue, will it be feasible for you to setup environment at your end and try that code? 

    Much appreciated.

    -Haider 

  • Hi Haider, the problem you describe (and your observations of a fix) looks similar to Usage Note 2.13 in AM37x Errata (www.ti.com/.../sprz318f.pdf)
    Although that usage note describes and issue with the HSDIVIDER bits and PWRDN mode, there may be a similar effect on the PLL when coming from OFF mode. I don't have any indication that there is an errata associated with this, just thought it was coincidental.

    Do you toggle the PWRDN bits at all? Can you perform the errata workaround even if you don't, and see if your frequencies are correct.

    If you can provide baremetal C code, a can try to get it running on one of our EVMs
    Regards,
    James
  • Hi James,

    I think I have already tried that Errata, but I will take a look at it again.

    No, we don't toggle PWRDN bits.

    Importantly, below is the link for baremetal code. Please give it a try. I have put few comments in there with your name initials, which are relevant to you.

    drive.google.com/.../0BwL5eLo7GWqFcWw2WUhNalVNWms

    Let me know if you need more information/help.

    This application simply puts CORE in OFF and wake the sytem up after ~5 sec using GPTIMER1.

    You only need to put breakpoint in the funciton where the control returns after wakeup, inorder to check the state of DPLL4.

    Thanks,
    Haider
  • Hi James,

    Please let me know if you face any issue while trying to reproduce the scenario.

    I am looking forward to your input.

    Regards,
    Haider