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.

DS90UB954-Q1: Expected Clock Stretch Behavior

Part Number: DS90UB954-Q1

What is the expected behavior of the 954 when a Slave Alias and Slave ID are setup for a given port and the remote slave is not present on the other side of the remote link?  The assumption is a 953 is present and the system is LOCKED, but the remote slave is not enabled or is not physically connected to the remote I2C bus.  Also assume Pass Thru is enabled and Pass Thru All is not used.  All remote communication to the 953 is fully functional.  Also assume BCC Watchdog Control register 0x07 is left as default.

In this case, should the 954 clock stretch for 127 * 2ms = 254ms waiting for a response from the remote slave and then timeout and release the clock?  I have a system where I observe both clock stretching and repeated communication attempts with the remote slave.  In the case where repeated attempts are made, the time duration between attempts is relatively fast ~500us.  Is it possible the 954 is not able to pull the SCLK low before the master is retrying communication?  Thank you.

  • Hi Mark,

    When I2C Pass Thru is on, the deserializer uses a lookup table to check if the I2C address the user is trying to communicate is one of the remote registers. If it isn't, then there's no transaction to the remote side.

    You are correct about the deserializer waiting for a response and time out after a certain duration. The clock stretching duration of 254ms sounds very high for me. ~500us sounds more right. The time stretched can be estimated by multiplying the period of the I2C on the serializer and the number of clock cycles (which is 9). The 954 should be pulling the SCLK low every time.

    Best,
    Jiashow
  • If the remote slave is not present on the remote I2C bus, will the 954 clock stretch for the entire 254ms? I assume the 954 is holding SCLK low the entire BCC_WATCHDOG_TIMER period while waiting for a response.
  • Hi Mark,

    In this case the DES will still send the I2C and does the clock stretching. I'm not sure where 254ms comes from but ~500us sounds more right. The time stretched can be estimated by multiplying the period of the I2C on the serializer and the number of clock cycles (which is 9). 

    Best,

    Jiashow

  • There are 2 different behaviors observed.  In the scope plots below the traces are:

    Yellow = 1V8

    Blue = LOCK

    Green = SCL

    You can see that in one case the SCL line is held low for 254ms.  I assume this is the 954 clock stretching for the entire BCC Timer period from register 0x07 of the 954.  In another case with the same software initialization, there is no long duration of SCL being held low.  Both cases have the same ECU with 954 but each picture has a different remote 953 camera attached.  In both cases, the initialization is looking for a device that is not present in either system.  However, when attempting to read status of the non-present device there are 2 different behaviors.

  • Hi Mark,

    I need more clarification on this. Are you using one 954 connected to two 953s? Or two 954s, each connected to a 953 on RX0? Or are you using the same 954, and just swapping the 953s?

    Can you also provide the register settings/dump for the two cases for us to compare? As well as the more zommed in scopeshots on the SCL line when it's supposed to pull-low.

    Best,

    Jiashow

  • Information was provided offline.