• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 2139 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.

BEAGLEBK: I2C issue

Tom W
Expert 1280 points

Part Number: BEAGLEBK

Hello, I'm using a BeagleBone Black (running Processor SDK 4.1) to communicate to an IC over I2C, using the BBB's built-in headers.  I'm working with I2C bus 2.  I've been attempting to communicate with the IC with a generic Python I2C module, which has worked for me in the past with the same IC (albeit on a Raspberry Pi).  The BBB always fails on I2C write commands.  I've also noticed this occurring while using i2cdetect -y 2, which leads to:

"Error: Can't use SMBus Quick Write command on this bus"

and i2cset -r 2 0x0f 0x3e leads to:

"Warning - data mismatch - wrote 0x3e, read back 0x22", where 0x22 is the correct value that should have been sent back from the IC.

I'm a little confused, i2cset implies that the I2C bus may be working, however the script which is known to be working on other machines, and uses no third-party python modules in and of itself (source is here), does not appear to work.

Is there anything special I should know about the I2C bus on the BBB?  Speed restraints?  Should I have added the IC as a node in the device tree?  Any help would be appreciated.

  • 0
    TI__Guru**** 393215 points
    The software team have been notified. They will respond here.
  • 0
    TI__Guru 65405 points

    Hi Tom,

    Check whether the following configuration of I2C pinmux presents in device tree. If it is missed add it:

    	i2c1_pins: pinmux_i2c2_pins {
		pinctrl-single,pins = <
			AM33XX_IOPAD(0x978, PIN_INPUT_PULLUP | MUX_MODE2)	/* i2c2_sda */
			AM33XX_IOPAD(0x97c, PIN_INPUT_PULLUP | MUX_MODE2)	/* i2c2_scl */
		>;
	};
    		i2c2: i2c@4819c000 {
			compatible = "ti,omap4-i2c";
			#address-cells = <1>;
			#size-cells = <0>;
			ti,hwmods = "i2c3";
			reg = <0x4819c000 0x1000>;
			interrupts = <30>;
			status = "disabled";
		};

    BR

    Tsvetolin Shulev

  • 0 in reply to Cvetolin Shulev-XID
    Expert 1280 points

    I found my I2C-2 pinctrl slightly different from the one mentioned above:

    	i2c2_pins: pinmux_i2c2_pins {
		pinctrl-single,pins = <
			AM33XX_IOPAD(0x978, PIN_INPUT_PULLUP | MUX_MODE3)	/* uart1_ctsn.i2c2_sda */
			AM33XX_IOPAD(0x97c, PIN_INPUT_PULLUP | MUX_MODE3)	/* uart1_rtsn.i2c2_scl */
		>;
	};

    But from what I can tell here, MUX_MODE3 is correct for setting these pins (P19, P20) to I2C. 

    Should I attempt a different bus?  I2C-1 would be the prime candidate for that.

  • 0 in reply to Tom W
    TI__Guru 65405 points
    You are right, MUX_MODE3 is the right mode for the pins which you are using (UART1_CTSn). MODE2 is applicable for SPI0_SCLK pin.
    Table 4-1 in the datasheet
    www.ti.com/.../am3358.pdf
    You can attempt on different bus like I2C-1 but check the connecting lines.

    BR
    Tsvetolin Shulev
  • 0 in reply to Cvetolin Shulev-XID
    Expert 1280 points
    I went ahead and configured I2C1 in the same way after I posted my previous reply, and unfortunately the same issue persists. I cannot run i2cdetect on either bus 1 or 2, but but I can write to the bus with i2cset, but cannot read from the bus with i2cget.