• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 436 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Question about setting register

Yi Yin1
Intellectual 430 points

Hi

I have a question about the register of am335x.

In the starterware_02_00_01_01, there are the sample code about the Initialization of MPUPLL、GPIO、I2C、UART...etc.

For example:

StarterWare\bootloader\src\armv7a\am335x\bl_platform.c :
void MPUPLLInit(unsigned int freqMult)
{
volatile unsigned int regVal = 0;

/* Put the PLL in bypass mode */
regVal =
HWREG(SOC_CM_WKUP_REGS +CM_WKUP_CM_CLKMODE_DPLL_MPU) & ~CM_WKUP_CM_CLKMODE_DPLL_MPU_DPLL_EN;

regVal |= CM_WKUP_CM_CLKMODE_DPLL_MPU_DPLL_EN_DPLL_MN_BYP_MODE;

HWREG(SOC_CM_WKUP_REGS + CM_WKUP_CM_CLKMODE_DPLL_MPU) = regVal;

/* Wait for DPLL to go in to bypass mode */
while(!(HWREG(SOC_CM_WKUP_REGS + CM_WKUP_CM_IDLEST_DPLL_MPU) &
CM_WKUP_CM_IDLEST_DPLL_MPU_ST_MN_BYPASS));

StarterWare\platform\beaglebone\gpio.c :
void GPIO1ModuleClkConfig(void)
{
HWREG(SOC_CM_PER_REGS + CM_PER_GPIO1_CLKCTRL) |=
CM_PER_GPIO1_CLKCTRL_MODULEMODE_ENABLE;

/* Waiting for MODULEMODE field to reflect the written value. */
while(CM_PER_GPIO1_CLKCTRL_MODULEMODE_ENABLE !=
(HWREG(SOC_CM_PER_REGS + CM_PER_GPIO1_CLKCTRL) &
CM_PER_GPIO1_CLKCTRL_MODULEMODE));

In the code , the "while " is be used for  waiting for the field to reflect the written value.

My question is that why the  "while" wait is necessary? 

If it is necessary, could you tech me that after how much time the value will be reflected? Because I want to add a timeout count in this code.

Thanks!

Yin

  • 0
    TI__Guru**** 393215 points

    Hi Yin,

    These are clock configuration functions. There are internal delays involved, which will cause the code to hang if executed before the clocks are really enabled. Timeout value will not help here.

  • 0 in reply to Biser Gatchev-XID
    Intellectual 430 points

    Hi Biser

    Thanks for reply.

    Could you tech me the general cycle number of the internal delays? 

    Thanks!

    Yin

  • 0 in reply to Yi Yin1
    TI__Guru**** 393215 points

    There is no public information about internal delays.

  • 0 in reply to Biser Gatchev-XID
    TI__Guru 63595 points

    The AM335x Data Sheet provides peripheral timing at the device package terminals.  Therefore, you should use the data sheet timing parameters to validate your design.

    Regards,
    Paul

  • 0
    Mastermind 8040 points

    Yi Yin1 said:

    My question is that why the  "while" wait is necessary? 

    If it is necessary, could you tech me that after how much time the value will be reflected? Because I want to add a timeout count in this code.

    The cases you showed all involve clock gating or reconfiguration, and involve request/acknowledge handshaking.  The PLLs and clock muxes are meant to provide glitch-free transitions, which means they have to wait for a suitable opportunity to make a clean transition.  The hardware being controlled is also typically in a different clock domain than the control registers, which incurs resynchronization delays both on the change-request and the acknowledge thereof.

    When enabling a module, it may take some time before it actually begins to receive a clock signal for the reasons given above, and it may take the module a few clock cycles to ready itself to service requests and indicate its readiness to the PRCM. For complex modules, if it is the first time they are being enabled after reset, it may take a few dozen clock cycles to complete the reset procedure and become ready for service.

    Since there are many factors, it will be difficult to estimate precisely how long these transitions can take, but since we're talking about "a few dozen clock cycles" and most clock signals to complicated modules are >= 100 MHz, I think a few microseconds would probably suffice, or a few dozen microseconds for waiting for a PLL to lock (which can take hundreds of clock cycles). However, given that a timeout on these things is a serious failure condition with very few recovery options, I would take a big margin and set the timeout to 1 ms or larger.

    The main reasons for failure to respond to a request would be:

    1. A required clock signal is missing:  anything that takes "a few clock cycles" will obviously take forever if that clock is not provided.
    2. You're trying to disable a module which rejects the PRCM's request to go idle.  Under which circumstances a module will or won't acknowledge an idle-request depends on the module and its configuration.  Some modules require specific procedures to enter an idle-state before you can disable them.