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: DS90UB948:How to perform the MAP test

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

Tool/software:

Hi,

We are conducting FPDLink3 communication between a display equipped with the DS90UB948 and a controller equipped with the DS90UB927.

I would like to implement MAP in this communication system, but I am having difficulties. Could you please provide some advice on possible solutions?

  • I can connect USB2ANY to the deserializer's I2C and perform BIST.
  • I also have the EVK kit, and I can connect it to a PC and run ALP to perform MAP.

Since the device with the DS90UB948 does not have a USB port, I am investigating ways to access the I2C to execute MAP.

Best,

  • Hello,

    I can connect USB2ANY to the deserializer's I2C and perform BIST.

    If you have I2C access through the external USB2ANY to the deserializer's I2C connection, you may run MAP through ALP on the USB2any over I2C and attain the output, same as if it were connected to a USB port.

    As long as you have a secure I2C connection to the DES from the USB2ANY, the same functions should be available when running ALP.

    Best,

    Miguel

  • Hi,

    Thank you for your response.
    I understand that I can use ALP with USB2ANY.

    However, I am currently unable to do so.
    I will outline my usage environment below, and I would appreciate any advice you could provide to improve the situation.

    1. Connect the device as shown in the photo.
    2. Launch the USB2ANY tool and select the 3.3V pull-up option. Do not close the tool.
    3. Launch the ALP tool.
    4. Select DU90UB948 in ALP.

    I suspect that I might be making a mistake in the steps or that there is a conflict with the DES's I2C.
    When I select option 4, the screen of the DES device goes dark, so I particularly suspect an I2C conflict.

    Is there a way to avoid conflicts on the USB2ANY/ALP side?

    Best,

  • Hello,

    Thank you for providing the block diagram - so it sounds like on this custom board there may be the I2C conflict from a different controller - possibly an MCU directing communication to the display (interruption causes black screen).

    Since the appropriate configurations are already made from the USB2ANY and ALP, my suggestion is to either run the MAP analysis from the local controller on the DES I2C bus, or to disable any peripherals connected to the DES while running the MAP analysis 

    • These peripheral devices can be re-enabled after the test - they should have no effect on the FPD-Link performance.

    Do you have access to the internal design of the DES board?

    Best,

    Miguel

  • Hi,

    I was able to execute MAP via I2C using USB2ANY.
    There were errors in the steps I provided, so I will document them as a reminder.

    1. Connect the device as shown in the photo.
    2. Launch the ALP tool and select DU90UB948 in ALP.
    3. Power on the DES device.
    It is unnecessary to launch the USB2ANY tool; instead, the device needs to be powered on after launching ALP.

    As a result of conducting MAP measurements, there were some areas that partially failed.
    Is this a common case? If so, could you please explain the reasons?
    Alternatively, when I enabled I2C passthrough for 0x03 and 0x05, the issue did not occur anymore, so I suspect that the conflict was caused by the I2C between ALP and the device.

    Best,

  • Hi,

    These results are okay, according to the FPD-Link MAP Analysis application note:

    FPD-Link Margin Analysis Program (MAP) user's guide

    There are at least 4 strobe positions within 2 EQ locations, which is within recommendations for FPD-Link:

    Please let me know if you have any further questions!

    Best,

    Miguel

  • Hi,

    I thought it was an issue with the I2C path, and after protecting it with aluminum tape, everything is now okay.

    In the case of the diagram recommended by TI, will the EQ value set in AEQ be 8?

    Best,

  • Hi,

    I thought it was an issue with the I2C path, and after protecting it with aluminum tape, everything is now okay.

    Good to hear!

    In the case of the diagram recommended by TI, will the EQ value set in AEQ be 8?

    The diagram recommendation is based on the specific results from this MAP analysis.

    In that case, the signal integrity is particularly limited, so using EQ of 9/10 is preferred in order to keep maximum margins.

    Based on your initial diagram, EQs that have no red boxes in any strobe locations would be fine to implement.

    Best,

    Miguel

  • Hi,

    "It is recommended to use a 9/10 EQ to maintain the maximum margin."

    Is my understanding correct regarding the following points?
    - When manually setting the EQ, it is better to keep it at a higher level.
    - In the case of AEQ, it is automatically set to a minimum, and if the stability threshold is exceeded, the EQ is incremented automatically."

    Best,

  • Hello,

    - When manually setting the EQ, it is better to keep it at a higher level.

    This actually depends on cable length - it is not recommended to have a higher EQ level with a short cable distance (large gain is induced and could amplify noise on the link), and smaller EQ values should not be used for longer cables for attenuation.

    - In the case of AEQ, it is automatically set to a minimum, and if the stability threshold is exceeded, the EQ is incremented automatically."

    This is correct understanding.

    The MAP analysis allows for a visual representation on what the acceptable EQ values are.

    Best,

    Miguel

  • Hi.

    I will primarily use the AEQ settings, but during manual operation, I will pay attention to the cable length and the gain level.

    It has been very informative. Thank you.

    Best,