• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 423 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.

AM6442: Getting I2C bus 2 working on SK-AM64B EVM

Timothy T
Mastermind 28550 points
Part Number: AM6442
Other Parts Discussed in Thread: SK-AM64B, SYSCONFIG

Hello,

I'm using the SK-AM64B EVM and I'm trying to get I2C working on the Raspberry PI header pin 3 (RPI_I2C2_SDA) and pin 5 (RPI_I2C2_SCL).

I'm using PROCESSOR-SDK-LINUX-RT-AM64 version 08.06.00.42.

All was looking good...

root@board1:~# i2cdetect -l
i2c-1   i2c             OMAP I2C adapter                        I2C adapter
i2c-2   i2c             OMAP I2C adapter                        I2C adapter
i2c-0   i2c             OMAP I2C adapter                        I2C adapter

root@board1:~# dmesg | grep i2c
[    0.814075] i2c /dev entries driver
[    0.981803] omap_i2c 20000000.i2c: bus 0 rev0.12 at 100 kHz
[    1.005999] omap_i2c 20010000.i2c: bus 1 rev0.12 at 400 kHz
[    1.007588] omap_i2c 20020000.i2c: bus 2 rev0.12 at 100 kHz

root@board1:~# ls -al /dev/i2c*
crw------- 1 root root 89, 0 Dec  7 10:27 /dev/i2c-0
crw------- 1 root root 89, 1 Dec  7 10:27 /dev/i2c-1
crw------- 1 root root 89, 2 Dec  7 10:27 /dev/i2c-2

But no matter the i2cget, i2cdump, detect, I couldn't see any toggling of pin3/5.  I confirmed the pull-ups were causing these pins to be high.

I tested with and without an i2c device attached.

In case it did require an update to device tree, I did update my .dts file to contain:

// in the main_pmx0 section:
        main_i2c2_pins_default: main-i2c2-pins-default {
                pinctrl-single,pins = <
                        AM64X_IOPAD(0x00b0, PIN_INPUT_PULLUP, 0) /* (P19) I2C2_SCL */
                        AM64X_IOPAD(0x00b4, PIN_INPUT_PULLUP, 0) /* (R21) I2C2_SDA */
                >;
        };


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

So with this change and a reboot, still not working, although it did change the I2C data rate!

root@labapps:~# dmesg | grep i2c
[    0.813661] i2c /dev entries driver
[    0.980639] omap_i2c 20000000.i2c: bus 0 rev0.12 at 100 kHz
[    1.006164] omap_i2c 20010000.i2c: bus 1 rev0.12 at 400 kHz
[    1.007741] omap_i2c 20020000.i2c: bus 2 rev0.12 at 400 kHz

For the record, from datasheet:

Thanks for the help.

73,
Timothy

  • 0
    TI__Guru** 100800 points

    Hello Timothy,

    I ran out of time to take a look at this today. Please ping the thread if you don't get a response by Thursday.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Mastermind 28550 points

    Hi Nick,

    Checking in on update.

    73,
    Timothy

  • +1
    TI__Guru** 100800 points

    Hello Timothy,

    Thanks for the ping.

    Your pinmux settings are wrong. Looks like you are setting the pins to mux mode 0 when I would expect them to be mux mode 1.

    I typically suggest using the Sysconfig pinmux tool to help generate pinmux settings. Here's what I got when I checked the auto-generated "devicetree.dtsi" file from the sysconfig tool:

    /* This file was auto-generated by TI PinMux on 1/29/2024 at 4:03:02 PM. */
/* This file should only be used as a reference. Some pins/peripherals, */
/* depending on your use case, may need additional configuration. */

&main_pmx0 {
	myi2c2_pins_default: myi2c2-default-pins {
		pinctrl-single,pins = <
			AM64X_IOPAD(0x00b0, PIN_INPUT, 1) /* (P19) GPMC0_CSn2.I2C2_SCL */
			AM64X_IOPAD(0x00b4, PIN_INPUT, 1) /* (R21) GPMC0_CSn3.I2C2_SDA */
		>;
	};
};

    To get there, go to https://dev.ti.com/sysconfig/#/start > device = AM64x > START

    Then select the peripherals you want to add, make sure the information looks the way you want, and then go over to the right hand side of the screen. Pinmux settings for Linux cores look different from pinmux settings for RTOS cores, so you'll want to grab your settings from the devicetree.dtsi file instead of the other pinmux files.

    Note that the core that controls a peripheral should set the pinmuxing for that peripheral. So if the R5F is using a UART interface, for example, the UART pinmuxing should be done on the R5F side instead of in the Linux devicetree file.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Mastermind 28550 points

    Thanks Nick,

    This worked.  Thanks for the Sysconfig tip.  I had tried to use this in past, but and always selected the SDK then the part, so didn't see the dts generation.

    BTW, is there something about reading the TRM or datasheet I missed that would have clued me into the "1" vs. "0" I copied?

    73,
    Timothy

  • 0 in reply to Timothy T
    TI__Mastermind 18090 points

    Hi Timothy,

    Nick is Out of Office today and will respond back to you later in the week.

  • 0 in reply to Anshu Madwesh
    TI__Guru** 100800 points

    Hello Timothy,

    Apologies for the delayed response, I lost track of this thread during my vacation.

    The pinmux value is listed in the datasheet table that you linked above - you can see that the I2C signals are pinmux value 1 instead of pinmux value 0 (which is GPMC signals).

    As far as being able to tell that the third argument in function AM64X_IOPAD is the mux value (instead of something else like "enable/disable"), I am not sure of an easy way to do that. Taking advantage of the SysConfig pinmux tool to double-check your work is the best suggestion I can give.

    Regards,

    Nick