• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 102 subscribers
  • Views 536 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Not able to get I2C2 working-looking for suggestions

Mitchell Kary
Intellectual 630 points

Hi,

We are working with a commercial SOM that brings out all three I2C ports. We are using winCE 7.0 and have I2c0 and i2c1 working. We went to add I2c2 and have been unable to get it working. Here are some details:

1. We tested the pin muxing and HW connectivity by changing the designated I2C2 pins to GPIO pins and toggling them via SW.

2. We can read and write the virtual memory space that was created for the "I2C2" registers and have looked at the I2c2_CON register to make sure it was enabled. It was.

3. The SDA2 and SCL2 pins just remain high even when we do a I2c2 write action.

Are there any errata for the I2c2 functionality in the AM335x?

Any suggestions on things to check would be most appreciated.

Thanks,

Mitch

  • 0
    TI__Guru*** 125430 points

    Did you set RXACTIVE=1 for I2C_SCL?

  • 0 in reply to Brad Griffis
    Intellectual 630 points

    I have it set as follows:

    #define I2C2_PADS    \

            PAD_ENTRY(UART1_CTSN,        (MODE(3) | RXACTIVE | PULLUDEN | SLEWCTRL))             /* I2C2_DATA */ \

            PAD_ENTRY(UART1_RTSN,        (MODE(3) | RXACTIVE | PULLUDEN | SLEWCTRL))             /* I2C2_SCLK */ \

  • 0 in reply to Mitchell Kary
    TI__Guru*** 125430 points

    It would be better if you could print the actual register values at run-time.  I'm not familiar with the way all those macros are defined in Windows.  Looking at what you've written, I would make the following assumptions:

    1. PULLUDEN is most likely enabling the pull up/down.  However, the default "type" is a pull down.  Since I don't see any macros for changing that to a pull UP it is most likely that you have enabled a pull DOWN.  The register value would be the best way to confirm.
    2. The data manual specifies that we have only confirmed timing for fast slew.  I'm not sure how "SLEWCTRL" is defined, but if that is setting the slewcontrol bit to 1 (which is my assumption) then you are using slow slew which is in violation of the data manual.

    I assume you have external pullups right?  These particular I2C pins belong to the VDDSHV6 domain, so you should be externally pulling the signals up to VDDSHV6.  (Make sure you're not pulling to the wrong rail, particularly if you're mixing 1.8V and 3.3V across the VDDSHVx rails.)

    Finally, are you able to print out the value of any of the I2C2 registers at run-time? This is a good way to have a sanity check whether the clock is enabled to the I2C.

  • 0 in reply to Brad Griffis
    Intellectual 630 points

    Brad,

    Thank you for the response. We discovered this week that some EBOOT source files had to be changed to add I2C initialization. I also had to add the pull-ups as you suggested.

    Again thanks for the help.

    -Mitch