This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DS90UB949A-Q1: I2C communication issues

Part Number: DS90UB949A-Q1

Hello Team, enclosed a question from customer doing a HDMI-to-FPD3 adapter device:

HW description:
- sender : DS90UB949 which is doing HDMI to FPD3, connected to a STM32 microcontroller which is controlled by a USB interface to PC (starting I2C commands)
- HDMI input of DS90UB949 could be connected with a PC. Resolution is 1920x1200 with a pixel clock of 154MHz

- receiver: DS90UB948 as de-serializer connected to a TFT display and also local ARM CPU. This CPU is I2C slave and is monitoring different I2C addresses and can be used for different applications such as touch, brightness, diagnostics,etc...

To do firmware updates 8-Byte-Writes on address 0x3C executed until 128 Bytes on payload is transferred. (means 19 times 8-Byte-Writes executed). After this they wait on acknowledge and next cycle starts.

Because of huge software load on receiver side clock-stretching is necessary on FPD3 devices.

Failure is that transfer is broken without any known reason. Effect is that transfer is not finished with release on CLK and ACK on serializer side even display side (de-serializer) is confirmed. Serializer is than running in timeout and cancelled transaction.

Included is a scope recording where you can see on top master/serializer and bottom slave/de-serializer. After 0x78 Byte slave is confirming with ACK but master didn't receive or recognize it.

HDMI is not connected but if connected probability of error is less. It seems that pixel clock is influencing the error - increased clock frequency is reducing the error. You can see this also with enabled pattern generator on the serializer side if no HDMI is connected. Leads to less errors.

Conditions:
- dual link FPD3 (mandatory at 154MHz)
- I2C on both sides on pass-through
- picture transfer is ok

Any idea how to solve this issue?

Many Thanks

Josef

  • Instead of combined 20 bytes write. Can they try to do short writes with just one byte data, one byte address, and terminate with a stop?

    Could you help provide the register dump for both the Ser and Des?

    Best Regards,

    Charley Cai