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.

DS90UB948-Q1: Use ALP to debug 948 to send pattern, and find that ALP cannot detect 948

Part Number: DS90UB948-Q1
Other Parts Discussed in Thread: ALP, USB2ANY

Hi team,

Tier 1:Pateo

OEM: VOYAH

Today when we were debugging the test of the 948 pattern, we found that ALP could not detect 948.

We only debug the screen module, so there is no SER. There is an MCU on the screen side. The MCU is responsible for powering on and initializing the configuration of the 948. Since the MCU debugging has not been completed, we can only use ALP to debug and send the pattern alone.

1. For ALP unable to detect the 948, we checked the hardware and removed the 948’s power supply flying lead to be powered by the power supply alone. Avoid 948 not being fully powered on. The picture below is the power supply waveform tested after flying the line on site:

2.I suspect that there are other devices besides 948 in the I2C on USB2ANY, occupying the I2C bus, causing ALP to be unable to detect 948. However, the customer said that all other I2C devices have been disconnected, and I will still continue to check on site tomorrow.
In addition, what suggestions can you give me to help me troubleshoot?

Thanks!

  • 3.948 Is there any relevant pattern code that can be provided to customers for later debugging? Or can you help me edit a copy of the 948 pattern code?

    Below is the customer's timing letter, generated using the internal clock:

  • Hi Alan,

    2.I suspect that there are other devices besides 948 in the I2C on USB2ANY, occupying the I2C bus, causing ALP to be unable to detect 948. However, the customer said that all other I2C devices have been disconnected, and I will still continue to check on site tomorrow.
    In addition, what suggestions can you give me to help me troubleshoot?

    Can the customer isolate the USB2ANY and the 948 in the I2C bus and check if the MCU can recognize the 948? I want to verify that there are no other devices that have the same I2C address. Maybe there is to much I2C communication going on and the bus is getting overloaded. Also, can you go on the scripting tab and write this code and let me know what you read "hex(board.WriteI2C(0x58,0x0)"?

    3.948 Is there any relevant pattern code that can be provided to customers for later debugging? Or can you help me edit a copy of the 948 pattern code?

    The customer can use the Pattern Generator Tab to enable PATGEN from the 948.

    Best Regards,

    Gil Abarca

  • Hi Gil,

    Because there is currently a problem with the customer's MCU debugging, the MCU cannot perform normal reading operations on 948.
    Secondly, we read the 7-bit address of 948 in the USB2ANY host computer. There is indeed an ACK, but the read register value is 0. We are trying to confirm whether there are other devices on the I2C.

    Also, can you go on the scripting tab and write this code and let me know what you read "hex(board.WriteI2C(0x58,0x0)"?
  • Hi Alan,

    Also, can you go on the scripting tab and write this code and let me know what you read "hex(board.WriteI2C(0x58,0x0)"?

    Apologies I made a typo. I meant "hex(board.ReadI2C(0x58,0x0,0x1)" Can you test this and let me know what you read?

    Secondly, we read the 7-bit address of 948 in the USB2ANY host computer. There is indeed an ACK, but the read register value is 0.

    What do you mean by USB2ANY host computer? Are you using ALP to communicate to the 948?

    Best Regards,

    Gil Abarca

  • Hi Gil,

    Yesterday, I went to the customer site to support this issue. Currently, the screen is on and the pattern is sent normally. Thank you for your support.

  • Hi Alan,

    Happy this was solved! I will close this thread for now.

    Best Regards,

    Gil Abarca