• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 61 subscribers
  • Views 116 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.

LP8764-Q1: I2C Reads to invalid device addresses

Barry W
Intellectual 810 points
Part Number: LP8764-Q1

The default I2C1 device address for the parts we buy is 0x48.

We re-program the flash and configure the I2C1 device address to 0x4C.

Now we run a startup routine to detect an unmodified LP8764.  We issue a read to 0x48.  The I2C write that sets up this read does not get acknowledged.  This is expected.

We wait 30ms.

Next we try to read from device ID 0x4C.  This is successful, but the values in the replies are corrupt.  We keep getting corrupt read value on subsequent I2C1 reads to other addresses.

If we power up the device and only ever read/write to 0x4C everything works fine.  Every time we issue a write to the incorrect address the corruption begins.

Do you have any idea why an unacknowledged write request to an incorrect address  would bork the I2C1 interface of the LP8764?

  • 0
    Intellectual 810 points

    The same thing happened when we reversed the process, reprogrammed to 0x48 and checked 0x4C.

  • 0 in reply to Barry W
    Intellectual 810 points

    Here is an I2C analyser trace of the issue.  I reduces the delay back down to 0.3ms so you could see the whole process.  I tried a 30ms delay with the same results.  You can see I am trying to read register 1 which should not respond with 0x86.  (0x86 is a common response to many addresses in this broken mode)

  • 0 in reply to Barry W
    Intellectual 810 points

    Of course 0x86 is the correct response from address 0x01.

    It is the I2C controller on our MSPM0 that is the issue.  It appears to want to keep reading address 1 indefinitely after the NAC on that first read.  Thus all the 0x86 responses.

    I have been looking at this issue for a week, but it wasn't until I began describing it to you in detail that the issue revealed itself.

    Sorry for the bother.