• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 4 answers
  • Subscribers 62 subscribers
  • Views 4386 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.

TPS23861 i2C Address Scan

Penny Xu
Genius 15685 points
Other Parts Discussed in Thread: TPS23861

Hi Leonard,

In TPS23861 datasheet section 7.3.13 you could find the sequence of programming the I2C address for each device.

Here’s the sequence to program the I2C address:

  1. Global write command including an unlock code (AAh) and a temporary common slave address (any address other than 30h) is sent to all I2C devices through the broadcast address, 30h.
  2. All TPS23861 devices respond to the broadcast address 30h regardless of the state of the A3 pin. When the three-byte sequence is correctly decoded.
  3. The first TPS23861 device being selected is the only one having its AIN pin at logic high level (U1 in Figure 41).
  4. Using the temporary slave address, write the new 7-bit device address in the I2C slave address register. 

If you take a look at  our reference code you will have a better understanding. http://www.ti.com/product/TPS23861/toolssoftware 

Best regards,

Penny

  • 0
    TI__Guru 71526 points

    If I use the TPS23861 as supplied with default settings, and ping the i2C bus with a READ from addresses 0x00 > 0x7F, I will see an ACK at 0x20 (expected default address) but also at these unexpected addresses:

    • 0x00
    • 0x30>0x3B

    Why is there an ACK at these addresses?

    Additionally, datasheet states 0x00 should NOT be used as an address, and in this case it is not, however, it still responds with an ACK.  Datasheet also states it is reserved, but why?  What is it used for?

    ~Leonard 

       . 

  • 0 in reply to LeonardEllis
    TI__Genius 15685 points

    Hi Leonard ,

    I checked with our designer. 0x00 is the general address defined in I2C standard. 0x0C is the alert response which is also defined in I2C standard. 0x30 is the broadcast address. When we scan the I2C address, it is normal to receive ack from those addresses. If your scan command includes any write action, it is possible to receive extra addresses other than those three addresses. He thinks it's OK to skip 0x30 when you do the I2C scan. Have you tried skipping 0x30? Did you still see the extra addresses when skipping 0x30?

    Best regards,

    Penny 

  • 0 in reply to Penny Xu
    TI__Guru 71526 points

    Thank you, Penny, great information.  Still some confusion, I think.

    Engineer says the sequence from the probe is:  writes a start bit, the address, and a stop bit and checks to see if the slave ACKed its address .

    Notice that the R/W bit is set to WRITE, I think the engineer believes this must be set to 'write' an address, but my understanding is the address is set whether it is a WRITE or READ operation, so I will ask him to change this bit in the analyzer to READ.

    What happens if 0x3x is attempted to WRITE to?

    ~Leonard 

  • 0 in reply to LeonardEllis
    TI__Genius 15685 points

    Hi Leonard,

    If you are trying to write something to 0x30 when doing the I2C scan, it is possible to get extra ack from other addresses. Our designer's suggestion is to skip 0x30 when you do the I2C scan.

    Best regards,

    Penny 

  • 0 in reply to Penny Xu
    TI__Guru 71526 points

    Well, we are not supposed to be writing to 0x3x, correct?  But the basic question in this case was that for every scan, the WRITE bit was set.  For testing addresses to see what is on the bus, the R/W bit should be set to R.  In addition, the table in the datasheet lists many addresses as 'RO' = Read Only, so what would happen if the WRITE bit was set when those addresses are scanned?

    ~L 

  • 0 in reply to LeonardEllis
    TI__Guru 71526 points

    Ooops!  I've been confused.  Okay, the TPS23861 has an automatically assigned i2C address of 0x20.  If the scan sends this address, the TPS23681 should (and does) respond with an ACK.  However, when other i2C addresses are sent, the TPS23681 should not ACK/respond, but at some addresses, it does.  These are not the REGISTER addresses, but the DEVICE address. 

    So, back to the original question - why is the TPS23681 replying/ACK other addresses?

  • 0 in reply to LeonardEllis
    TI__Genius 15685 points
    Hi Leonard,

    Like I said in previous reply, 0x30 is a broadcast address and we use 0x30 to program TPS23861 slave address to EEPROM. Designer thinks it is possible to get extra ACK if you are trying to write to 0x30 which is not allowed. I would suggest you do a quick test that skip 0x30 during I2C scan and check if the extra ACK is missing. I have a customer having same the question and after skipping the address 0x30, they didn't see extra ACK.

    Best regards,
    Penny
  • 0 in reply to Penny Xu
    TI__Guru 71526 points

    Penny,

    Would you be willing to run a test in your lab to see what results you get, please?  Perhaps a set of tests with the i2C R/W bit set to 'W' and another with it set to 'R'.  As well, with and without the 0x3x addresses. 

    This way we know what to expect, as I'm sure this is going to come up over and over.

    ~Leonard 

  • 0 in reply to LeonardEllis
    TI__Genius 15685 points

    Hi Leonard,

    We tested with BeagleBone black board using I2C scan command. We ran the read all command and we didn't get extra addresses. We are not able to run the command with write. We don't have the test setup you have to run your test. You could order TPS23861EVM online to verify with your test setup.

    Best regards,

    Penny

  • 0 in reply to Penny Xu
    TI__Guru 71526 points

    Using u-boot's 'i2c probe' command, when doing a loop probe over all the addresses, setting the READ bit instead of the WRITE bit, I see the TPS23861 only ACKs on expected addresses: 0x00, 0x20 and 0x30. There are no extra mystery ACKs.

     

    HOWEVER - all 3 other devices on the same bus, do not enjoy the READ-bit probe style. They all hold the SDA line low waiting for a register address to appear. One of them holds the line low forever, the other two have lengthy timeouts. Based on the evidence of 3 against 1, I have to assume that WRITE-bit probing is the usual manner, and the TPS23861 is just not handling it properly.   The I2C specification doesn't mention a protocol for discovering attached devices; although [ START, ADDRESS, WRITE, STOP ] appears to be the de facto standard.

    Probing with the READ bit set will not work for us.

     

    I observed that the time between one STOP and the next START is about 4.2ms when mystery extra ACKs are occurring (i2C bus speed is 100 kHz). I added some delay between the probes and discovered this mitigates the mystery ACKs!

    +5ms gave only 0x31 - 0x37 as extra ACKs (instead of the usual 0x31 - 0x3b)

    +10ms gave 0x31 - 0x35

    +15ms gave 0x31 - 0x34

    +30ms gave 0x31 - 0x32

    and finally

    +90.750ms (for a total delay of 95.24246ms as measured on my scope) had the TPS23861 ACKing no extra addresses!

     

    This seems rather clear that an issue with the TPS23861 ACKing addresses it shouldn't, because it's not handling the [ START, ADDRESS, WRITE, STOP ] sequence appropriately. It's not listed on page 34 as acceptable - all the other ICs on the bus are doing it without the delay. Unless there is a timing requirement in the data sheet that the WRITE-probe is violating? I didn't find anything specific to "normal operation" delays.

     

    Seems there is a bug in the TPS23861 i2C handling. Please advise.

  • 0 in reply to LeonardEllis
    TI__Genius 15685 points

    Hi Leonard,

    Here’s the I2C slave address programming protocol(Figure42 in datasheet). 0x30 is the global address. After writing to 0x30, an unlock code(0xAAh) is expected to continue slave address programming, but it doesn’t look for a match unlock code 0xAA before ACK. Meaning if the unlock code doesn’t match, the device will still ACK. So it is possible that the chip would ACK to multiple addresses even though it doesn’t match the unlock code.

    That also explains why after a certain delay, you didn't see the extra ACK.

    Best regards,

    Penny

  • 0 in reply to Penny Xu
    TI__Guru 71526 points

    Thanks for the explanation; however, I'm not understanding why the extra delay creates a situation where the ACK is not sent.  Is there a state-machine or timer in the TPS23861 that will time-out and not send the ACK?

  • 0 in reply to LeonardEllis
    TI__Genius 15685 points
    Hi Leonard,

    If there's no delay after the command to address 0x30, the command to 0x31 could be considered as the unlock code to program the slave address, and then you received the extra ACK according to the unlock code.

    Best regards,
    Penny