Artifacts on CrystalFontz LCD Display

Hello,

I am having artifacts displaying on my CrystalFontz lcd display. I am using a Mega 2560 a with glcd library. The artifacts do not display one the CF prototyping board: http://www.crystalfontz.com/product/CFA10006, and therefore seem to be limited to the arduino. All of the glcd examples show artifacts and pictures of the diagnostic are shown below.

Anything is appreciated, thank you.

Diagnostic Serial Output:

Serial initialized
--------------------------------------------------------------------
Reported Arduino Revision: 1.52
--------------------------------------------------------------------
GLCD Lib Configuration: glcd ver: 3 glcd_Device ver: 1 gText ver: 1
GLCD Lib build date: Mon Dec  5 01:50:07 CST 2011
GLCD Lib build number: 442
Panel Configuration:ks0108
Pin Configuration:ks0108-Mega
--------------------------------------------------------------------
GLCD:ks0108 DisplayWidth:128 DisplayHeight:64
Chips:2 ChipWidth:64 ChipHeight:64
 CSEL1:34(PIN_C3) CSEL2:33(PIN_C4)
 RW:35(PIN_C2) DI:36(PIN_C1) EN:37(PIN_C0)
 D0:22(PIN_A0) D1:23(PIN_A1) D2:24(PIN_A2) D3:25(PIN_A3)
 D4:26(PIN_A4) D5:27(PIN_A5) D6:28(PIN_A6) D7:29(PIN_A7)
Delays: tDDR:320 tAS:140 tDSW:200 tWH:450 tWL:450
ChipSelects: CHIP0:(34,0x1, 33,0x0) CHIP1:(34,0x0, 33,0x1)
Data mode: byte
--------------------------------------------------------------------
Diag Loop: 1
Initializing GLCD
Displaying ChipSelect Screens
Walking 1s data test
Wr/Rd Chip Select Test
Testing GLCD memory pages
Horizontal Page Test Chip: 0 Pixels 0-63
Vertical Page Test Chip: 0 Pixels 0-63
Horizontal Page Test Chip: 1 Pixels 64-127
 Verify error: (67,0) 3!=2
 Verify error: (71,0) 7!=6
 Verify error: (75,0) B!=A
 Verify error: (79,0) F!=E
 Verify error: (81,0) 11!=10
 Verify error: (83,0) 13!=12
 Verify error: (85,0) 15!=14
 Verify error: (87,0) 17!=16
 Verify error: (89,0) 19!=18
 Verify error: (91,0) 1B!=1A
 Verify error: (93,0) 1D!=1C
Vertical Page Test Chip: 1 Pixels 64-127
 Verify error: (64,0) 3!=40
 Verify error: (64,0) 7!=40
 Verify error: (65,0) F!=41
 Verify error: (66,0) 17!=42
 Verify error: (67,0) 1F!=43
 Verify error: (68,0) 23!=44
 Verify error: (68,0) 27!=44
 Verify error: (69,0) 2F!=45
 Verify error: (70,0) 33!=46
 Verify error: (70,0) 35!=46
 Verify error: (70,0) 37!=46
Full Module Horizontal Page Test:Pixels 0-127
 Verify error: (65,0) 41!=40
 Verify error: (67,0) 43!=42
 Verify error: (69,0) 45!=44
 Verify error: (71,0) 47!=46
 Verify error: (75,0) 4B!=4A
 Verify error: (77,0) 4D!=4C
 Verify error: (79,0) 4F!=4E
 Verify error: (81,0) 51!=50
 Verify error: (83,0) 53!=52
 Verify error: (85,0) 55!=54
 Verify error: (87,0) 57!=56
Full Module Vertical Page Test:Pixels 0-127
 Verify error: (64,0) 3!=40
 Verify error: (64,0) 7!=40
 Verify error: (65,0) F!=41
 Verify error: (66,0) 17!=42
 Verify error: (67,0) 1F!=43
 Verify error: (68,0) 23!=44
 Verify error: (68,0) 27!=44
 Verify error: (69,0) 2F!=45
 Verify error: (70,0) 33!=46
 Verify error: (70,0) 35!=46
 Verify error: (70,0) 37!=46
TEST FAILED

I don't support the GLCDv3 library anymore.
I've moved on to a new library (openGLCD) which is a derivative of this library.
openGLCD has many udates, bug fixes, and new features over GLCDv3.
It is licensed as GPL v3 vs LGPL 2.1+
So if you are are ok with GPL licensing I'd recommend moving to openGLCD:
https://bitbucket.org/bperrybap/openglcd

With respect to the display issues, those are almost always due to
some sort of wiring or configuration issue.
The output and pixel errors appear to show issues communicating with the right half of the display.
My guess at this point would be something related to the chip select lines.

It could be that the chip select wires are not making proper contact, or are broken internally,
or it could be that the display uses a different chip select line logic than the configuration that the library ships with.
i.e. the library comes with a default configuration that was picked based on what the vast
majority of glcds use for their chip select line logic. There are few out there that do not use the same
chip select line logic to select the two chips.

I've also seen similar strange issues when the control lines are mixed up, broken, shorted...
i.e. the rw, di, cs1, cs2 are not all wired up properly.

Another possibility is that there is an issue with the low level AVR port i/o pin mapping on
the mega2560.
I dont' have a mega board so I can't test the code on that platform, but others have used
it so I'm assuming that there were not any port mapping issues with the "out of the box" configuration.

However, if there is an AVR port mapping issue,
In order to debug and fix that type of issue, would require going to openGLCD as I am
no longer providing any support or updates to GLCDv3.
openGLCD also has additional capabilities like the ability to disable the direct port i/o.
While non direct port i/o is much slower it can be used to diagnose and eleminate any
potential direct port i/o issues.

Another thing that would be useful would be know what the diagnostic does
to the display at the begining during the chip select tests.
Maybe you could post a video of that somewhere?

Let me know if you want to switch over to openGLCD and then I can help further.
In order to diagnose further, I'll also need to see the datasheet for the exact glcd you are using.

--- bill

Alright.
So the initial issue with the artifacts came out as a dud since the screen died a week later.
I have a new screen now and with that is a new setup and new set of problems. This comes in the form of a large black bar on the top half of the screen spanning both chips. My current setup is a Mega Pro 5V from Sparkfun (https://www.sparkfun.com/products/11007) another Crystalfontz screen (http://www.crystalfontz.com/product/CFAG12864BTFHV, http://www.crystalfontz.com/products/document/1749/CFAG12864BTFHV_v3.0.pdf) and a ribbon cable connecting the two.
I already checked the wiring through the ribbon cable by running jumper wires from a crystalfontz prototype board to the ribbon cable header and the screen ran fine, which leads me to believe that the issue lies somewhere in the board-program area. I did make the switch up to openGLCD and also found that the issue lies somewhere in initialization since the black bar pops up on running Init(); and remains static through the duration of the run. Attached is a Diags iteration of the run as well as a serial output below.

A couple things to note:
-Chip select lines are swapped to account for swapped screen sides
-Pinout lines are changed for ease of hookup in project. They are displayed below and give the same result when reset to default

  • The noise created on the black bar at init() is different each run but remains unchanged during the run.

Thanks for all the help,
HG

Serial initialized
--------------------------------------------------------------------
Reported Arduino Revision: 1.5.2
F_CPU: 16000000
--------------------------------------------------------------------
Lib Configuration: openGLCD ver: 0.8a-27 build: v0.8a-27-g62cf169
Panel Configuration:ks0108-128x64
Pin Configuration:ks0108-Mega
--------------------------------------------------------------------
GLCD:ks0108 DisplayWidth:128 DisplayHeight:64
Chips:2 ChipWidth:64 ChipHeight:64
 CSEL1:35(PIN_C2) CSEL2:36(PIN_C1)
 RW:38(PIN_D7) DI:39(PIN_G2) EN:40(PIN_G1)
 D0:27(PIN_A5) D1:28(PIN_A6) D2:29(PIN_A7) D3:30(PIN_C7)
 D4:31(PIN_C6) D5:32(PIN_C5) D6:33(PIN_C4) D7:34(PIN_C3)
Delays: tDDR:320 tAS:140 tDSW:200 tWH:450 tWL:450
ChipSelects: CHIP0:(35,0x1, 36,0x0) CHIP1:(35,0x0, 36,0x1)
Data mode: 
 d0-d3:bit i/o
 d4-d7:bit i/o
Backlight: <Not configured>
--------------------------------------------------------------------
Diag Loop: 1
Initializing openGLCD
Displaying Library version Screen
Turning display & backlight on/off
Displaying ChipSelect Screens
Walking 1s data test
 Compare error: 14 != 4
 Compare error: 14 != 10
TEST FAILED

Screen problems.mp4 (2.37 MB)

It is difficult to tell what is happening.
I have seen this kind of behavior before, and usually it is due to broken wires, wires making poor contact,
or incorrectly connected wires.
It appears that something is strange on data bits 2 and 4 so I'd look closely at those wires.

Can you post a connection table of how each of the Arduino pins is connected to the GLCD,
just so I can verify them?

THANK YOU, it works now!
I swapped out pins 29 and 31 (data line 2&4) to pins 4 and 5 and it works now. This makes sense since the pins are right next to each other on the mega. when i tested them with a voltmeter it appeared shorted so I will be looking into whether it was soldering or a faulty board.
Thanks again
HG

For posterity:
Original Configuration:
Data line 0-7 -> 27-34

CSEL1 36
CSEL2 35
RES 37
RW 38
DI 39
EN 40

Sounds like it is all working now.

Just a bit of followup on the chip selects being “backwards”.
In reality they are not backwards but rather a misconfiguration between
your glcd and the default ks0108 panel configuration file.
The data sheet that you have shows the chip select pins being active low.
Most 128x64 ks0108 modules use active high chip selects.

The default 128x64 ks0108 panel file uses active high logic for the chip selects.
You can see this by looking at the ks0108 panel file or at the diag output.
In the diag output note these lines:

CSEL1:35(PIN_C2) CSEL2:36(PIN_C1)
ChipSelects: CHIP0:(35,0x1, 36,0x0) CHIP1:(35,0x0, 36,0x1)

That shows that CS1 is connected to Arduino pin 35 and CS2 is Arduino pin 36
and that to address chip0 you set CS1 high and CS2 low
and to address chip 1 you set CS1 low and CS2 high.

The datasheet shows CS1 (glcd pin 12) and CS2 (glcd pin 13) as active low.
This doesn’t match the default ks0108 configuration.
While technically to fix it, the ks0108 panel config file would have to
be modified, when you only have two chips and two chipselect lines
you can also make it work by just flipping the wires to the glcd CS1 and CS2 pins.

Switching the chip select wires in many cases is easier than editing the panel config file,
but in reality the chip selects weren’t backwards, it was that the ks0108 panel config file
chip select definitions file didn’t agree with the glcd module.

Another thing to consider is that if you want the maximum speed, the data line
Arduino pins need to be selected carefully. If you select them such that the bits in the AVR port
align with the data bits i.e. bit 0 is bit 0 of the AVR port, … up to bit 7, then the library
will use nibble or byte mode which is faster than using bit i/o on all the individual bits.
byte mode if all 7 align and are in the same AVR port
and nibble mode if only the upper or lower 4 bits align or if all 8 bits are not in the same AVR port.

— bill