On GMSL1 devices I don't get an ACK for I2C commands sent to a remote device--why is this?.
In camera or sensor systems it is common to have a uC attached to the GMSL1 deserializer and for the serializer (camera or sensor) to be considered the remote device and not have a uC.
GMSL1 devices use a high speed video channel in the forward (serializer to deserializer) direction to carry control information in the forward direction, and a dedicated reverse (deserializer to serializer) control channel to carry control information in the reverse direction. These two channels are set up independently.
Assuming the uC and the deserializer can communicate. Sometimes when a command is sent for the remote (serializer) device, no I2C ACK is received. In this case software running on the uC may flag an error (or worse).
This can happen if the serializer is in sleep mode (SLEEP bit set to 1), if the video channel is disabled (SEREN bit set to 0), if the serializer and deserializer are not able to set up the video channel due to incompatible settings, or if there are signal integrity problems with the video channel.
In all cases, the reverse control channel sends the I2C command to the serializer which actions the command, but the ACK is not returned as it is part of the video link, which is non-operational.
A solution to this problem is to enable a dummy acknowledgement locally at the deserializer. Set the I2CLOCACK bit to 1 to do this.
It is advisable to turn this feature off as soon as the video link has been established correctly. This makes sure an error during normal operation will be detected.