• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 63 subscribers
  • Views 668 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.

UCD90160: MFR_SPECIFIC(High Byte bit 4) of STATUS_WORD(0x79) is wrong when the device first boot

Willy Hung
Prodigy 20 points
Part Number: UCD90160

Hi sir,

Our environment:

OS version: Linux ubuntu-Default-string 5.4.0-48-generic #52~18.04.1-Ubuntu SMP Thu Sep 10 12:50:22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

UCD90160: i2c bus 4, i2c address is 0x6b

1. We use i2cset command to CLEAR_FAULTS.

ex. i2cset -f -y 4  0x6b 0x3

2. We use  i2cget command to read a word data from STATUS_WORD(0x79).

ex. i2cget -f -y 4 0x6b 0x79 w

The STATUS_WORD is 0x0 but it is wrong because we read a word data from MFR_STATUS(0xf3) that is 0x4.

ex. i2cget -f -y 4 0x6b 0xf3 w

The issue only happen at the first boot.

If we power off and then power on the device, the issue can't happen.

It means that the STATUS_WORD is 0x1000 after first boot.

Thanks,

Willy

  • 0
    TI__Guru 65610 points

    Hello

    STATUS_WORD and MFR_STATUS are different command and have different protocol.

    STATUS_WORD is a READ WORD command which shall return 2 bytes

    MFR_SATUS is a READ BLOCK command which shall return 5 bytes including the size byte(fixed at 0x4)

    Could you provide the complete returned data from step 2 and step3. just copying from the console directly shall be enough.

    Regards

    Yihe

  • 0 in reply to yihe
    Prodigy 20 points

    Hi sir,

    console Log:

    ubuntu@ubuntu-Default-string:~$ sudo su
    [sudo] password for ubuntu:
    root@ubuntu-Default-string:/home/ubuntu#
    root@ubuntu-Default-string:/home/ubuntu# uname -a
    Linux ubuntu-Default-string 5.4.0-48-generic #52~18.04.1-Ubuntu SMP Thu Sep 10 12:50:22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
    root@ubuntu-Default-string:/home/ubuntu# ls /sys/class/hwmon/hwmon4/device/driver
    4-006b bind module uevent unbind
    root@ubuntu-Default-string:/home/ubuntu# cat /sys/class/hwmon/hwmon4/name
    ucd90160
    root@ubuntu-Default-string:/home/ubuntu# i2cset -f -y 4 0x6b 0x3
    root@ubuntu-Default-string:/home/ubuntu# i2cget -f -y 4 0x6b 0x79 w
    0x0000
    root@ubuntu-Default-string:/home/ubuntu# i2cget -f -y 4 0x6b 0xf3 w
    0x0004

    Thanks,

    Willy

  • 0 in reply to Willy Hung
    TI__Guru 65610 points

    Hi

    Thanks for the console data.

    But why does command 0xF3 only return 2 bytes? it shall return 5 bytes including the byte size fixed at 0x04? 

    Could you read all 5 bytes of 0xF3?

    if possible. could you also connect the USB-TO-GPIO Dongle to open the fusion GUI and capture the status tab under monitor?

    Regards

    Yihe

  • 0 in reply to yihe
    Prodigy 20 points

    Hi


    We use standard i2cget command that only support to read 2 byte.

    Usage: i2cget [-f] [-y] I2CBUS CHIP-ADDRESS [DATA-ADDRESS [MODE]]
    I2CBUS is an integer or an I2C bus name
    ADDRESS is an integer (0x03 - 0x77)
    MODE is one of:
    b (read byte data, default)
    w (read word data)
    c (write byte/read byte)
    Append p for SMBus PEC

    We can connect  the USB-TO-GPIO Dongle and we will install TI-Fusion-Digital-Power-Designer to capture the status.

    Thanks,

    Willy

  • 0 in reply to Willy Hung
    TI__Guru 65610 points

    Hi

    You can download the latest Fusion GUI at 7.6.1.

    Regards

    Yihe

  • 0 in reply to yihe
    Prodigy 20 points

    Hi sir,

    We install TI-Fusion-Digital-Power-Designer-7.6.1.exe.

    According to the result, we think it is timing problem.

    We will use the below command to track the issue.

    i2cset -f -y 4 0x6b 0x3

    sleep 0.2

    i2cget -f -y 4 0x6b 0x79 w

    i2cget -f -y 4 0x6b 0xf3 w

    Thanks,

    Willy

  • +1 in reply to Willy Hung
    TI__Guru 65610 points

    HI 

    Thank you for the snapshot. I understand what happened. 

    When you issue the clear_fault(0x3) command to clear fault, it does not clear the NEW LOGGED_FAULT_DETAIL bit in the MFR_STATUS since this bit is latched. So there is a mis-match between STATUS_WORD and MFR_STATUS.

    Normally, applications read status before issuing the clear_fault command so they know what happen. 

    One more recommendation is to upgrade the kernel driver to read 5 bytes instead of 2 bytes of the MFR_STATUS. This can ensure that you have the right status from the device.

    Regards

    Yihie