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.

AM4378: I2C observed and set clock frequency are different.

Part Number: AM4378

Hi,

In our custom board, EEPROM and PMIC are connected to I2C bus 0 in 400KHz frequency. We are able to communicate with the EEPROM and PMIC with no issues. But when we probed the I2C0_SCL line, the observed frequency is only 370KHz. Please refer to the attached waveform. So, the set frequency is 400KHz and but the observed frequency is 370KHz. And the same we observed when we tested in U-Boot and Kernel. 

How to get the set frequency and observed frequency as the same? Is there any clock setting that needs to be checked?

Thanks,

Monish P

  • Hi,

    Could you please help me to solve the issue 

    Regards,

    Monish P

  • Hello Monish,

    Apologies for the delayed response. Just to double check, how are you setting the frequency in uboot and kernel?

    I am a bit surprised that the oscilloscope sees such a long ramp on the rising edge of the SCL signal. Do you have a lot of capacitance on the traces? What does that part of the circuit look like?

    Regards,

    Nick

  • Hi Nick,

    We are setting the frequency of the I2C channel in the dts device tree of u-boot and kernel.

    In Kernel dts,


    &i2c0 {
    status = "okay";
    pinctrl-names = "default";
    pinctrl-0 = <&i2c0_pins_default>;
    clock-frequency = <400000>;

    }

    Regarding the ramp on the SCL signal. I will check with our team and revert.

    Regards,

    Monish P

  • What crystal frequency are you using?

    if you are using a 24MHz crystal, but configured for a 26MHz crystal, then you would see 370KHz on I2C.

    Check sysboot[15:14] are set correctly. 

    -Paul

  • Hi Paul,

    We are using 24MHz crystal frequency. And the sysboot[15:14] pins are configured as 01b for 24 Mhz crystal frequency.

    Regards,

    Monish P

  • Hi Nick, Paul,

    I2C0 is connected to PMIC(TPS65218D0PHPR) and EEPROM (M24C16-RMN6TP). Please find the image of the circuit.

  • Are you able to monitor the 192MHz PER_CLKOUT_M2 clock on the CLKOUT1 or CLKOUT2 pins? Monitor over time to ensure you have a good stable clock. I can divided by up to 256 before the output pin. See TRM section 6.6.14 for details. 

    Can you check the value of the register I2C_PSC[7:0]?

    --Paul

  • Hi Paul,

    The i2c_psc[7:0] value is 0x00000004

    md.l 0x44e0b0b0 1

    44e0b0b0:00000004

    I am unable to get clock in CLOCKOUT1 and CLOCKOUT2 pins. How to enable and divide upto 256 the clock in either of those pins? What SW changes need to be made to get 192MHz clkout?

    Regards,

    Monish

  • Can you clarify if you have no physical access to the ball D24 or C24, or if you don't know how to configure the device to monitor the clock? 

  • Hi Paul,

    We have physical access to monitor those pins. But our doubt is for getting 192MHz PER_CLKOUT_M2 clock on CLOCKOUT1 and CLOCKOUT2 pins, whether it is required to do any software configuration or it will be sysboot configuration? Could you please explain in detail?

    When we verified both the pins using the oscilloscope, on CLOCKOUT1 pin 24MHz is observed and on CLOCKOUT2 no signal is observed. Also, we set SYSBOOT[17]=1 and SYSBOOT[18]=0.

  • Great,  Here are the register settings in order to route the clock to the pins. 

    For CLKOUT1 on D24 - Dividing 192MHZ by 4 to give a 48MHz clock. you can change the divider as necessary

    PRCM_CM_CLKOUT1_CTRL.CLKOUT1SEL2SOURCE = 0x3 # Selects192Mhz clock from PER PLL[PER_CLKOUT_M2]

    PRCM_CM_CLKOUT1_CTRL.CLKOUT1SEL2DIV1 =  0x2      # Divide by 4 -> 48MHz

    PRCM_CM_CLKOUT1_CTRL.CLKOUT1SEL2DIV2 =  0x0       # Divide by 1

    PRCM_CM_CLKOUT1_CTRL.CLKOUT1SOURCE = 0x2          # Select source from CLKOUT1SEL2SOURCE

    PRCM_CM_CLKOUT1_CTRL.CLKOUT1SEL0DIV = 0x0          # Divide by 1

    PRCM_CM_CLKOUT1_CTRL.CLKOUT1EN = 0x1                     # CLKOUT1 is enabled

    A summarized register value is 0x00820023

    Also need to set the pinmux, CTRL_CONF_XDMA_EVT_INTR0 = 0x0001003

    For CLKOUT2 on C24, same divide value to provide 48MHz clock

    PRCM_CM_CLKOUT2_CTRL.CLKOUTSOURCE = 0x3            # Selects192Mhz clock from PER PLL[PER_CLKOUT_M2]

    PRCM_CM_CLKOUT2_CTRL. CLKOUT2DIV = 0x0                  # Divide by 4 -> 48MHz

    PRCM_CM_CLKOUT2_CTRL. CLKOUT2POSTDIV = 0x2        # Divide by

    PRCM_CM_CLKOUT2_CTRL.CLKOUT2EN = 0x1                     # CLKOUT2 is Enabled

    A summarized register value is 0x00010023

    Also need to set the pinmux, CTRL_CONF_XDMA_EVT_INTR1 = 0x0001003

    CLKOUT2 is probably the one to go with.

      -Paul 

  • Hi Paul,

    Thanks for your prompt reply.

    We tested using the above register settings and we are able to observe 64MHz on both CLOCKOUT1 and CLOCKOUT2 pins.

    => md.l 0x44e10a74 1
    44e10a74: 00010003 ....
    => md.l 0x44e10a70 1
    44e10a70: 00010003 ....
    => mw.l 0x44df4100 0x00820023
    => mw.l 0x44df4108 0x00010023

    PRCM_CM_CLKOUT1_CTRL.CLKOUT1SEL2DIV1 =  0x2  this will divide 192 MHz by 3 to give 64MHz clock on CLOCKOUT1 PIN.

    PRCM_CM_CLKOUT2_CTRL. CLKOUT2DIV = 0x2  this will divide 192 MHz by 3 to give 64MHz clock on CLOCKOUT2 PIN.

    So, we are able to get the expected output on both pins.

    Whether it is possible to achieve I2C clock set frequency and observed frequency as the same?

  • Great - glad it worked (even with my little typo)

    There is no way to get the 192Mhz signal down to  400Khz, best that can be done is 1.2Mhz (3x 400Khz)

    PRCM_CM_CLKOUT2_CTRL. CLKOUT2POSTDIV = 0x5        # Divide by 32

    PRCM_CM_CLKOUT2_CTRL. CLKOUT2DIV = 0x4                 # Divide by 5

    You can observe, in this case, CLKOUT2 along with SCL. What do you measure? 

    Note: CLKOUT2 and SCL will not be in phase.

  • Hi Paul,

    We are able to get the 400 KHz clock frequency at I2C SCL pin. It was the problem with the capacitor (150pF) that was put in SCL line. When it was removed and checked, we were able to get the expected result.

    Thanks for supporting us.

    Regards,

    Monish P