Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State
  • Replies 5 replies
  • Subscribers 29 subscribers
  • Views 164 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

DRV2605L: Wrong I2C-Address: 0x5b (instead of 0x5a)

Georg Bauer
Prodigy 10 points
Part Number: DRV2605L
Other Parts Discussed in Thread: USB2ANY, HAPTICS-CONSOLE

Tool/software:

We use the TI chip DRV2605LDGS on a pcb with other i2c slaves. According to the data sheet, this should report at address 0x5A. On some circuit boards it reports at address 0x5B. The chip works perfectly there (rudimentary tests via bit manipulation using I2C tools). The Linux driver does not support this address by default. Hence the reason for the request.

Here is some information to narrow down the cause of the fault:
- Functioning chips and non-functioning chips are labeled the same: 32 TI 05L
- All circuit boards that show this error pattern come (so far) from the same EMS:
- The question to TI:
   o Is there a technical explanation why the chip reports to the wrong address? Was a batch of chips with a different address manufactured for a specific customer?

The information below is for technical error analysis:
- The chip is supplied with 3.3V.
- The I2C level is also 3.3V
- The set frequency is 400kHz, a lower frequency showed the same error pattern.
- The image “i2cdetect_0x5a_0x5b.png” shows the I2C signal characteristics for a bus scan.


- The file “i2cdump.txt” shows the memory content of the functioning chip at address 0x5b.

root@qsxm-mm60:~# i2cdump 1 0x5b
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1, address 0x5b, mode byte
Continue? [Y/n]
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: e0 40 00 01 01 00 00 00 00 00 00 00 00 00 00 00    ?@.??...........
10: 00 05 19 ff 19 ff 3e 8e 0c 6c 7e 93 f7 e1 20 80    .??.?.>??l~??? ?
20: 33 94 00 00 00 00 00 00 00 00 00 00 00 00 00 00    3?..............
30: 00 78 d1 5b df 00 00 00 00 00 00 01 91 00 00 00    .x?[?......??...
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00    ..............?.

- The image “i2cdump_analog_digital.png” shows an example of the signal curve (analog sampled) of the I2C signals.

Best regards and thank you in advance

Georg

  • 0
    TI__Intellectual 1390 points

    Georg, 

    We do not make samples with custom I2C address. This device has only one address at 0x5a. Can you confirm the I2C address of 0x5b can be written by your driver?

    Thanks

    Hailong

  • 0 in reply to Hailong Chen
    Prodigy 10 points

    Hi Hailong,

    thank you for your message.

    I think I did not understand your question. Do you think that the driver changed the address of the device?

    In the first picture “i2cdetect_0x5a_0x5b.png” you can see a cutout of the bus scan sequence. At the address 0x5a is no aknowledge. At the address 0x5b is an aknowdledge with answer. This signal is detected by using a logic analyzer. This means the device will answer on address 0x5b.

    If I try to debug the device I change register values like this:

    i2cset 1 0x5a 0x01 0x06 (set mode “Diagnostics” and activate the device)
    i2cset 1 0x5a 0x0C 0x01 (set Go-Bit)

    to move the motor. This will work with good devices on address 0x5a and with our bad-address-device on 0x5b, too. I am very confused.

    Thanks a lot

    Georg

    PS: I'm only getting in touch because I didn't see the reply. You had updated the out-of-office message. And I received no e-mail. I am sorry!

  • 0 in reply to Georg Bauer
    TI__Intellectual 1390 points

    Georg, 

    No problem. Let me look into the issue and see what can be the reasons. I will provide the feedback after some internal tests. 

    Best,

    Hailong

  • 0 in reply to Hailong Chen
    Prodigy 10 points

    Hi Hailong,

    in the meantime I have a update: We have more devices with an address 0x5b.

    In one case we have a device with address 0x5e.

    Here is the hex dump of this device:

    root@qsxm-mm60:~# i2cdump 1 0x5e

         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef

    00: e0 40 00 01 01 00 00 00 00 00 00 00 00 00 00 00    ?@.??...........

    10: 00 05 19 ff 19 ff 3e ae 2c 6c 7e b7 f7 e4 20 80    .??.?.>?,l~??? ?

    20: 33 8f 37 00 00 00 00 00 00 00 00 00 00 00 00 00    3?7.............

    30: 00 a9 d9 5e df 00 00 00 00 00 00 01 91 00 00 00    .??^?......??...

    40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

    50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

    60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

    70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

    80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

    90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

    a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

    b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

    c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

    d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

    e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

    f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 00    ..............?.

    One other device had a very interesting history: vibration won’t work → debugged with i2cdetect → responds on address 0x5a-> connected another motor (known good device) → motor works fine → reconnect the “original“ motor → no vibration function → debugged with i2cdetect , again → responds on address 0x5b

    Could a possible cause of the address problem be a contact problem with the motor?

    Here are detail images comparing digital and analog signals of logic analyzer. Everything looks fine. The wrong bit at the address can’t caused by signal disturbance or to much speed.

    I buyed an USB2ANY to scan and check with your software Haptics-Console https://www.ti.com/tool/HAPTICS-CONSOLE

    Greetings and Thanks
    Georg

  • 0 in reply to Georg Bauer
    TI__Intellectual 1390 points

    thanks for the additional info. That's interesting to see the inconsistent results. Could you share your schematic if possible? You can email me at h-chen@ti.com if you want to keep it confidential.