TDA4VE-Q1: Unable to access I2C5 (omap_i2c 2050000.i2c) in both U-Boot and Linux environments

Hi,

Christopher said:

We have no idea why the same software configuration fails on the custom board.

1. Can you double check if the same pins are used for the I2C5 on your custom board?
   1. 
   2. 
   3. There are 2 sets of pins so just double confirm the pins.
2. Can you also cross check on your custom board in Linux by reading back the pin mux registers?

   1. /* This file was auto-generated by TI PinMux on 5/26/2025 at 10:11:27 AM. */
      /* This file should only be used as a reference. Some pins/peripherals, */
      /* depending on your use case, may need additional configuration. */

      &main_pmx0 {
      myi2c1_pins_default: myi2c1-default-pins {
      pinctrl-single,pins = <
      J721S2_IOPAD(0x01c, PIN_INPUT, 8) /* (Y24) MCAN15_TX.I2C5_SCL */
      J721S2_IOPAD(0x018, PIN_INPUT, 8) /* (W23) MCAN14_RX.I2C5_SDA */
      >;
      };

      }

3. In your custom board boot to Linux & try:
   'dmesg | grep i2c' Just double check if indeed main_i2c5 is probed successfully.

- Keerthy

Hi Keerthy,

Thanks for the feedback.

We followed your insitructions and cross checked on our custom board in Linux.

Make below modification in k3-j721s2-common-proc-board.dts

&main_pmx0 {
..

    main_i2c5_pins_default: main-i2c5-pins-default {
        pinctrl-single,pins = <
            J721S2_IOPAD(0x01c, PIN_INPUT_PULLUP, 8) /* (Y24) MCAN15_TX.I2C5_SCL */
            J721S2_IOPAD(0x018, PIN_INPUT_PULLUP, 8) /* (W23) MCAN14_RX.I2C5_SDA */
 
        >;
    };
};

&main_i2c5 {                                                                                                   
    pinctrl-names = "default";
    pinctrl-0 = <&main_i2c5_pins_default>;
    clock-frequency = <400000>;
};

And read back the pin mux registers as below

root@j721s2-evm:~# devmem2 0x0011C01C
/dev/mem opened.
Memory mapped at address 0xffff8113f000.
Read at address  0x0011C01C (0xffff8113f01c): 0x40060008
root@j721s2-evm:~# devmem2 0x0011C018
/dev/mem opened.
Memory mapped at address 0xffffaa3da000.
Read at address  0x0011C018 (0xffffaa3da018): 0x00060008
root@j721s2-evm:~#
root@j721s2-evm:~# i2cdetect -l
i2c-3   i2c             OMAP I2C adapter                        I2C adapter
i2c-1   i2c             OMAP I2C adapter                        I2C adapter
i2c-4   i2c             OMAP I2C adapter                        I2C adapter
i2c-2   i2c             OMAP I2C adapter                        I2C adapter
i2c-0   i2c             OMAP I2C adapter                        I2C adapter
root@j721s2-evm:~# i2cdetect -y 4
Warning: Can't use SMBus Quick Write command, will skip some addresses
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:
10:
20:
30: [   72.559377] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   73.571375] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   74.583373] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   75.595376] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   76.607375] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   77.623373] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   78.639375] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   79.651374] omap_i2c 2050000.i2c: timeout waiting for bus ready
--
40:
50: [   80.663373] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   81.675377] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   82.687372] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   83.699372] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   84.711376] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   85.723374] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   86.735374] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   87.747375] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   88.759374] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   89.775375] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   90.787374] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   91.803372] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   92.815371] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   93.827373] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   94.839374] omap_i2c 2050000.i2c: timeout waiting for bus ready
-- [   95.851373] omap_i2c 2050000.i2c: timeout waiting for bus ready
--
60:
70:
root@j721s2-evm:~#

It seems main_i2c5 is not probed successfully

root@j721s2-evm:~# dmesg |grep "i2c"
[    0.689104] i2c /dev entries driver
[    0.815933] omap_i2c 42120000.i2c: bus 0 rev0.12 at 100 kHz
[    0.822188] omap_i2c 40b00000.i2c: bus 1 rev0.12 at 100 kHz
[    0.828290] omap_i2c 40b10000.i2c: bus 2 rev0.12 at 100 kHz
[    0.934569] omap_i2c 2000000.i2c: bus 3 rev0.12 at 400 kHz
[    1.959428] omap_i2c 2050000.i2c: timeout waiting for bus ready
[    1.976186] omap_i2c 2050000.i2c: bus 4 rev0.12 at 400 kHz

We are wondering: since the same bootable SD card works correctly on the TDA4VE EVM and the main_i2c5 interface is readable.

Does this imply that main_i2c5 has been configured properly?

We also double checked Y24 and W23 is only connected to UB960

Thank you very much.

Christopher

Hello Christopher,

I see the pin mux is set correctly. I will loop in our hardware experts. Please expect a delayed response as it is a long weekend for the US team.

- Keerthy

Hi Keerthy,

Thank you for the comfirmation to the sofrware configuration, and look forward to the insights from the hardware experts.

Regards,

Christopher

Hi Keerthy,

We selected a few pins for experimentation and used devmem2 to directly modify the pad configuration, setting the mode to GPIO for read/write operations.

For example:

1. unbind i2c5
echo 2050000.i2c > /sys/bus/platform/drivers/omap_i2c/unbind

2. set pinmux to GPIO mode for ball Y24 and W23
devmem2 0x0011C01C w 0x40060007
devmem2 0x0011C018 w 0x40060007

3. export gpio sysfs to contrl, and measure the voltage by meter

On our custom board, we observed the following:

1. Pins under the VDDSHV2 IO bank, such as Y24/I2C5_SCL, W23/I2C5_SDA, and W25/UART5_TXD, cannot be properly controlled.
2. Pins under the VDDSHV0 IO bank, such as AH25/I2C0_SCL, AE24/I2C0_SDA, and AG26/UART2_RXD, can be controlled correctly. In input mode, they correctly read high/low levels, and in output mode, they can be set to high/low as expected.

Note that on the TDA4VE EVM, all of the above pins (under both VDDSHV2 and VDDSHV0) can be controlled correctly.

Questions:

1. What could be the possible reasons that IO pins under VDDSHV2 are not functioning correctly on our custom board?
2. How can we determine whether the IO bank has entered fail-safe mode due to some error?

Thanks.

Regards,

Christopher

Hi Keerthy,

We picked more pins for experimentation，but the results remained the same. The pins associated with the VDDSHV2 IO group could not be properly controlled.

VDDSHV0 group: AH25, AE24, AG26, AH26, AE27
These pins functioned correctly in GPIO mode.

VDDSHV2 group: Y24, W23, T25, W25, V23, T26, AB28, U27, AD26, U25
These pins could not be properly controlled in GPIO mode.

And the power-on sequence of the PMIC is provided below.

A-GPIO9		= EN_MCU3V3_VIO			= R967	= -56us
B-GPIO11	= EN_3V3_IO 			= R700	= -55us
A-LDO2		= VDD_MCU_GPIORET_3V3	= C727	= 0us
B-LDO2		= VDD_GPIORET_3V3		= C760	= 0us    <-- Yellow (Reference)
B-GPIO3		= EN_DDR_VDD1			= R699	= 1680us
A-LDO4		= VDA_MCU_1V8			= R729	= 1790us
A-LDO3		= VDD_MCUIO_1V8			= R728	= 1750us
B-BUCK3		= VDD_PHY_1V8			= C750	= 1860us
B-BUCK1		= VDD_IO_1V8			= C734	= 1860us
B-LDO4		= VDD_PLL_1V8			= C762 	= 1810us
A-BUCK5		= VDD_MCU_0V85			= C722	= 2860us
A-LDO1		= VDD_MCU_WK_0V8		= C726	= 2760us
A-BUCK1234	= VDD_CPU_AVS			= C695	= 2860us
C-BUCK1234	= VDD_CORE_0V8			= C768 	= 2740us
B-LDO1		= VDD_WK_0V8			= C759	= 2760us
B-LDO3		= VDA_DLL_0V8			= C761	= 2760us
B-BUCK5		= VDD_RAM_0V85			= C756	= 4940us
B-BUCK4		= VDD_DDR_1V1			= C754	= 4940us
A-nRSTOUT	= H_MCU_PORz			= TP190	= 12800us
A-GPIO11	= H_SOC_PORz			= TP191	= 12800us

Thanks.

Christopher

Hi Robert, 

Thank you for the helpful information.

We’ve checked that VDD_WAKE0 (pin 20) is connected to VDD_WK_0V8. However, we noticed that on our custom board, VDD_WK_0V8 is not connected to VDD_WK_0V8_REG, which is the output of PMIC-B LDO1.

After connecting VDD_WK_0V8_REG and VDD_WK_0V8, the IO pins of VDDSHV2 IO group could be properly controlled.

Thanks again and the thread could be closed.

Regards,

Christopher