• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 3 answers
  • Subscribers 98 subscribers
  • Views 877 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.

DRA829V: Issues with probing I2C slaves

Ahsan Hussain
Intellectual 600 points

Part Number: DRA829V
Other Parts Discussed in Thread: DS90UB960-Q1, DS90UB926Q-Q1

Hello,

I'm using PSDKLA Release 06.02.00 for J7-EVM and trying to probe i2c slave devices using the i2c-detect tool. I'm specifically looking for FPD III ub960 deserializer which should be on /dev/i2c-2 at address 0x2C (i2c3 according to the board schematic).

However I see weird results when probing i2c-2 adapter; every time I run i2c-detect the slave devices are detected at different addresses, and I get no response on reading 0x0 register on chip address 0x2C (which should read the chip address according to ub960 datasheet). At first I thought this an issue with my EVM board, but I could reproduce this with a couple of other boards as well.

Moreover probing some of the other adapters for i2c slaves results in OMAP i2c driver timing out and i2c reads failing. In the light of these observations I have the following queries:

1. Why is the omap driver acting up? Could this be pinmux/electrical properties issue for i2c pins?

2. How can I access ds90ub960-Q1 via I2C character device on Linux.

Thanks

  • 0
    Intellectual 600 points

    i2cdetect log for a couple of runs:

    # i2cdetect -y -r 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- 13 -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- 2c -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- 3a -- -- -- -- -- 
40: -- 41 -- 43 -- 45 -- 47 48 49 4a 4b 4c 4d 4e 4f 
50: 50 51 -- -- 54 -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
    # i2cdetect -y -r 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- 13 -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- 48 49 4a 4b 4c 4d 4e 4f 
50: 50 51 -- -- 54 -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --
  • 0 in reply to Ahsan Hussain
    TI__Genius 9905 points

    Hello Hussain,

    It seems that the problem is that deserializer DOES NOT respond to the i2c detect message.

    This might be because you are runnning the i2c at a  speed which is not supported by the slave.

    Check if you need to lower the i2c speed in device tree.

    Also, other device addresses are actually the remote devices for which the Deserializer aliases with different addreses.

    If the deserializer communication is unstable, its expected that the aliased remote devices do not show up all the time.

    If you can detect one device, that means all pinmux is correct.

    If some controllers timeout all the time, that might be due to missing pinmux. Please check the DT to confirm if pinmux is being described.

    Also Check the i2c speed.

    Regards,

    Nikhil D

  • 0 in reply to Nikhil Devshatwar
    Intellectual 600 points

    Hello Nikhil D,

    First let me make some corrections to my question. This is not a ub960 but ds90ub926q-Q1 deserializer that I'm trying to access. According to J721EXCP01EVM common processor board schematic this should be on the I2C3 bus at 0x2C. Also note that I didn't make any modification to the device tree that comes with TI Linux SDK.

    Looking at the k3-j721e-common-proc-board.dts in TI kernel for PSDKLA Release 06.02.00, I can see that "main_i2c3" node is configured at 400KHz, which is supported as the "Fast Mode" SCL clock frequency by ub926. Still, the device isn't showing on i2c-3 under Linux.

    root@j7-evm-mel:~# i2cdetect -y -r 3                                                                                                                                                                               
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: UU -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- 6d -- -- 
70: 70 71 -- -- -- -- 76 --

    > If some controllers timeout all the time, that might be due to missing pinmux. Please check the DT to confirm if pinmux is being described.

    This is correct; no pinmux is being described for these controllers. Shouldn't these be disabled in the common processor board dts?

    Regards,

    Ahsan

  • 0 in reply to Ahsan Hussain
    TI__Genius 9905 points

    Hi,

    You are right. The i2c3 and many other devices which do not have pinmux should be disabled so as to avoid this kind of confusion.

    Now, for the i2cdetect not working with right bus number, Please note that the Linux enumeration of the i2c devices is not tied to the TRM i2c instances

    I did following to find out the actual i2c device for main_i2c

    root@j7-evm:~# cat /proc/device-tree/__symbols__/main_i2c3; echo
    /interconnect@100000/i2c@2030000

    root@j7-evm:~# ls /sys/devices/platform/interconnect@100000/2030000.i2c/
    driver driver_override i2c-6 modalias of_node power subsystem uevent

    root@j7-evm:~# i2cdetect -r -y 6
    0 1 2 3 4 5 6 7 8 9 a b c d e f
    00: -- -- -- -- -- -- -- -- -- -- -- -- --
    10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    20: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    40: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
    50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    70: -- -- -- -- -- -- -- --
    root@j7-evm:~#

    I hope this solved your issue.

    Regards,

    Nikhil D

  • 0 in reply to Nikhil Devshatwar
    Intellectual 600 points

    > Now, for the i2cdetect not working with right bus number, Please note that the Linux enumeration of the i2c devices is not tied to the TRM i2c instances

    Yeah, udev dynamic enumeration; I was getting omap i2c timeout on the same buses every time so I thought maybe the controller numbers correspond due to some changes in kernel by TI.

    > i2cdetect -r -y 6

    This still doesn't show the device at 0x2c?

  • 0 in reply to Ahsan Hussain
    TI__Genius 9905 points

    Hi,

    Can you please confirm if the controller you are looking for is indeed main_i2c3?

    I checked on the common proc board, there is no UB960 in the schematics

    Regards,

    Nikhil D

  • 0 in reply to Nikhil Devshatwar
    Intellectual 600 points

    Hello,

    > Can you please confirm if the controller you are looking for is indeed main_i2c3?

    Yup, pretty sure. The device shares the bus (PROC079E3B(001)_SCH.pdf pg.7 'I2C Tree') with audio codec at 0x44 which is visible in your i2cdetect output for main_i2c3.

    > I checked on the common proc board, there is no UB960 in the schematics

    It's ub926 (same doc. pg. 41)

  • 0 in reply to Ahsan Hussain
    Intellectual 600 points

    Hello,

    Is there an update on this?

  • 0 in reply to Ahsan Hussain
    TI__Genius 9905 points

    Hi Hussain,

    Sorry for the delay in response.

    You are not seeing the chip because it is in reset by default.

    You need to drive the UB926_RESETN  (GPIO expander at i2c3/0x20 P02) line to high to as to enable this.

    I did following to enable the GPIO:

    root@j7-evm:~# ./scr/fun-leds.sh 6 0x20
    >> Detected chip pca6408
    + i2cset -f -y 6 0x20 0x3 0xfa
    >> Set pin 002 to output
    + i2cset -f -y 6 0x20 0x1 0xff
    >> Set pin 002 to 1

    root@j7-evm:~# i2cdetect -r -y 6
    0 1 2 3 4 5 6 7 8 9 a b c d e f
    00: -- -- -- -- -- -- -- -- -- -- -- -- --
    10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    20: UU -- -- -- -- -- -- -- -- -- -- -- 2c -- -- --
    30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    40: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
    50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    70: -- -- -- -- -- -- -- --

    I hope this solves your issue.

    Regards,
    Nikhil D

  • 0 in reply to Nikhil Devshatwar
    Intellectual 600 points

    Thanks, I was able to see the device after setting UB926_RESETN to high. However according to datasheet I should read 7–bit address of Deserializer from register at 0x00 address, but I'm reading a different value.

    # i2cget -y 6 0x2c 0x00
0x58

    Can you please let me know why's that?

  • 0 in reply to Ahsan Hussain
    TI__Genius 9905 points

    Hi,

    The address is in the bits 7:1 

    If you shift 0x58 by 1 bit, you get 0x2c

    Regards,

    Nikhil D