DS90UB935-Q1: 935 cannot access local device via remote I2C

Hello Elec,

reg    good 962    bad 962
0x47      0x00          0x02 -- This bit will be set if the BCC Watchdog Timer expires while waiting for a response from the Serializer while the BCC I2C Slave is active.
0x4e      0x0c         0x04 -- In good, CSI errors reported
0x53      0x02         0x03 -- Temo sensor
0x7b      0x02         0x00 -- CSI error counter
0x7a      0x01         0x00 -- ECC1 error

All these dumps are from Rx Port2. Is the correct? All other ports are working fine?

Can you try changing 935 reg ister 0x0A[1] from 0 to 1, and see if that resolves the issue?

Hi Hamzeh,

Hamzeh Jaradat said:

Can you try changing 935 reg ister 0x0A[1] from 0 to 1, and see if that resolves the issue?

Yes we already tried to change Watchdog Timer to 50ms but it doesn't work either. 

Hamzeh Jaradat said:

All these dumps are from Rx Port2. Is the correct? All other ports are working fine?

The failure follows 935 module. They test 962 connected to two 935 module. One is good and one is bad. They switch 935 module and it follows with 935 module. 

Elec Cheng said:

It's very weird that they only config 935 register as below initial code. They don't change 935 register. And I also compare 935 register between good and bad. You can see my screen shot as below.  The left one is bad and right one is good. The only difference between them are the several "reserved" register. Can you share more details about these reg? I am also asking the customer whether they change them or not.

Could you please explain the reserve register meaning? I suppose it's not our customer that changes them. Have you ever seen the reserved register changed? 

Also we have another test today. We connect 962 with our 953 EVM, but we replace 953 with faulty 935. We have sensor on the EVM board. We also find the problem, which is 935 remote I2C doesn't output. as you can see below, at "2s" we power on 953 EVM. After 935 power up, we will run 935 initial configuration as mentioned above, and then will access sensor via remote I2C. But we cannot access it. There is no I2C output.

Also, we put the module in -40 temp ambient and then put in 25℃ ambient for 10mins, then power up. The test waveform is as below. 935 I2C not only has no output, but also have voltage drift. 

We will have on-site test with the customer. If there is still no progress, I am afraid that I have to set up call to discuss the problem. It's a very urgent case because the OEM hold off 2000 car because of this problem. You can also tell me what else you need for analysis. Thanks for understanding.

BR,

Elec Cheng

Hello Elec,

I have asked this question earlier but did not get an answer from you!

Which I2C pull-up voltage are they using on the SER?

Can you also send me the initialization Code they are using to initialize our SER, including delays and the used sequence.

Hi Hamzeh,

Elec Cheng said:

For 935 mode pin, it's pulled down with 10k. So the mode should be CSI-2 Synchronous mode.

Already answer here! 

Elec Cheng said:

935 initial code:

         {0x02, 0x73},

         {0x0d, 0x00}, /* disable remote gpio */

         {0x0E, 0xA5}, /* enable gpio input */

         {0x06, 0x43}, /* DIV:4, M:3 */

         {0x07, 0x7d}, /* N:0x7D */

935 initial code is here. There is all for 935 initiation.

As I said, we need your strong support here since it's very urgent case. Thanks for understanding!

BR,

Elec Cheng

Elec,

please read my question carefully! you have not answered it .

Also, I have talked to the team about this behavior. They are pretty sure that this has to do with the WD timeout. Please refer to the attached document and make sure the customer implement and test this correctly!

5732.FPD-Link Camera Startup flow.pdf

Hi Hamzeh,

The pull up voltage is 1.8V. You can see below schematic.

BR,

Elec Cheng

Okay thank you!

Please be aware that the recommended pullup resistor on I2C = 4.7 kΩ for the Standard and Fast mode, while a pullup resistor of = 470 Ω is recommended for the fast plus mode. However, the pullup resistor value may be additionally adjusted for capacitive loading and data rate requirements as per this AppNote.

But as I said, I have talked to the team about this behavior. They are pretty sure that this has to do with the WD timeout. Please refer to the attached document and make sure the customer implements and test this correctly!

Hi Hamzeh,

Thanks for your recommendation here. We set "Speed up I2C Bus Watchdog Timer" as 50ms both in 935 and 962 and it works fine. But for this issue, we have several confusion regarding to our test today.

1. what's the difference between "Speed up I2C Bus Watchdog Timer" and "BCC_WD_TIMER"? We only change "BCC_WD_TIMER" to a small value and it doesn't work. Is "BCC_WD_TIMER" also related in this case? 

2. Currently we the register setting is : "Speed up I2C Bus Watchdog Timer" is 50ms. "BCC_WD_TIMER" is 10ms. Is it good config? 

3.. "Speed up I2C Bus Watchdog Timer" is indeed related for this issue. But from our understanding, the watchdog timer is used for reset I2C when it's not in good state. In our faulty scenario, the remote i2c is accessible 1s after PDB. So that means remote i2c enters "fault" state once PDB pulls high. Only after watchdog timer expires and pull remote i2c back to good state. So why would it act like this? Is it normal?

4. As we mention and test today, with setting "Speed up I2C Bus Watchdog Timer" as 1s. It tends to easier to appear in -40℃. We test one module and it works fine in 15℃ and doesn't work in -40℃. The customer test many module and find in -40℃ it have a higher failure rate. So why is it related to temp? What does temp affect? 

Thank you, Hamzeh again for help in this case!

BR,

Elec Cheng

Hi Hamzeh,

Thanks for your reply!

Hamzeh Jaradat said:

Please change the BCC_WD_Timer to higher than the 50ms.

Could you please explain why BCC_WD_Timer should be higher?

Hamzeh Jaradat said:

Since I2C is based on open-drain IOs, any power supply transients on the power supply will directly translated as activity on I2C and detected as activity by the SER and will trigger the timer. This is especially true during the start-up as there are current transient during device power-up

We understand that the I2C controller enters time out due to transient or disturb on the I2C bus. From your point of view, is it often the case? Is it normal in customer's system? And I am curious that why I2C  watchdog timer is default as 1s? 

Hamzeh Jaradat said:

The Temp change will affect the internal Oscillator clock which can vary as said up to +/-40%, which means in time variation of 600ms to 1.4s. Also, different temperature may have an impact on the power supply for faster or lower rise and fall times.

In one test, we measure it takes about 2s from the PDB pulls up to remote I2C access. Is there any more possible cause that will extend the time? 

Another question, to address the problem before we set I2C watchdog timer to 50ms, the customer will make I2C retry till finally access. In normal operation, do we need the retry still? Thanks.

BR,

Elec Cheng 

Hamzeh,

I work with Elec together for the case.

Customer need to explain to CAR OEM so they still need more clarification from TI.

One thing we cannot explain is why this phenomenon goes with our specific silicon UB935 (A-B-A swap experiment done). 

And the issue can be easily reproduced at low temperature with this specific UB935 (around 10% UB935 can have this behavior at low temperature like -20C).

Bad UB936 can reproduce the phenomenon at our EVM at -20C.

Could you give us a technical explanation for us to report to CAR OEM to close the issue?

Thanks

Hi Hamzeh,

Besides Ryan's question, I have another request. As you may know, this case causes great influence for both CAR OEM and Tier-1. From my point of view, to better close this case, it would be the best if you can provide a material, such as app note or technical manual explaining the root cause and how changing the register helps on technical aspect, to the customer to serve as a conclusion. You can send us via e-mail since this is public forum. Thanks.

BR,

Elec Cheng