CFAX12864CP1-WGH-TS "Weirdness"

[occam49]

I have a CFAX12864CP1-WGH-TS mounted on a PCB that I acquired from Spark Fun.

1.) It seems that when writing to the display, the first column is actually 4 not 0!! Try writing to positions 0 through 3 and nada. This is kinda bizarre, and the data sheet for the controller does not say anything about this!!! The Spark Fun example code did not reflect this "little" gotcha because that code flips the display 180 degrees about both axes and is effectively writing from position 133 to position 0, thus masking the 4 position column "0" offset issue. After beating my head against the wall, I was able to confirm this by examining the Crystalfontz example Windows code!!!! I made the necessary work-around adjustments to my code.

2.) Writing to the display works, but when I read a column on a page, bit 7 is always set!!!. I'm pretty sure my connections are OK since all commands to write the screen and control the device work. For example, I can send 0xFF to each column on each page, and the screen is black. When I read back I get 0xFF for each column on each page, I can write 0x00 to each column on each page and the screen is cleared. However when I read back each column each page, the return value is 0x80 so bit 7 is set on each column of each page read, but the screen is blank!! I'm at a loss to figure this out. Is this a unit defect? So, I ask, what's going on?

If this is an inherently flaky device, does Crystalfontz have something else with a touchscreen that is similar

TIA

Darrell

Crystalfontz LCD Blog

Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

 

[CF Tech]

The starting address is in the data sheet, but it is kind of buried in the Display Data RAM on page 10:

I do not know what could be going on with bit 7 stuck on the reads. Can you try writing a "walking one" test to the display, and reading it back:

00000001
00000010
00000100
00001000
00010000
00100000
01000000
10000000

Then try writing a "walking zero" test to the display, and reading it back:

11111110
11111101
11111011
11110111
11101111
11011111
10111111
01111111

One of those may shed some light on what is going on.

This display is not "inherently flaky"--or we would not offer it!. It is used by several OEMs in quantity with success.

Please give the test above a shot and let us know what comes of it.

 

[occam49]

Well ... you're right, it is in the documentation albeit a bit of a "subtle" reference . It definitely falls into the class of once you understand what is going on, you can understand the documentation! I don't recall the helpful blue annotations .

I'll give your suggested tests a try and get back to you with my findings ...

Thanks for the prompt response.

Darrell

 

[cosmicvoid]

In your read of data from the display, are you doing the "dummy" read before the data read? It might be helpful if you posted your I/O routines.

 

[occam49]

Experiment complete: I walked a '1' ,and a '0' through all pages, and bit 8 IS stuck when I read the display RAM, but the display IS correct ??!!! Except for bit-8, all write/reads are correct for all pages and all columns.

I tried placing a 47K resistor to ground on pin D-7, and get the same results.

What now ?? Has anyone else seen this problem?

Darrell

 

[occam49]

@cosmicvoid

Yes I do the dummy read.

I don't think it's the routines since all reads (and all writes for that matter) except bit-7 are copacetic.

Darrell


BTW ... there is no such thing as a void in the cosmos ... dark matter is everywhere, or so they say . On the other hand if you follow the "multi-versers", anything is possible. Very interesting article in the latest Discover magazine.

 

[CF Tech]

Hmmmm. I guess the circuit on the display controller that drives bit 7 could have been damaged.

To verify one more thing . . . is this a prototype? Could you switch say bit 6 and 7--after the display is initialized? If the problem then moves to b6, it is in the display, if it stays at b7 then it would have to be the processor or code.

Is there a "special function" on b7 of the processor that might be interfering? Is there something like a signed/unsigned type issue?

Posting your read code for cosmic to look over is a good idea. Many problems are found that way in this forum.

We can get you a replacement display if all the problems point to the hardware.

 

[occam49]

OK.... This is due to a defect in the commercial development board I'm using. With the processor module removed, I get a an 11K ohm short between the bit-7 pin and VCC!!! The relatively high resistance of this short allowed it to be driven low on output, but stuck the input high!!!! What a freaking waste of time !!!! Sorry for the trouble.

 

[CF Tech]

Hey, no trouble. I am glad you were able to track down the cause.

Please feel free to post back if you have any questions.

Also, we always appreciate any demo code posted to the forum, so if your demo code is something that you can (and want to) release, I am sure someone will find it useful when they do a similar project.