DS90UB949-Q1: Clock stretches we try to write registers in DS90UB949-Q1

Hi Lisa,

Is the waveform a snapshot of the 949 or 948? Can you please capture both SCL and SDA lines for 949 and 948 so we can see the full picture? 

We believe this issue may be more of a lock up on the I2C bus rather than clock stretching. Capturing the two devices' SCL and SDA traces will ideally help us determine where in the topology the problem originates.

BR,

Esther

This is from the 949. I can capture SDA and SCL on 949 and 948 today.
The SCL stays low for 252.6ms which is close to the default BCC Watchdog Timeout which is 254ms, it seems like clock stretching to me but we've been having issues with I2C lock up as well.

Can you also give some insight on the second question
"We are using DS90UB948-Q1 on the deserializer which is connected to the remote I2C and has a couple of ADCs that I've confirmed do not clock stretch. In what situation would the serializer need to clock stretch if the peripherals do not clock stretch? Would it be because packet loss?"

Hi Lisa,

Thanks for more information. It seems the SCL is timing out based on the BCC watchdog value, which can indicate an I2C lockup. It would help to capture the 948 traces as well. 

To answer your second question, the serializer theoretically would not need clock stretching if the peripherals do not need clock stretching.  

Thanks for the reply Esther!

I'm still trying to get the trace because the issue it intermittent. I don't think I can catch the exact moment that the bus goes into I2C lockup.
There seems to be a mismatch between the I2C timeout on our STM and the timeout on the 949 Serializer.

The smallest timeout we can configure 949 to have is 2ms which is 222 times the typical BCC delay of 9us as stated in AN-2173, in what application would the BCC watchdog need to be more than the minimum value of 2ms?

Hi Lisa,

I2C timeout could be periodically occurring due to one of the targets holding the bus down or the controller timing out and not sending any more transactions. We would need the 949 and 948 traces to determine where the issue lies. 

Lisa Li said:

There seems to be a mismatch between the I2C timeout on our STM and the timeout on the 949 Serializer.

The smallest timeout we can configure 949 to have is 2ms which is 222 times the typical BCC delay of 9us as stated in AN-2173, in what application would the BCC watchdog need to be more than the minimum value of 2ms?

The timeout of the local I2C bus of the 949 (between the controller and 949) would be the I2C Watchdog Timer rather than the BCC Watchdog. I2C Watchdog Timer is configured in Register 0x5 in the 949.

BCC Watchdog Timer is referring to the timeout across the FPD-link (between the 949 and 948). The BCC Watchdog Timer is not dependent on the BCC delay. Regardless of the BCC delay, the timer will wait 2 ms for a valid transaction and if it doesn't receive anything valid on the control channel, it will terminate the transaction. 

Things will be clearer once you're able to capture the 949 and 948 traces :) 

Thanks,

Esther