• State TI Thinks Resolved
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 35 subscribers
  • Views 73 views
  • Users 0 members are here
Support feedback
Options
Options
Related

DS90UB941AS-Q1EVM: The screen display is normal, but the i2c communication is abnorma

zhao yunlong
Prodigy 10 points

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

soc-------ds90ub941--------ds90ub948------------lcd 

The screen can display normally, but the i2c communication is abnormal. It can read 941, but cannot read or write 948 and tp

Register information dumped after the problem occurred:

96b62660-fb3d-4db9-a982-c55a71f69e24.png

  • 0
    TI__Genius 11886 points

    Hi Zhao,

    Thanks for the 941 register dump, this is helpful information. I've got a few questions about the test setup and what you have tested so far:

    1. How are you communicating to the FPD devices? Is it via a micro USB to onboard USB2ANY, an Aardvark over the I2C pins, etc.?
    2. Are these TI EVMs or custom designed boards?
    3. Have you tried connecting directly to the local 948 I2C bus to see if it responds?
    4. Do you have any initialization code you ran before this register dump that you can provide?
    5. Do you have a logic analyzer capture of the I2C transactions you attempt to send to the 948?

    BR,

    Cameron

  • 0
    Prodigy 40 points

    1.In the automotive field, the i2c of ds90ub941 is connected to the soc

    2.During real vehicle testing, we encountered an issue where the i2c of the 948 could not be directly connected to the SOC, nor could it be tested using a logic analyzer

    3.Initialization code

    ds90ub941:

     0x03, 0x9a
    0x17, 0x9e
    0x01, 0x08 //Disable DSI
    0x11, 0x33 //Disable DSI
    0x5b, 0x10 //select dsi pll colck
    0x40, 0x04 //Select DSI Port 0 digital registers
    0x41, 0x20 //Select DSI_CONFIG_0 register
    0x42, 0x6f //Set DSI_SYNC_PULSES = 0
    0x41, 0x21 //Select DSI_CONFIG_1 register
    0x42, 0x60 //Set DSI_VS_POLARITY=DSI_HS_POLARITY=1
    0x4f, 0x8c //Set DSI_CONTINUOUS_CLOCK, single DSI, 4 lanes, DSI Port 0 input
    0x41, 0x30 //Select DSI_HSW_CFG_HI register
    0x42, 0x00
    0x41, 0x31 //Select DSI_HSW_CFG_LO register
    0x42, 0x18 //hsync-len = 12
    0x41, 0x32 //Select DSI_VSW_CFG_HI register
    0x42, 0x00
    0x41, 0x33 //Select DSI_VSW_CFG_LO register
    0x42, 0x03 //hsync-len = 3
    0x40, 0x04 //Select DSI Port 0 digital registers
    0x41, 0x05 //TSKIP_CNT set indirect addr (reg DPHY_SKIP_TIMING)
    0x42, 0x2E //TSKIP_CNT set reg DPHY_SKIP_TIMING value
    0x40, 0x10
    0x41, 0x86
    0x42, 0x0A
    0x41, 0x94
    0x42, 0x0A
    0x0e, 0x3f //TP_INT BL_EN
    0x0f, 0x03 //PWM
    0x10, 0x03 //TP_RST NULL
    0x01, 0x00 //Enable DSI
    ds90ub948-q1:
    0x01, 0x03 //reset 948
    0x49, 0x60 //Dual FPD/OLDI output
    0x21, 0x13 //GPIO_7_8:TP_FAIL_DET input,lcd_reset output low
    0x34, 0x02 //Selects Port 1
    0x1e, 0x01 //DGPIO_1:lcd_stb output low
    0x46, 0x60 //Dual FPD/OLDI output
    0x34, 0x02 //Selects Port 1
    0x1d, 0x09 //DGPIO_0:tp_3v3 set to hight
    0x34, 0x01 //Selects Port 0
    0x1a, 0x19 //GPIO_9:lcd_3V3 set to hight
    0x34, 0x02 //Selects Port 1
    0x1f, 0x09 //DGPIO_3:bias_en set to hight
    0x34, 0x01 //Selects Port 0
    0x20, 0x09 //GPIO_6:tp_reset output hight
    0x21, 0x93 //GPIO_7_8:TP_FAIL_DET input,lcd_reset output hight
    0x34, 0x02 //Selects Port 1
    0x1e, 0x09 //DGPIO_1:lcd_stb output hight
    0x34, 0x01 //Selects Port 0
    0x1d, 0x03 //GPIO_0:MPQ3367_FAIL_DET
    0x1e, 0x53 //gpio_1_2:tp_irq bl_en
    0x1f, 0x05 //gpio_3:pwm
    4.If the value of the 0x0c register of ds90ub941 is 0x16, the link should be completely blocked. Why is the video signal normal? Only the i2c is abnormal
  • 0 in reply to yunlong zhao
    TI__Genius 11886 points

    Hello,

    Thank you for the additional information. Can you confirm if the unit is still in the vehicle or if it was moved to a bench?

    I would like to understand a few more things:

    • Has this failure occurred once or has this been reproduced? If more than once, how many times and on how many chips?
    • Have you attempted to recover the system at all?
    • Does the system recover after a soft reset to the serializer? (i.e., board.WriteI2C(serAddr, 0x1, 0x1))
    • Does the system recover after a power cycle of both the serializer and deserializer?

    I also noticed that in registers 0xA and 0xB of the 941, that there are a large amount of CRC errors on the link. This usually indicates a link integrity issue with the FPD channel, especially since you stated the 948 works and can communicate initially, but then goes bad after some period of time. You could try changing out the FPD cable to see if the issue is being caused by a faulty cable. Has a schematic review or layout review been completed by TI for this design in the past?

    BR,

    Cameron

  • 0 in reply to Cameron Hoholik-Carlson
    Prodigy 40 points

    1.The problem only occurred on the vehicle. Currently, the equipment is still on the vehicle.

    2.It occurred twice, with the same vehicle and equipment.

    3.It is impossible to perform a soft reset on the vehicle.

    4.After restarting the device, it displayed a black screen without any display. However, plugging and unplugging the screen cable restored the normal operation.

    5.The problem should be related to the screen connection cable, but why does this situation only affect the I2C signal? The video signal is normal.

  • 0 in reply to yunlong zhao
    TI__Genius 11886 points

    Hello,

    Thank you for providing the additional information. 

    yunlong zhao said:
    5.The problem should be related to the screen connection cable, but why does this situation only affect the I2C signal? The video signal is normal.

    Since video seems to be functioning while the 941AS is reporting no link/lock and no I2C communication to the 948, it sounds like there is a gross back-channel margin issue. This is backed up by the fact that there are a large amount of back-channel CRC errors, further indicating an issue with the back channel.

    My first recommendation would be to change the cable being used for a new one. This should eliminate any potential issues with the cable. Is this a coax implementation or an STP implementation?

    My second recommendation would be to send the schematics for your 941 and 948 for me to review. 

    If these two things don't reveal anything, we will need to likely have the problematic units taken out of the vehicle and instrumented on a bench for testing. This would be to see if the issue follows the deserializer, and to be able to run custom I2C transactions to the units.

    Could you additionally confirm if this issue is seen right after start-up or if it occurs after a period of time? And is this on a 0km vehicle?

    BR,

    Cameron

  • 0 in reply to Cameron Hoholik-Carlson
    Prodigy 40 points

    At present, this problem has been resolved after reconnecting the screen cable, and it has not occurred again.

  • 0 in reply to yunlong zhao
    TI__Genius 11886 points

    Hello,

    yunlong zhao said:
    At present, this problem has been resolved after reconnecting the screen cable, and it has not occurred again.

    Glad to hear the issue appears to be resolved. I would recommend monitoring registers 0xA and 0xB on the main page of the serializer to check for large amounts of CRC errors. My guess is that the cable wasn't fully seated correctly and was causing a marginal link between the serializer and deserializer, resulting in the issue you saw.

    I am going to close out the thread for now, but feel free to reply again to open it if you have additional problems regarding this issue.

    BR,

    Cameron

  • 0 in reply to Cameron Hoholik-Carlson
    Prodigy 40 points

    Monitor the 0x0a and 0x0b registers on the serializer. If a large number of CRC errors are detected, is there a way to perform a soft reset to restore normal communication?

  • 0 in reply to yunlong zhao
    TI__Genius 11886 points

    Hello,

    Yes, you can attempt a soft reset by writing a value of 0x1 to register 0x1 to the device:

    • board.WriteI2C(devAddr, 0x1, 0x1)

    Please note: this will interrupt video to the display temporarily while the reset occurs. 

    BR,

    Cameron