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.

AM263P4: CLKOUT frequency Configuring and Multi-PHY Connection

Part Number: AM263P4
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

For a custom PCB that includes multiple DP83826 PHYs I would like to use that AM263Px.CLKOUT0 pin as the DP83826.XI (clock input). 

DP83826 Datasheet Excerpt1:

DP83826 Datasheet Excerpt2

However, it is not clear how I can configure AM263Px.CLKOUT0 to output the 50MHz clock needed.

 a)

It seems like there may be a way to configure this through SysConfig through:

{BUILD_CONFIG_OUTPUT_PATH}/syscfg/ti_power_clock_config.c

However, I do not see where in the GUI to configure this.

Is it possible to configure the clock through SysConfig?

 b)

Or can it by done through a driver API call? is this API call what I’m looking for?

void SOC_rcmCoreApllHSDivConfig(SOC_RcmPllFoutFreqId outFreqId, SOC_RcmPllHsDivOutConfig *hsDivCfg)

… defined here:

${COM_TI_MCU_PLUS_SDK_AM263PX_INSTALL_DIR}\source\drivers\soc\am263px\soc_rcm.c

 

 c)

I also see what looks like the register addresses that may control CLKOUT0 in file:

${COM_TI_MCU_PLUS_SDK_AM263PX_INSTALL_DIR}\\source\drivers\hw_include\am263px\cslr_iomux.h

.. sections:

  /* CLKOUT0_CFG_REG */

 /* PLL_PER_HSDIVIDER_CLKOUT0 */

Is using direct register writes an option?

Please advise.

 

  • Hi Scott,

    You can use this API from soc_rcm.c

    /**
     * \brief Set CLKOUT clock frequency
     *
     * \param clkout0FreqHz [in] CLKOUT0 frequency
     * \param clkout1FreqHz [in] CLKOUT1 frequency
     *
     */
    extern void SOC_rcmsetClkoutClock(uint32_t clkout0FreqHz, uint32_t clkout1FreqHz);

    You can also refer to the following excerpt 6.4.1.2.3.2.3 Sequence for Programming CLKOUT Clock from TRM.

    Best regards,
    Akshit

  • Hi Akshit,

    I tried using SOC_rcmsetClkoutClock(), but I have not been able to get the intended results().

    To reiterate my goal, I want to use the CLKOUT0 port as seen here:

    My SOC is configured for CLKOUT0, but I do not know how.

    I tried calling 

    .SOC_rcmsetClkoutClock() in various places during initialization. However:

    1) I am passing in zero as the 2nd argument which may ne wrong

    2) The clock stops oscillating when I call SOC_rcmsetClkoutClock().  

    Please advise.

    Regards,

    Tollman

  • Hey Scott,

    Apologies! something might not be working correctly. Let me try to figure out the issue with the API.

    However, you can configure the above register directly to your preferred DIV VAL, for CLKOUT0.

    Regards,
    Akshit

  • Hi Akshit,

    I tried to change the CLKOUT0 frequency by writing to TOP_RCM_MMR0.

    1)

    I did this through the debugger as seen here:

    However, I was not able to get a 50MHz signal.

    0x00000222 == ~8MHz,

    0x00000333 == ~6MHz,

    Is there something I'm doing wrong with this approach?

    2)

    Then tried to follow the TRM sequence that you referenced:

     6.4.1.2.3.2.3 Sequence for Programming CLKOUT Clock 

    However, I cannot find the "CLKOU0 GCD register" referenced in that section (step 1).

    Please provide Register Addendum references for the required registers.

    Regards,

    Tollman

  • Scott,

    1. I used this API to configure CLKOUT[1:0] both at 50MHz -> SOC_rcmsetClkoutClock(50000000, 50000000);
    2. Following are the divider and status values set as you can see to 0x999 and 0x904 respectively.
    3. To test the waveform I set the configure pinmux to output CLKOUT1 on HSEC pin 72, like this:

      /*
      * Pinmux
      */
      static void App_pinmuxConfig()
      {
          static Pinmux_PerCfg_t App_PinMuxMainDomainCfg[] = {
          {

              PIN_SDFM0_CLK0,
              ( PIN_MODE(0) | PIN_PULL_DISABLE | PIN_SLEW_RATE_LOW)
          },

          {PINMUX_END, PINMUX_END}
      };
      Pinmux_config(App_PinMuxMainDomainCfg, PINMUX_DOMAIN_ID_MAIN);

      }

    4. And got the following output, verifying my expectations.

    Could you try this way and let me know if this works for you ?

    Best regards,
    Akshit

  • Hi Akshit,

    I tried to replicate your test on my AM263Px Control Card. However, I do not see any oscillation on HSEC pin 72.

     

    My project is based on "hello_world_am263px-cc_r5fss0-0_freertos_ti-arm-clang". 

    The project is attached.

    .hello_world_am263px-cc_r5fss0-0_clkout1.zip

    Do you see the problem?

    Regards,

    Tollman

  • ...

    Hi Akshit,

    Also, if you could provide your project in the meantime, that would be helpful.

    Thanks,

    Tollman

  • Hi Scott,

    The following project is working for me!

    hello_world_clkout_50MHZ.zip

    Best regards,
    Akshit

  • Hi Akshit,

    I am not able to get 50MHz to work when running in DEV_BOOT mode (with debugger attached). Upon reset, I see 25MHz, but after the:
    the SOC_rcmsetClkoutClock(50000000, 50000000);

    ... call, the CLKOUT1 stops oscillating. 

    If I write the appimage to OSPI, the CLKOUT1 oscillates at 50MHz. This works with both the appimage  you supplied in the zip file, and also with a locally built version.

    Can you explain this behavior?

    Regards,

    Tollman

  • Hi Scott,

    You're right, I was also testing in OSPI mode, although with a debugger. 
    I am able to reproduce your issue of not getting any clock in Devboot Mode.

    My thought is that as devboot mode has no SBL, the CLKOUT clocks aren't configured in the gel scripts.

    Let me get some more information for you from the right people regarding this issue.

    Thanks and regards,
    Akshit

  • Hi Akshit,

    1)

    It general do you recommend using SBL_NULL rather than DEV_BOOT? 

    2)

    My understanding is the with DEV_BOOT gel scripts through RBL are used to configure the processor into a state needed to attach the debugger, and execute an application loaded by JTAG. With SBL_NULL, the SBL does is responsible for doing (through executable code) what the gel scripts do with DEV_BOOT.  Differences in these two processes may put the processor in a different state, during execution of application code if that code does not reconfigure what was done during bootloader execution.

    Is this accurate?

    Regards,

    Tollman

  • Hi Scott,

    I'll have to confirm this with the boot experts. Let me get back to you ASAP.

    Regards,
    Akshit

  • Hi Scott

    1) SBL_NULL would be more universal than GEL scripts which are CCS based.

    2) Yes these operations put the processor in a different state, which may need to be handled by the application.

    Also, I missed this before but here's an excerpt from the TRM, which states that PLL's are not configured by DEVBOOT

    Regards,
    Akshit