nhd-7.0-800480ef-atxv color issues

robincornelius

• September 22, 2015 09:07

Hi, i'm having a few issues with one of your displays. We have it connected to a PIC32MZ via a epson S1d13517. The design is based on the microchip Pictail Plus S1D13517 reference board.

The summary of the problem is that colors seem quite wrong on the display, as if i've lost some bits, or swapped some bits somewhere. I have checked the datasheets for the display, the epson chip and the PIC32 and cannot find any possible bit swapping anywhere.

I have tried setting the entire screen to a single shade of red with one bit set in the RGB color eg RGB(1<<c,0,0) where c was 0-7 i then looked at the RGB signal on the ribbon and found for each increment of c i only saw corresponding R0-R7 signals on the ribbon as expected, so that seems to be working perfectly.

The problem can be seen with the attached picture where i have drawn a 16x16 grid of grey boxes each box is one possible grey shade, horizontal is the upper nibble of the color and vert is the lower nibble. I also attach another test with various other gradients and it can be seen that the "brightness" is out of order.

if i run the same code on the reference board driving the Truly display, everything looks as expected. There are of cause minor differences between the two setups. Currently the NHD display is in 24bit color mode so i could try all combinations of colors, i was in 16bit mode and the reference board is always in 16bit mode. I've tried various clock and pixel timing settings but they make no difference until i push them to far then i get corruption.

I'm at a bit of a loss to what is actually wrong with the setup, so seeking any ideas.

I've attached one photo and had to make it smaller to fit the forum allowed size but I've also put some slightly higher rez photos on imagebin:-

actual result:-
http://imagebin.ca/2GWtoKUf2J0K/messedupgreys.jpg

expected result:-
http://imagebin.ca/2GWtcmGVr1ii/goodgreys.jpg

some other gradients on the NHD display :-
http://imagebin.ca/2GQNVajvJ9ru/IMG_0498.JPG


Thanks in advance,


Robin

0

• 

  Paul_B

  • September 24, 2015 11:07

  Hi Robin!
  
  Thank you for the information, it appears there is an issue with your data lines (RGB Data Signals).
  
  Can you please confirm that you are grounding the LSB's on our display when using 16bit mode.
  
  E.g.
  
  R0  -GND (LSB)
  R1 - GND
  R2 - GND
  R3
  R4
  R5
  R6
  R7
  R8 (MSB)
  
  G0  -GND (LSB)
  G1 - GND
  G2
  G3
  G4
  G5
  G6
  G7
  G8 (MSB)
  
  B0  -GND (LSB)
  B1 - GND
  B2 - GND
  B3
  B4
  B5
  B6
  B7
  B8 (MSB)
  
  
  Finally, can you please post the datasheet for the Truly display so I can look it over  
  
  Thanks!

  0
• 

  robincornelius

  • September 24, 2015 12:07

  Hi Thanks for the reply.
  
  I think i have actually got to the bottom of this.
  
  Although i checked the R0-R7 data lines (in 24bit mode) and saw data, it was not until i overlay the pixel clock that it started to become more obvious. I was missing 1/2 the data all the time, so every other pixel column was being set, which is what you can actually see in the grey scale plots i posted.
  
  The reason that every other pixel was set is due to two reasons, the cause of the issue and the way the data is stored in ram. The cause of the issue appears to be (and we will confirm 100% tomorrow) an incorrect SDRAM fitted , the one fitted has the 8bit data bus not the required 16. The difference in part number is two digits transposed in the middle of a long ish number so nobody spotted it. Due to the way the 8 bit version is configured it uses every *other* data pin compared to the 16bit version so if you scope the SDram you see data pins that send nothing when doing a read from ram (but have plenty of data on them when the framebuffer chip writes to them). As the data in memory is 24bits mapped into 16bit addresses the colors change from high to low bytes on each address read so when you look at the RGB signals on the FPC connector you see data but you are missing 50% of it.
  
  Hopefully tomorrow the correct SDRAM will arrive and it will all then just work correctly.

  0
• 

  Paul_B

  • September 25, 2015 12:07

  Hello!
  
  Thank you for sharing, sounds like your making progress.
  
  Looking forward to the final verdict  :)

  0
• 

  robincornelius

  • September 25, 2015 13:07

  Hi again, yep it was the RAM and the wrong type used display is working perfectly now. Just need to get the touch screen numbers correct and this bit is all working.
  
  thanks again.

  0
• 

  Paul_B

  • September 25, 2015 14:07

  Not a problem, have a great weekend!

  0

Please sign in to leave a comment.