CFAG320240 Write Problems

[JackOfVA]

I'm seeing an intermittent problem writing to a CFAG320240 display.

I'm writing to it with an 18F458 PIC Microcontroller and it's easiest to explain the problem with a screen shot or two.
I've included a photo of the checkerboard test pattern, as it should look. (Alternates white/dark squares every 500 ms.)

Intermittently, the display locks up and the area outside the legal writing area displays a pattern. Sometimes the diagonal lines shown in the attached photo, and sometimes solid white.

I'm can't immediately see how to attach two photos, so if it does not show up in this one, I'll put the bad image photo in a second message.

The PIC continues to send data to the display, but commands appear not to be executed. All the evidence available to me (looking at data flows with the oscilloscope) indicates that the problem is not with the software logic in my program.

Sometimes, the test pattern will be written to the display, but shifted.

I am intentionally not limiting writes to the retrace interval, as the real application is already slower than I would like. I can live with flicker in exchange for faster data transfer.

I'm running in 6800 mode.

Here's what I've tried, but without success:

1. Verified that all timing intervals are within the limits. Intentionally lengthened the into/out E interval to be 1.6us LOW, followed by 1.6us HIGH. All data is stable before the 1.6US low period.

2. To double check timing issues, the program is now running with the PIC clock at 10 MHz (real program is at 40 MHz) so that all bus writes are nice and slow.

3. I thought the problem might be the cursor not being correctly updated and hence the image data was not being written to a memory address within the display window. I revised the write routine to read back the cursor address and repeat setting the cursor address until it reads the same as the target address. This has not changed the problem.

4. This has some elements of a hardware problem, such as power glitch, so I've tried a couple different ways of powering the display, without any change in behavior.

The period of good operation is variable, and has run between 5 minutes and 1.5 hours.

The code that generates the checkerboard pattern also does a memory clear before writing each checkerboard so if the cursor address were mangled in one write procedure, it would, I believe, be corrected during one of the successive write procedures. This seems not to be happening, as once the display goes into the bad mode, it stays in that mode, regardless of clear memory writes by the PIC. Hence, I've tentatively concluded, when combined with the cursor-read cross check, that the problem is not with cursor addressing.

Another possibility I'm considering is that somehow the setup registers are getting mangled somehow. Not clear how to verify that, as the setup registers can't be read, near as I can tell from the controller data sheet.

I'm hoping that someone else has experienced this problem, and that perhaps the out-of-bounds lines will help identify my problem.


Jack

Crystalfontz LCD Blog

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

 

[JackOfVA]

Herre's the good image.

 

[JackOfVA]

Here's the bad image. Note the artifacts at the top of the screen, outside the legal write area.

 

[cosmicvoid]

1. Verified that all timing intervals are within the limits. Intentionally lengthened the into/out E interval to be 1.6us LOW, followed by 1.6us HIGH. All data is stable before the 1.6US low period.

I have no experience with this specific display. That said, I think its peculiar to have the E signal be high as a quiescent state. All my usage of these kinds of displays involves keeping E low normally, and then doing the ->high->low pulse during the write routine. Have you tried that.

Or am I misinterpreting what you're doing?

 

[JackOfVA]

In the normal state in my code E is low.

Here's the code for WriteByte (similar code for WriteControlByte, except for status line difference that differentiates a data byte from a control byte.)

I added the NOPs to make sure that all the data and control parameters were set before taking EE high and provide a longer high. Didn't make any difference, so I don't think that's the problem, at least with a 10 MHz clock (each NOP instruction takes 200ns.)

Public Inline Sub WriteData(DataByte as Byte) 
'-------------------------------------
   DatPort  = DataByte //assert data on bus - give it time to settle
   A0 = %0             //CLEAR A0 -- this determines that the data is intrepreted as data by LCD
   CS = %0             //CLEAR CS
   E  = %1              //SET E    -- data is read on falling edge of E.
   ASM                 // E must be high at least 120ns
      NOP
      NOP
      NOP
   End ASM 
   E  = %0              //CLEAR E  -- here's the falling edge
   ASM                 // E must be high at least 120ns
      NOP
      NOP
      NOP
   End ASM 
   CS = %1             //SET CS
end sub   // WriteData

 

[cosmicvoid]

Hmmm, OK.

When the "bad screen" occurs, do you see an abnormal voltage on the Vo pin?

Are your cables/wires too long, and maybe your control signals are ringing?

As for the setup registers getting corrupted, I've seen code for some commercial products that will periodically reinitialize the display, just to guard against such problems.

Is the cure for the lockup to power down, or will giving the controller a reset bring it back to life?

 

[JackOfVA]

Vo looks normal.

The cable between the display and the PIC board is a 20-wire ribbon cable, somewhere between 8 and 10 inches long. Scope on the PIC end of the cable shows normal logic levels, no sign of ground bounce, ringing or overshoot. (400 MHz scope, so it should see even narrow pulses.)

I had added an automatic display reset and initialization to some experimental code. It worked, but not something you want in releasable code.

I have not tried initialization only, without the display reset in the test code, but will give it a run tomorrow.

To get the display working again, all I need to do is reboot the PIC. No need to remove power from the display. The initialization code in the PIC program performs a reset on the LCD display and that seems adequate to restore operation. Hence, the controller is not locking up hard; it just seems to have lost its moorings.

 

[cosmicvoid]

Scope on the PIC end of the cable shows normal logic levels, no sign of ground bounce, ringing or overshoot.

What about on the CFAG end of the cable, where it matters? If ringing, maybe a damping resistor(s) would help.

Try adding a bypass cap (100uF tant paralleled w/ 0.1uF ceramic) at pins 1&2 of the CFAG.

I know what you mean about not having kludge code in the release version. But consider the added robustness of being able to recover from unexpected things like this, automatically. People might wonder about the display glitching (at a recovery reset) once in a while, but for sure they will notice if it locks up.

I don't have any other ideas right now.

 

[JackOfVA]

The automatic reset code I had added tried to detect a lock-up condition by writing a test byte to an unused part of the memory and then reading the byte back periodically.

If the sentinel byte didn't match the expected value, the code issued a RESET instruction to the PIC, and it went through a complete power-down restart.

This approach was intended to catch a problem caused by memory corruption, whereby the screen data would be correctly written, but would be in the wrong place. The sentinel byte was just outside the screen display RAM so my theory was that a bad memory write would overwrite the sentinel byte and hence errors would be detected.

This did not trap the blank screen problem, although it would force a reset a couple times a day. Hence, my thoughts turned towards corruption of the LCD's configuration registers.--the data is correctly written to memory, but the display controller mis-intreperts the data.

That degree of restart (involving displaying the text setup screen, initializing variables, etc.) isn't necessary and I can revise the code to only restart the display.

In any case, you've given me a couple god ideas. I wll look at the LCD end of the cable. The cable is unterminated.

Will also add a routine that periodically refreshes display configuration registers without also causing a display reset and see what happens.

Thanks for the suggestions.

 

[JackOfVA]

Looks like something is trashing the display's configuration register(s).

I added code to re-write the configuration registers once every 30 seconds or so and that prevents the problem.

Will know for sure after a longer stability test, but looks good at the moment.

More work to be done here to determine why the configuration is trashed, but this is a start and can be used in final code, if necessary, as the refresh isn't too noticeable.

Jack

 

[CF Tech]

Look for noise on the LCD's power supply (probe Vdd to Vss at the LCD during activity) and look for bouncing on the "E" line. Either of those could cause trouble.

 

[JackOfVA]

Will look for noise.

Thanks. It's been frustrating but I can see signs of success now.

Jack

 

[JackOfVA]

Here's the E line (Chan 1) and the +5V line , measured at the display (AC coupled vertical).

The ground bounce on Channel 1 is, in large part, due to long ground lead on the scope probe.

There's more noise than I expected on the +5V line, so some additional filtering will be in order.

The E pulse does not look too bad to me, but would appreciate other opinions.

Jack

 

[cosmicvoid]

I would shorten up the probe ground lead to see what the signal *really* looks like. Except for the overshoots, pretty good looking.

 

[JackOfVA]

With a periodic register refresh, It's working well enough to continue work on the project.

Will report back when a better PCB layout is in place, probably around the end of March.

Thanks everyone for the suggestions.


Jack

 

[Henri]

That sounds familiar. Few years ago I experienced intermittent display blanking with CFAG320240.

I don't remember all the details but it was a new project and a new CFAG320240 module so naturally I spent some time trying to figure out what I was doing wrong to cause that and tried all kind things. Wasn't my first CFAG320240 though so things should have been working.
Finally I swapped another new CFAG320240 there and magically everything was working and no more problems.

I did spend some more time later with the module and I believe the problems didn't appear immediately, only after a while when the module had heated up a bit.
I might have traced the problems to the reset input of the S1D13305. Might have even used a soldering iron in some point there. If I got it working better I don't remember but that unit was put out of duty as I didn't want it taking any more of my time.

But the point here was that my problem was fixed by swapping the lcd to a new one.

 

[JackOfVA]

Henri:

Thanks for the report.

I've been putting off ordering a second display module until my PCB and cabinet layout is further along. Will have to accelerate that and spend the money on a second LCB module.

With luck that will fix the problem.


Jack

 

[JackOfVA]

Henri:

I believe you are correct.

I received a second display yesterday and started a test this morning.

After 6 hours of the checkerboard pattern, no problem at all. No indication of loss of initialization information.

I assume that Crystalfontz would like to have the original board back so they may determine the problem source, as it seems I am not the only one with the sporadic initialization problem.

Also, the new board is Rev B, so there might have been some engineering changes as well. It looks quite different than the controller on the first display.

Thanks again for the information.