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.
Dear Ti :
I encountered some problems when using the ds90ub949a-q1 EVM. I hope I can get help from ti.
Background: I have a project that uses ds90ub949-q1 as the serializer on the soc side, in conjunction with the screen's 948 deserializer, to light up the lvds screen.
Problem: I have a problem when I use i2c and ti949-q1 on the soc side to communicate: when I first supply power to the ti949 adapter board and then to the soc development board, I cannot read the ti949 registers. But when I cut off the power to the ti949 and then re powered it, the registers that I used the i2c tool to operate it can be read again.
However, in my project, the i2c communication between soc and ti949 is to be placed in the driver code, but I cannot guarantee the loading order of ti949 and driver. This also leads to the fact that the 949 cannot interact with the i2c code in the driver to truly light up the screen.
Best Regards,
Xinyu
Hello Xinyu,
I am not sure I understood your problem! Are you using 949 EVM or it is your own design?
What is the adapter board you are talking about and how it is connected to the 949 and SoC?
Does your SoC supports multi-Master arbitration?
Is your SoC and 949 using the same I2C bus?
Make sure the I2C bias voltage and pull-up resistors are datasheet compliant.
Also, please make sure your 949 power-up sequence is datasheet compliant.
Hello Jaradat,
Thank you for your reply,
I am not sure I understood your problem! Are you using 949 EVM or it is your own design?
>>>> I use the EVM of 949, not a product designed by ourselves
What is the adapter board you are talking about and how it is connected to the 949 and SoC?
>>>> There is no adapter board. The above "adapter board" refers to 949 evm
Does your SoC supports multi-Master arbitration?
>>>> Yes
Is your SoC and 949 using the same I2C bus?
>>>> Use the same I2c
Make sure the I2C bias voltage and pull-up resistors are datasheet compliant.
>>>> I don't know what part of the data table is in this part? Can you point it out?
Also, please make sure your 949 power-up sequence is datasheet complian
>>>> What is the power on sequence of this part?
Best Regards,
Xinyu
I believe your issue is the interaction between the I2C Master (Microcontroller) on the 949 EVM and your SoC. Once you power up the 949 EVM first, this microcontroller become the Master on the bust, but once you turn ON your SoC first, or power cycle the 949 EVM, then your SoC becomes the Master on the bust.
Please try to diactivate the I2C Master on the 949 EVM and test again.
Hello Jaradat:
Allow me to elaborate on my question:
As shown in the figure below
i2C Master attached to Serializer
In this configuration, DS90UB949 evm acts as a slave on the local I 2 C bus and DS90UB948 will act as a master proxy on the remote i2c bus
I need to communicate with the 948 serializer on the screen through the 949evm serializer. Realize functions such as lighting the screen and controlling touch
The screen is now lit, but there is a problem with the touch function. My touch screen can be understood as the remote slave device in the figure, and I can already communicate with him. However, since my touch is implemented in the cyclic mode (and only in the cyclic mode), that is, I will continuously read the data of the touch device on the screen through the i2c link of 949+948. It was normal at first, but i2c read failed after a period of time.
At this time, both the 949 EVM reading and the remote slave reading failed.
I can only read the 949 evm register again by re powering down and re powering on the 949 evm
This is all my current registers:
0x00 -> 0x18 0x01 -> 0x00 0x02 -> 0x00 0x03 -> 0xda 0x04 -> 0xa0 0x05 -> 0x00 0x06 -> 0x58 0x07 -> 0x60 0x08 -> 0x62 0x09 -> 0x00 0x0a -> 0x00 0x0b -> 0x00 0x0c -> 0x05 0x0d -> 0x20 0x0e -> 0x00 0x0f -> 0x00 0x10 -> 0x00 0x11 -> 0x00 0x12 -> 0x00 0x13 -> 0x88 0x14 -> 0x00 0x15 -> 0x00 0x16 -> 0x02 0x17 -> 0x1e 0x18 -> 0x7f 0x19 -> 0x7f 0x1a -> 0x01 0x1b -> 0x00 0x1c -> 0x00 0x1d -> 0x00 0x1e -> 0x01 0x1f -> 0x00 0x20 -> 0x4b 0x21 -> 0x00 0x22 -> 0x25 0x23 -> 0x00 0x24 -> 0x00 0x25 -> 0x00 0x26 -> 0x00 0x27 -> 0x00 0x28 -> 0x01 0x29 -> 0x20 0x2a -> 0x20 0x2b -> 0xa8 0x2c -> 0x00 0x2d -> 0x00 0x2e -> 0xa5 0x2f -> 0x5a 0x30 -> 0x00 0x31 -> 0x00 0x32 -> 0x00 0x33 -> 0x00 0x34 -> 0x00 0x35 -> 0x00 0x36 -> 0x00 0x37 -> 0x00 0x38 -> 0x00 0x39 -> 0x00 0x3a -> 0x00 0x3b -> 0x00 0x3c -> 0x00 0x3d -> 0x00 0x3e -> 0x00 0x3f -> 0x00 0x40 -> 0x14 0x41 -> 0x5c 0x42 -> 0x00 0x43 -> 0x00 0x44 -> 0x80 0x45 -> 0x00 0x46 -> 0x00 0x47 -> 0x00 0x48 -> 0x00 0x49 -> 0x00 0x4a -> 0x00 0x4b -> 0x00 0x4c -> 0x00 0x4d -> 0x00 0x4e -> 0x00 0x4f -> 0x00 0x50 -> 0x97 0x51 -> 0xa1 0x52 -> 0x1e 0x53 -> 0x00 0x54 -> 0x28 0x55 -> 0x0c 0x56 -> 0x1f 0x57 -> 0x00 0x58 -> 0x00 0x59 -> 0x00 0x5a -> 0xcd 0x5b -> 0x20 0x5c -> 0x42 0x5d -> 0x06 0x5e -> 0x44 0x5f -> 0x8c 0x60 -> 0x22 0x61 -> 0x02 0x62 -> 0x00 0x63 -> 0x00 0x64 -> 0x10 0x65 -> 0x00 0x66 -> 0x00 0x67 -> 0x00 0x68 -> 0x00 0x69 -> 0x00 0x6a -> 0x00 0x6b -> 0x00 0x6c -> 0x00 0x6d -> 0x00 0x6e -> 0x00 0x6f -> 0x00 0x70 -> 0x00 0x71 -> 0x00 0x72 -> 0x00 0x73 -> 0x00 0x74 -> 0x00 0x75 -> 0x00 0x76 -> 0x00 0x77 -> 0x00 0x78 -> 0x00 0x79 -> 0x00 0x7a -> 0x00 0x7b -> 0x00 0x7c -> 0x00 0x7d -> 0x00 0x7e -> 0x00 0x7f -> 0x00 0x80 -> 0x00 0x81 -> 0x00 0x82 -> 0x00 0x83 -> 0x00 0x84 -> 0x00 0x85 -> 0x00 0x86 -> 0x00 0x87 -> 0x00 0x88 -> 0x00 0x89 -> 0x00 0x8a -> 0x00 0x8b -> 0x00 0x8c -> 0x00 0x8d -> 0x00 0x8e -> 0x00 0x8f -> 0x00 0x90 -> 0x00 0x91 -> 0x00 0x92 -> 0x00 0x93 -> 0x00 0x94 -> 0x00 0x95 -> 0x00 0x96 -> 0x00 0x97 -> 0x00 0x98 -> 0x00 0x99 -> 0x00 0x9a -> 0x00 0x9b -> 0x00 0x9c -> 0x00 0x9d -> 0x00 0x9e -> 0x00 0x9f -> 0x00 0xa0 -> 0x00 0xa1 -> 0x00 0xa2 -> 0x00 0xa3 -> 0x00 0xa4 -> 0x00 0xa5 -> 0x00 0xa6 -> 0x00 0xa7 -> 0x00 0xa8 -> 0x00 0xa9 -> 0x00 0xaa -> 0x00 0xab -> 0x00 0xac -> 0x00 0xad -> 0x00 0xae -> 0x00 0xaf -> 0x00 0xb0 -> 0x00 0xb1 -> 0x00 0xb2 -> 0x00 0xb3 -> 0x00 0xb4 -> 0x00 0xb5 -> 0x00 0xb6 -> 0x00 0xb7 -> 0x00 0xb8 -> 0x00 0xb9 -> 0x00 0xba -> 0x00 0xbb -> 0x00 0xbc -> 0x00 0xbd -> 0x00 0xbe -> 0x00 0xbf -> 0x00 0xc0 -> 0x00 0xc1 -> 0x00 0xc2 -> 0xa8 0xc3 -> 0x00 0xc4 -> 0x68 0xc5 -> 0x00 0xc6 -> 0x00 0xc7 -> 0x60 0xc8 -> 0xc0 0xc9 -> 0x00 0xca -> 0x00 0xcb -> 0x00 0xcc -> 0x00 0xcd -> 0x00 0xce -> 0xff 0xcf -> 0x00 0xd0 -> 0x00 0xd1 -> 0x00 0xd2 -> 0x00 0xd3 -> 0x00 0xd4 -> 0x00 0xd5 -> 0x00 0xd6 -> 0x00 0xd7 -> 0x00 0xd8 -> 0x00 0xd9 -> 0x00 0xda -> 0x00 0xdb -> 0x00 0xdc -> 0x00 0xdd -> 0x00 0xde -> 0x00 0xdf -> 0x00 0xe0 -> 0x00 0xe1 -> 0x00 0xe2 -> 0xa8 0xe3 -> 0x00 0xe4 -> 0x68 0xe5 -> 0x38 0xe6 -> 0x00 0xe7 -> 0x00 0xe8 -> 0x00 0xe9 -> 0x00 0xea -> 0x00 0xeb -> 0x00 0xec -> 0x00 0xed -> 0x00 0xee -> 0x00 0xef -> 0x00 0xf0 -> 0x5f 0xf1 -> 0x55 0xf2 -> 0x42 0xf3 -> 0x39 0xf4 -> 0x34 0xf5 -> 0x39 0xf6 -> 0x00 0xf7 -> 0x00 0xf8 -> 0x00 0xf9 -> 0x00 0xfa -> 0x00 0xfb -> 0x00 0xfc -> 0x00 0xfd -> 0x00 0xfe -> 0x00
Best Regards,
Xinyu
Hello Xinyu,
Do you mean that after powering your system up you can communicate locally between the I2C Master and the UB949, and through that to the UB948 into the Touch screen, but after some time you can't communicate anymore, either locally or remotely?! Is my understanding correct?
If the above is correct, how long is the waiting time from working to non-working?
Are you doing any changes on the system during this time before it fails? Or you just keep cyclic reading? How often you do the reading?
Once there is no more reading is possible, do you still see LOCK on the UB948?
How do you recover this issue? You said resting the UB949 will allow local communication again, but what about UB948 and Touch screen?
Hello Jaradat:
1.Do you mean that after powering your system up you can communicate locally between the I2C Master and the UB949, and through that to the UB948 into the Touch screen, but after some time you can't communicate anymore, either locally or remotely?! Is my understanding correct?
If the above is correct, how long is the waiting time from working to non-working?
>>>> Your understanding is correct. It took about 1 minute from working to not working
2.Are you doing any changes on the system during this time before it fails? Or you just keep cyclic reading? How often you do the reading?
>>>> During this period, I will not make changes to the system, but read the data returned from the touch screen circularly.
The reading time of each cycle is 20ms.
3.Once there is no more reading is possible, do you still see LOCK on the UB948?
>>>> If I want to control the UB949 again, I can only power off the UB949 and then power it on again
4.How do you recover this issue?
>>>> Because the above UB949 suddenly loses control, in order to control the UB948 and touch device again, when the UB949 is powered off, the entire system needs to be powered on again.
This is because when the EVM is powered off, it means that the video signal and the entire control link of I2c are interrupted
5.You said resting the UB949 will allow local communication again, but what about UB948 and Touch screen?
For your convenience, the following figure shows my overall display architecture
>>>> As shown in the figure above
UB948 is designed in the screen and controlled by its own MCU architecture. All communication with UB948 and Touch devices should be through UB949. After the UB949 is disconnected, it can no longer communicate with the UB948 and Touch devices
Best Regards,
Xinyu
Hello Xinyu,
Thanks for the provided details. That makes things easier to understand!
I have some questions to you:
- Can you list all the registers from 949 and 948, that you are changing/configuring during your initialization?
- Please check if the 949 is the one holding the bus or if something else on the SoC side, or the SoC itself is holding the bus on the 949 side when this happens?
- When the issue happens, can you just PDB the 949 while keeping all the rest of the power? Does that restore the I2C communication to the 949?
- If you can manage access to the 948 board, can you probe the I2C bus of the 949 and the I2C bus of the 948 with a logic analyzer, along with the LOCK pin of the 948, all on the same window so we can see what exact sequence of events led to the lockup?
boardI2c.write( 0x04,0xa0) boardI2c.write(0x5B,0x20) boardI2c.write(0x16,0x02) boardI2c.write(0x07,0x60) boardI2c.write(0x08,0x62) boardI2c.write(0x1e,0x01) boardI2c.write(0x03,0xDA) boardI2c.write(0x5c,0x42)
Best Regards,
Xinyu
Hello Xinyu,
I guess these registers are configured on the 949, correct?
What do you re-configure the BCC Watchdog timer to only 2ms? Can you please use the default value, i.e., 0x7F and see if there is any improvement?!
>>>>On the Soc side, I2c used by 949 will connect multiple slave devices
Can you monitor this I2C bus using a scope or Logic analyzer and monitor all the I2C logs to see when is the bus getting stuck, after what transaction!?
Hello Jaradat,
I'm sorry to reply so late. Due to the overall design problem, 948 is designed on the screen, and I can't measure it. Because the I2c used by 949 EVM on the soc side is connected with multiple devices, the logic analyzer is not able to measure accurately.
But I found a way to improve. After the J9 jumper of EVM was pulled out, the above problems were improved a lot
This is the default setting. What is the reason?
Best Regards,
Xinyu
Hello Xinyu,
thanks for your feedback! That was actually one of the first questions I have asked you, if all I2C pull-ups and voltages are compliant!
It looks like your SoC or other I2C device is using different I2C voltage! You need to make sure all devices using the same I2C bus are using same I2C voltage
Hello Jaradat,
My SoC side I2c bus connects multiple devices.Each device on the I2c bus on the Soc side is connected with a 2.7k resistor and pulled to 3.3v. Does this affect EVM?
Unplug the jumper of J9, will it have a bad impact on the subsequent I2c communication?
Best Regards,
Xinyu
Hello Xinyu,
that Jumper gives you the option to select either 1.8V or 3.3V for the EVM I2C. So, in this case, you shall choose the 3.3V settings.