Some interesting news!
Am 05.03.2014 um 12:40 schrieb Dr. H. Nikolaus Schaller:
Hi, for the records...
I have checked the hardware with the new R63311 data sheet and did not find issues.
The panel is wired as "VSP and VSN: External supply Method" (Fig. 3 on page 26)
Except that there is a DBIST input hard wired to "0". It can be interpreted as disabling the test pattern mode completely - or it can be interpreted as not enabling it unless software does.
Then, I did check and verify the capacitors we find external to the controller chip on the panel's fFPC. All voltages fit to the data sheet and appear to be ok (what I don't know is if +/- 6.5V is the right voltage to drive the liquid crystal - but I assume it is ok).
I should also note that the charge pump stops if I issue the 10h DCS command and most voltages are switched off.
Since
- there are not many other pins on the display connector and
- I have checked the data/clock lanes for correct assignment and
3, we can read/write DCS commands, I conclude that it is very unlikely that we still have an undetected hardware error on our adapter.
Another though on the pattern we see. It is comprised of fine vertical stripes - but all in grey. I did now understand that the R63311 chip has 1080 output drivers and those are most likeley driving the *columns*. So if we see *rows* of stripes this would mean that the panel is vertically scanning - but the 1080 column values all have constant output signals.
What could that mean? Maybe that our horizontal sync is not working properly. So even if we send data to the panel in RGB lines, the drivers are not changed/updated as needed.
This could have several reasons:
- we do not have hsync bursts in the video data (so that the panel is not switching to the next line)
- the timing of the hsync bursts may be wrong in relation to what the R63311 can accept
- the washing out effect of the corners may also come from such a missing hsync (since a panel usually inverts the voltage after each full frame)
So again some more ideas where to look into.
Note: this all does not explain why I can't read the BFH chip id data through DCS.
I have checked what the initialization code is (trying to) program into the panel:
This means that the Panel voltges should be 9.0 V and not the 6 V I can measure!
The only conclusion I can draw is that the panel is not executing manufacturer specific commands. Neither setting the panel nor reading the chip ID.
But it is handling (most) "standard" DCS commands.
It turns out that it is even worse: if I issue the same write command from the /sys interface (after it had been sent during initialization) - the panel controller gets stuck and non-responsive.
That is really strange but may be a hint where the problem is.
BR, Nikolaus