DS90UB954-Q1EVM: Chained ACK of I2C

Hello,

Is this 37us between the serializer i2c bust ack and the deserializer i2c bus ack?  Or does it change regularly?  II know that there is typically a response delay time between the data sent and the ACK which is usually on the order of 5-10 us.  With that said 37us is quite a bit outside that range.  Is there anything else on the i2c line that may be interfering with the i2c communication?

Also would you be able to pull some of the i2c status/control registers from the 954/053? 

Regards,

Nick

Hello,

Thank you for your quick response. 

The 37us is between the camera's ACK to the deserializer ACK. The write message was generated from a computer.

The line is clear, only those messages.

I'm able to pull everything with the ALP. Which registers to pull?

Hello again,

So usually there will be some delay between the ACK on the serializer i2c bus and it being recreated on the deserializer I2C bus.  The computer writes to the I2C bus on the deserializer side, the message is encoded in FPD-Link and sent to the serializer where it is recreated.  Then the camera sees the message acknowledges it and that ACK has to be sent back to the deserializer, which can take several microseconds.  So does every camera ACK take 37us to be recreated on the deserializer side? 

Setting AUTO_ACK_ALL in register 0x58 should eliminate this latency but wouldn't allow any verification that the camera received the message.

Regards,

Nick

Hello,

There is always 37us between the ACK of the Camera to the ACK of the serializer.

Please note that the baud rate is 1M and we want to work with that rate.

At 400k the there is a shorter wait time. Please look at the picture attached (A2 and B2 are at the same place).

The AUTO_ACK_ALL didn't change a thing.

Can you please assist?

Hello again,

I am currently looking deeper into this, when you try to transmit at 400k instead of 1M the ACK delay is shorter?  This is peculiar because the delay should be reduced if anything when operating at a higher speed.  Can you tell me whether you are operating the devices in sync mode or non-sync mode?

Nick

Hello,

Yes, the delay is shorter. Please also look at the total transaction time of 400k and 1M, they are very close (56.75us vs. 55.5us).

The 954 is on the evaluation board and it works at its default state as non-sync mode.

The 953 works as sync mode.

Thank you,

Ronen Shashoua.

Hello,

Any updates?

Hello,

Sorry for the delay here.  The 954/953 should just recreate the I2C communication on the other side of the link.  Is it possible to try another slave device on the 953 I2C bus other than 0x12?  It appears that the clock is never released and a stop condition doesn't occur.  Can you also get a capture with another slave device or no slave device?

Regards,

Nick

Hello Nick,

Thank you for your quick response.

I would like to note that the 953 works in synchronous mode and at 1M.

The previous captures reflect the use case of constant data transmitted from an I2C master to the 954 (SCL and SDA above) and from the 953 to the camera (SCL and SDA below). Meaning, the 0x12 is part of the data. capture 1 is an example of zoom out.

I transmitted from the USB2Any of the 954 EVB (using the ALP scripting) a message to another slave. At capture 2, the slave address wasn't configured at the SlaveId and SlaveAlias registers so there was no transmission between the 953 and the slave. Note that the USB2Any transmits at 400k.

At capture 3, I configured those registers to accept this other slave.

Hello Ronen

      Can you clarify if you are still seeing the issue? It looks like you configured the 953/954 for 1MHz I2C whereas the USB2ANY is set for 400KHz. Can you confirm?

Thanks

Vijay

Hello,

The issue still exists. Please look at the captures above and pay attention to the time between the ACK from the camera to the ACK of the 954 (takes about 38us) and the time of 1M transactions vs. 400k transactions (they are very close).

Hello again,

Is there a delay between the ACK and recreation of the ACK if you try to read a register directly from the serializer?  The serializer and deserializer don't interfere with the I2C communication in anyway.  It simply recreates the communication on either side.  It appears the I2C clock is being held low.

Regards,

Nick

Hello,

Sorry for the delay.
Let me summarize the main issues mentioned earlier:
1. The setup is host -> I2C -> 954 EVB -> FPDLINK -> 953 -> I2C -> camera
2. There is a write sequence of data (4000 bytes) at a baud rate of 1Mbps (see captures)
3. The first ACK was generated by the camera that had received the data. The ACK is passed through via FPDLINK and the 954 generates ACK to the host.
4. The time between the first ACK (camera) to the second ACK (954) is too long - around 37us. The main question of this thread is how to eliminate this time?
5. The total time of a write transaction at I2C 400Kbps is similar to 1Mbps (around 56us).
6. Modify AUTO_ACK_ALL didn't change a thing
7. There are no other messages or transmissions on the line beside my transmissions.
8. The 953 works at synchronous mode.
9. I was asked By Nick to capture another slave, I used the USB2ANY that located on the 954 EVB and transmitted from it a data. The baud rate of the master (USB2ANY) is 400Kbps and it cannot be changed to 1Mbps. The part of the 953 -> I2C -> camera was set to 1Mbps.
10. With section (9), I transmitted data to a non-existing slave. The write time was still around 56us. Meaning, there might be a constant wait time of ~56us between transactions. This is weird.
11. With section (9), I transmitted data to an existing slave. There was no change, the waiting period between the ACKs was around 56us.
12. The I2C lines stay low because it is in the middle of data transactions of 4000 bytes. This is done by the 953 and the host/USB2ANY and it is fine.

Please assist as mentioned in section (4).

Thank you very much,
Ronen Shashoua

Ronen,

We have tested this type of configuration before with 1Mbps on both sides of the link and did not see this long delay. Check here for an example:

Please show us what the ALP main page looks like for this setup with the 954 EVM. Also provide the register programming for both devices in the system

Best Regards,

Casey 

Hello Casey,

I sent you a mail with this information.

Thank you,

Ronen Shashoua.

Hello Ronen, 

The attachments in your mail could not be unzipped for some reason. Can you please try again?

Thanks,

Casey