DS90UB914A-Q1: FPD-LinkⅢ with ds90ub914a-q1 and ds90ub913a-q1

takayuki matsumoto

Prodigy 10 points

Part Number: DS90UB914A-Q1
Other Parts Discussed in Thread: DS90UB913A-Q1,

The DS90UB913A-Q1 catches ACK during I2C communication. However, ACK is not output from a DS90UB914A-Q1.

This phenomenon occurs only with a specific address, and normalcy works by I2C communicating again.

WHY?

NG I2C (no ack in ds90ub914a-q1) OK

CH1(YELLOW) DS90UB913_SDA

CH2(BLUE) DS90UB913_SCL

CH3(RED) DS90UB914_SDA

CH4(GREEN) DS90UB914_SCL

over 3 years ago

0 Justin Phan over 3 years ago

TI__Mastermind 28040 points

Hi Takayuki,

In your 913A/914A setup, it seems you are sending an I2C command to the I2C bus at the remote 913A, from the processor connected to the 914A.

SoC->914A->913A

1) Are there any other devices on the 913A I2C bus that may be holding the I2C lines down?

2) On the 914A device, what is the value set in registers 0x21 and 0x03? Is I2C_PASS_THROUGH_ALL enabled or I2C_PASS_THROUGH?

3) After a failed I2C transaction on the UB913A I2C bus, do you need to wait a certain amount of time before you can send another I2C command through? If so, then the I2C Watchdog timer on the 913A device might be being triggered.

Best,

Justin Phan

0 takayuki matsumoto over 3 years ago in reply to Justin Phan

Prodigy 10 points

Hello, Justin

thank you for your reply.

1) SoC->914A->913A->camera. No other devices.

2)On the 914A device is I2C_PASS_THROUGH Enable and I2C_PASS_THROUGH_ALL Diseble.

3) I will think about it.

0 Justin Phan over 3 years ago in reply to takayuki matsumoto

TI__Mastermind 28040 points

Hi Takayuki,

Since I2C_PASS_THROUGH is enabled, then only I2C commands that are defined in the SlaveAlias/SlaveID registers in the 914A device will be passed to the I2C bus on the 913A. If you send an I2C command from the SoC on the local 914A I2C bus to the remote 913A I2C bus, but the I2C address does not match any device address, then the I2C bus on the 913A side will be held until the Watchdog Timer times out and cancels the I2C command.

If you are able to successfully send I2C commands to the camera, but get no response when sending an I2C command from any other I2C address, then this is expected behavior.

Best,

Justin Phan

0 takayuki matsumoto over 3 years ago in reply to Justin Phan

Prodigy 10 points

Hello, Justin

914A outputs ack, device address and register address in device on I2C bus.so address is no problem on i2c bus.

914A doesn't output ack only when write register data of specific in device.

But ack is output again when write register data of specific in device.

No time out, because watchdog timer diseable .

914A didn't output ack when other I2C address, then this was expected behavior.

takayuki

0 Justin Phan over 3 years ago in reply to takayuki matsumoto

TI__Mastermind 28040 points

Hi Takayuki,

If you are sending an I2C command from the SoC->914A->913A->Camera, then the receiver (in this case the Camera) will send an ACK response back to the SoC across the SER->DES channel.

If ACK is not sent back after a certain amount of time, then the Watchdog timer on the 913A will cancel the transaction and release the I2C bus on the 913A. The Watchdog timer is enabled by default on the 913A device and it is recommended to keep enabled.

If the Watchdog timer is disabled, then the 913A will continue to hold the I2C bus, until it gets an ACK from the target of the I2C command.

This App Note also explains how I2C works across our FPD-Link devices:

https://www.ti.com/lit/an/snla131a/snla131a.pdf?ts=1649787622565&ref_url=https%253A%252F%252Fwww.google.com%252F#:~:text=The%20FPD%2DLink%20III%20Serializer,according%20to%20the%20I2C%20standard.

Best,

Justin Phan

0 takayuki matsumoto over 3 years ago in reply to Justin Phan

Prodigy 10 points

Hello, Justin

I will ask the camera manufacturer. because 914A doesn't output ack when only specifik address.

ACK is sent back by retry when specifik address.

Thank you for everything.

0 Justin Phan over 3 years ago in reply to takayuki matsumoto

TI__Mastermind 28040 points

Hello Takayuki,

In that case, I will close this thread for now. Feel free to follow-up or post a new E2E post if you have any questions.

Best,

Justin Phan

0 D_Coburn_MSI_WGV over 3 years ago in reply to takayuki matsumoto

Prodigy 100 points

Hi guys,

I am experiencing a very similar problem with the DS90UB954 & DS90UB953 link.
I have not been able to determine why it happens yet, but it is not associated with address or register offset.
I do not know what the default BCC timeout is for your parts, but on my setup it is 254msec.
The picture I am including actually shows 2 failures. The broad empty waveform sections at the top are both ~ 250msec. The lower section shows a closeup of the waveform when it fails. You can see that the protocol works through the write, but it fails in getting the sensors' ack back to the ISP.

Here is another failure with a little better imagery. You can clearly see the timeout numbers in the second capture.

I have the single address write broken down in my mind as follows: (954-deSer / 953-Ser)
01) ISP: start good
02) ISP-2-954: good
03) 954-2-953: good
04) 953-2-Snsr: good
05) Snsr-2-953: good ack / unsure of 953 capture
06) 953-2-954: ???
07) 954-2-ISP: no ack / BCC Watchdog timeout
08) 254msec (deterministic)
09) 954-2-ISP: nack (correct for failed mode at 254msec)
10) ISP: stop good

Have you gained any more understanding with your issue so far?

thanks,
david coburn

0 Justin Phan over 3 years ago in reply to D_Coburn_MSI_WGV

TI__Mastermind 28040 points

Hello David,

Could you start a new E2E post with your question and then link this E2E post, if necessary?

This helps us keep the E2E forum posts organized and easier to look-up for other members of the community.

Best,

Justin Phan

0 D_Coburn_MSI_WGV over 3 years ago in reply to Justin Phan

Prodigy 100 points

Justin,

I will open a new question and link to this one....

I do have a question about this one though... At the top right of this page it shows "TI thinks resolved". What was the resolution for Takayuki's problem? The sensor sent back the ack to the 913 in both of his captures. The 914 did not provide an ack to the I2c Master.
thank you,

david

0 Justin Phan over 3 years ago in reply to D_Coburn_MSI_WGV

TI__Mastermind 28040 points

Hello David,

In the FPD-Link devices, when the a Master sends an I2C command from Master->DES->SER->Slave, the target Slave needs to send an ACK response back to the Master over the cable link between the SER and the DES.

An 8-bit I2C address is sent to the Slave first. If the Slave responds with a proper ACK, then the Master will send another 8-bit message which is the actual READ/WRITE command. It seems to me that when an I2C message is sent from the Master->Slave, the wrong address is used and there is no Slave that matches the address. As a result, no Slave will send an ACK response back to the Master and the Master will not send an 8-bit I2C READ/WRITE command. The Watchdog Timer on the SER will automatically cancel the I2C action after some time if no ACK bit is sent back.

Here are also some App Notes that describe the topic, when including the FPD-Link devices:

https://www.ti.com/lit/an/slva704/slva704.pdf?ts=1652483477132&ref_url=https%253A%252F%252Fwww.google.com%252F#:~:text=Acknowledge%20(ACK)%20and%20Not%20Acknowledge,another%20byte%20may%20be%20sent.

https://www.ti.com/lit/an/snla131a/snla131a.pdf?ts=1652483690364&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FDS90UB960-Q1

Best,

Justin Phan

0 D_Coburn_MSI_WGV over 3 years ago in reply to Justin Phan

Prodigy 100 points

Justin Phan said:
Hello David,

In the FPD-Link devices, when the a Master sends an I2C command from Master->DES->SER->Slave, the target Slave needs to send an ACK response back to the Master over the cable link between the SER and the DES.

An 8-bit I2C address is sent to the Slave first. If the Slave responds with a proper ACK, then the Master will send another 8-bit message which is the actual READ/WRITE command. It seems to me that when an I2C message is sent from the Master->Slave, the wrong address is used and there is no Slave that matches the address. As a result, no Slave will send an ACK response back to the Master and the Master will not send an 8-bit I2C READ/WRITE command. The Watchdog Timer on the SER will automatically cancel the I2C action after some time if no ACK bit is sent back.

Here are also some App Notes that describe the topic, when including the FPD-Link devices:

https://www.ti.com/lit/an/slva704/slva704.pdf?ts=1652483477132&ref_url=https%253A%252F%252Fwww.google.com%252F#:~:text=Acknowledge%20(ACK)%20and%20Not%20Acknowledge,another%20byte%20may%20be%20sent.

https://www.ti.com/lit/an/snla131a/snla131a.pdf?ts=1652483690364&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FDS90UB960-Q1

Best,

Justin Phan

Justin,

I have started the new question as you asked, and have left you some questions.

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1102203/ds90ub954-q1-ds90ub954-q1-to-ds90ub953-q1-bcc-i2c-errors

thank you,

david coburn

0 Justin Phan over 3 years ago in reply to D_Coburn_MSI_WGV

TI__Mastermind 28040 points

Hello David,

In that case, we can continue the discussion on the new thread.

Best,

Justin Phan

Interface

Interface forum

DS90UB914A-Q1: FPD-LinkⅢ with ds90ub914a-q1 and ds90ub913a-q1