Hi, at the moment i would like to connect a Riverdi Display with singel RVDI to the DSI to RVDI Adapter. Now I can’t find my way around the designations in the Toradex data sheet. These are very different from the data sheet from Riverdi.
can anyone help me?
Reverdi.pdf (1.5 MB)
verdin.pdf (312.6 KB)
I’m going to assume you mean LVDS instead of RVDI, but correct me if I’m wrong.
As for the connections I see both the main connectors are 40-pin connectors though the terminology is a bit different. Since your display is single channel it seems we only need to pay attention Channel A connections on the LVDS adapter. Therefore, this is my educated guess of what corresponds to what:
- LVDS_1_A_TX3_P → Rxin3+ (notice the P at the end stands of the verdin notation stands for positive, also the 3 in both notation indicate the data lane)
- LVDS_1_A_TX3_N → Rxin3- (notice the N at the end stands of the verdin notation stands for negative, also the 3 in both notation indicate the data lane)
- Based off this you can extrapolate how the other 3 data lines match up.
- The 3.3 Power supplies and grounds should match up and be obvious
- The LED connections on the Riverdi side, I’m not sure it’s not obvious what purpose these LEDs serve, but I assume their not vital.
- Everything else on the Riverdi side should be no connection.
At least this is my best assumption on how the signals match up. You may need to guess and check however. I hope I helped clear things up a bit.
Hey @jeremias.tx ,
yes of course LVDS… the weekend was calling
thanks. We will check this and start a request for the led pins at riverdi.
Please let us know how it works out, when you get a chance.
So LED+ and LED- is necessary for the backlight. A constant current source is required for the control. The DC/DC converter (PAM2423) on the DSI/LVDS adapter from you is unfortunately not designed for this. Riverdi recommends the TPS61500 converter. We will now simulate the constant current source for the development with a laboratory power supply.
Now we have done the hardware wiring. According to the timings in the data sheet of Riverdi we have created a dtsoverlay file and inserted according to the instructions of toradex. The result is unfortunately sobering, the display remains black. Do you recognize an error for this?
Riverdi_Timings.pdf (1.1 MB)
verdin-imx8mm_sn65dsi84_RVT101HVLNWCOO_overlay.dts (2.5 KB)
First we need to get more information since there’s many possible reasons that would result in a black display.
the display remains black
To clarify when you say the display is “black”. Do you mean that there is no backlight, or there is a backlight and nothing is being displayed?
Furthermore if you check the
dmesg output of the device do you notice any messages related to the display subsystem, or MIPI-DSI, or any of the other interfaces you modified in your device tree overlay?
Finally if possible, if you probe the lines physically with a scope or similar tool, do you see activity on the lines? This is just to make sure the connection is good and the software is sending signals of some kind at least.
the backlight was visible. But following your tip to look into the dmesg, we noticed that the devicetree overlay file was not included correctly (or we did not include it correctly). Furthermore, we had the wrong version of the devicetree files (the devicetree files did not match the BSP). There was a version conflict there.
Nevertheless, we still have a problem. As you can see in the videos, we often have problems with the image transfer. In some cases, however, the image is displayed very clearly (such as the Torizon logo or the Linux boot sequence).
Now we don’t know what exactly the problem is. Could this be due to the display timings? We have already tried many things in this regard, but Riverdi uses a different synatax and other definitions for the timings.
Link to the videos (HiDrive)
Okay just to check then, so after fixing the version conflict and such, the display is "working now? I mean it’s not black anymore and is displaying as seen in your videos.
The issue with the screen “glitching” out though is odd. I don’t think it’s a timing issue. Usually if the timings were incorrect the issue would be persistent instead of only happening as seen in your videos. Could possibly be a connection issue? Or maybe a clock issue?
It’s honestly quite hard to tell without a more in-depth analysis. What might be needed is to put some signal scopes on the hardware connections. This might help us tell whether the issue is rooted in software or hardware. Otherwise I can’t provide much insight.
yes now the display works as you see it in the video.
We have now also looked again at the signal traces and seen that the “glitching” must come from our cable. We now have a very “clean” picture.
Now we start with the next challenge. The integration of the touch control.
Perfect glad to hear the display is working now!