CFAF320240F-T - Display not coming

[kirankaranki]

Hi -

I have bought CFAF320240F-T and I'm trying to setup the display. I'm looking to use the 8 bit interface.

I have connected the CFAF320240F-T to LPC2148 MCU.

Currently the back light itself is not coming. We have given 3.3 V to A2, A1 (lines 48 and 49) and grounded K2 and K1 (lines 47 and 50).
Further to this, the Vcc lines - 44 and 45 has been connected to 3.3 V line from MCU. And all the lines that have been mentioned to be grounded have been grounded (Pins 1, 4, 5, 6, 37, 38, 39, 40, 42 and 43).

I have checked the connectivity from the MCU to the connector (I have used HFJ150CT-ND).

Please advise on how to check further.
1. Is there any reason why the back light is not on?
2. How to check the connectivity beyond the connector?

Please help.

Thanks,
Kiran.

Crystalfontz LCD Blog

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

 

[cosmicvoid]

... Currently the back light itself is not coming. We have given 3.3 V to A2, A1 (lines 48 and 49) and grounded K2 and K1 (lines 47 and 50).

If you look at the data sheet, on page 4 it shows that the LED backlight has a Vf of 9.9 volts (at 12.5mA per side). This means that you will need to use a voltage of more than 10 volts, and YOU MUST use current limiting resistors to prevent destroying the LEDs. In my hookup, I use 12 volts and 2 resistors of 180 ohm, 1/4 watt to A1 and A2.

... I have checked the connectivity from the MCU to the connector (I have used HFJ150CT-ND). 2. How to check the connectivity beyond the connector?

There is no way that I know of to check connectivity beyond the ZIF connector.

 

[kirankaranki]

Thanks a lot

Thanks a lot. The back light is working.

The display panel has started displaying but I'm yet to understand the behaviour. Only the bottom 20 rows show some color and that too not the color I have specified. I have specified BLUE but its showing RED/MAROON.

Please let me know if you have any idea?

Thanks,
Kiran.

 

[cosmicvoid]

... Only the bottom 20 rows show some color and that too not the color I have specified. I have specified BLUE but its showing RED/MAROON. Please let me know if you have any idea?

Without seeing your code, especially the color defines, and the register init settings, I can't say what your problem might be.

One possibility may be due to the value of the BGR bit in register 01h, which affects the color assignments.

 

[kirankaranki]

Display not coming - Code attached

Hi -

I have attached the code for your reference. I have used the the sample program given by Crystalfontz.

I have used the LPC2148 as MCU. The Port 0 is being used to interact with display controller.

P0.8 to P0.13 - D10 to D15
P0.15 - D17
P0.23 - D16
The P0.14 has been avoided as it has additional function of taking the MCU into programming mode.

P0.16 - RD Line
P0.17 - RESET
P0.18 - CS
P0.19 - CD
P0.20 - WR

Now the behaviour of display has changed. Half the screen is showing random colors and other half is just backlight.

Please let me know if I have missed anything. Thanks a lot for your help.

Thanks,
Kiran.

 

[cosmicvoid]

You have not given information about which interface mode you are using, so I am assuming 8080, based on what I see in your code.

I see two problem areas, in the command and data write functions. If you are using a 60 MHz cpu, then I think you need to add some delays to widen your write strobe to more than 70 nS.

The data is written into the display controller on the rising edge of the write strobe, yet you clear your data port before raising WR. This is a deadly error, I think, as the upper byte of every write will be 0. See my comments to your code.

void write_command(unsigned int command)
{
	CLEARDATAPORT;	[COLOR="Red"]// this is unnecessary, you should remove it[/COLOR]
	CLR_CS;
	CLR_CD;
	SET_RD;	[COLOR="Red"]// this is unnecessary, you should remove it[/COLOR]
	SET_WR;	[COLOR="Red"]// this is unnecessary, you should remove it[/COLOR]
	DATAPORT = ((0x0000BF00 & (command)) | (0x00800000 & (command << 9)));
	CLR_WR;
	[COLOR="Blue"][B]// put in a 100 nS delay here[/B][/COLOR]
	CLEARDATAPORT;	[COLOR="Red"][B]// this is deadly, you should remove it[/B][/COLOR]
	SET_WR;
	DATAPORT = ((0x0000BF00 & (command << 8)) | (0x00800000 & (command << 17)));
	CLR_WR;
	[COLOR="Blue"][B]// put in a 100 nS delay here[/B][/COLOR]
	SET_WR;
	SET_CS;

Make the same changes to both of your write functions.

I have not looked for errors beyond this, so if there are problems after you make these fixes, then we can look for them.

 

[kirankaranki]

Display fixed - Partially

Hi -

Thanks a lot for going through the code. I have fixed per your guidance and the display is working fine (partially). The top panel is showing the colors properly but the bottom half (I would say bottom 2/3'rd) is blank.

Regarding the CLEARDATAPORT, I think it's required. I have adjusted where it's placed based on your comments. Way the LPC2148 works is that the IO lines are controlled through SET0 and CLR0 registers. If I pass a 0 on SET0 register, it does not have any meaning. If a line was set to high previously, it'll continue to stay high till it's set high through CLR0 register. Please let me know if my understanding is not correct.

I have attached the code again, after doing the modifications suggested by you.

Thanks a lot for your help.

Warm regards,
Kiran.

 

[cosmicvoid]

... Regarding the CLEARDATAPORT, I think it's required. I have adjusted where it's placed based on your comments. Way the LPC2148 works is that the IO lines are controlled through SET0 and CLR0 registers. If I pass a 0 on SET0 register, it does not have any meaning. If a line was set to high previously, it'll continue to stay high till it's set high through CLR0 register. Please let me know if my understanding is not correct.

Since I am not familiar with the LPC2148 (and too lazy to do the research ), I do not know how the SET0 and CLR0 registers work. What you say makes sense, and moving the CLEARDATAPORT outside of the write pulse is the correct way to handle that.

I do not see any reason that your code does not fill the entire display. Can you step through your program with a debugger, and see if it appears to execute correctly?

You could take a look at my CFAF320 code, and try using your I/O port defines and write functions with my code, to see if it acts the same as yours or whether it fills the screen. You could remove the part about writing text strings, since the memory access is probably not compatible with your cpu.

https://forum.crystalfontz.com/showthread.php?t=6637

The only other idea I have for your problem is it might be either a wiring error or a bad signal connection.

 

[kirankaranki]

Display working - After disconnecting Vcc

Hi -

The display has started working. It started working after disconnecting the Vcc.
I had shorted pins 17, 18 (PS0, PS1), 44 and 45 (Vcc pins). If these are connected to 3.3v power supply, the screen is showing partial display. If we remove the power connection, the display is working perfectly.
We are assuming that the display panel might be getting power from RESET pin (as it's always high).

We are not sure whether what is the issue .. any idea? Please let me know.

Thanks a lot for your help.

Thanks,
Kiran.

 

[cosmicvoid]

It seems like you still might have a wiring problem. I assume you have seen the CFAF320240F connection document

http://www.crystalfontz.com/products/document/2236/CFAF320240F_Pin_Usage_Table_by_Interface.pdf

Without knowing all of your pin connections, I can not say what might be wrong. Maybe signals shorted together; have you looked at the ZIF connector soldering very closely under a magnifier to find solder bridges?

How are PS0~PS3 connected? You are probably right about the display being powered through high inputs, but connecting Vcc should not cause problems.

 

[kirankaranki]

Display panel - Connection details.

Hi -

I agree with you. There is very likely a wiring issue.

Just going through the connections. The Port 0 is being used to interact with display controller.

P0.8 to P0.13 - D10 to D15
P0.15 - D17
P0.23 - D16
The P0.14 has been avoided as it has additional function of taking the MCU into programming mode.

P0.16 - RD Line
P0.17 - RESET
P0.18 - CS
P0.19 - CD
P0.20 - WR

Pins 17, 18 (PS0, PS1), 44 and 45 (Vcc pins) have been shorted and connected to the power supply. The power supply is from the micro controller board.

Pins 1, 4, 5, 6, 15, 16 (PS2, PS3), 37, 38, 39, 40, 42, 43, 47 and 50 (backlight-) have been shorted and connected to ground.

Other pins have not been connected to anything, would this cause any issue?

Following verifications have been done
1. We removed the backlight power supply - to make sure that backlight power supply was not creating problem. We were able to replicate the same behaviour.
2. We removed the PS0, PS1 shorted with Vcc and kept it open - the program did not execute
3. We built a second board - The exact problem is replicated

The breakout board used is
http://cgi.ebay.in/ws/eBayISAPI.dll?ViewItem&item=190348996157&ssPageName=ADME:L:OU:IN:1123

We have verified for the shorts using multimeter. There does not appear to be any shorts. The connection from MCU to the breakout board and breakout board through connector has been verified.

Two things we are planning to try
1. Give an independent power supply, currently the 3.3v supply is coming from MCU board but we doubt whether this will solve the problem
2. We are planning to connect the PS0 and PS1 to an IO line and give a 1 programatically.

Please let us know if we need to try anything else.

Also, let me know if you need any more information to understand the connection better.

Thanks,
Kiran.

 

[cosmicvoid]

Pins 1, 4, 5, 6, 15, 16 (PS2, PS3), 37, 38, 39, 40, 42, 43, 47 and 50 (backlight-) have been shorted and connected to ground.

I suggest that you remove pins 37, 38, 39, and 40 from ground, and leave them open-circuit (as shown in the connection guide document).

Other pins have not been connected to anything, would this cause any issue?

I don't think so.

We removed the PS0, PS1 shorted with Vcc and kept it open - the program did not execute

Of course, the mode would be wrong.

The breakout board used is
http://cgi.ebay.in/ws/eBayISAPI.dll?ViewItem&item=190348996157&ssPageName=ADME:L:OU:IN:1123

I have some of those boards, and used one with a CFAF240400D.

We are planning to connect the PS0 and PS1 to an IO line and give a 1 programatically.

I did that with another TFT display, to let me dynamically switch between 8 and 16 bit modes, to do troubleshooting.

I really don't see what else might be causing your problem, so I hope my suggestion helps.

 

[kirankaranki]

Thanks for your help

Hi -

I'll try out the suggestions today and see what happens. Thanks a lot for your help and guidance.

Warm regards,
Kiran.

 

[kirankaranki]

Removed the ground - still not working

Hi -

I removed the ground connection to pins 37, 38, 39 and 40 and made it open. This did not help (nor harm). The display is showing till around 110 row and blank after that.
As well, the display scrolls, in the sense, the 111 row is the 1'st row again, thus overwriting what was written in row 1.

Please let me know if there's anything more to try out.

This has been replicated on different display panels (I had bought 3 panels and all of them show same behaviour). I have prepared two connection boards and both of them show same behaviour - works perfectly when not connected to Vcc and shows only till row 110 when connected to Vcc.

Thanks for your help.

Thanks,
Kiran.

 

[cosmicvoid]

I wonder if something in your init sequence is programming the display appear to have a smaller active area. You said that when you disconnected the Vcc, the display "worked perfectly". If so, then you could try reconnecting the Vcc to one pin at a time, and see when the operation stops working correctly. Maybe that would suggest the problem.

You could also take a look at my code samples, and try my init sequence to see if it makes any difference. There is also a port test routine that I used to troubleshoot wiring errors, which puts out pulses on the port pins, 1 pulse on D0, 2 pulses on D1, 3 pulses on D2, etc. You can modify that for your cpu. If you have an oscilloscope, you can check your signal wiring that way.
https://forum.crystalfontz.com/showpost.php?p=27968&postcount=1

 

[kirankaranki]

Init sequence and removing Vcc Connection

Hi -

Regarding Init sequence - I had copied your init sequence. There was a minor difference in one of the register value. I have however as of now, copied your init sequence itself.
I somehow don't think its init sequence issue or programming issue because otherwise it should work fine if the Vcc is disconnected. I could be mistaken. It could be program issue which is getting masked when the Vcc is kept open.

Regarding disconnecting all the Vcc and then reconnecting one by one - I'll try this out and let you know. I'll have to connect the PS0 and PS1 to an IO line, other than that only 44 and 45 are connected to the Vcc. I'll connect them one by one and see.

Regarding testing port pins - I have written a similar program, give pulses to one line at a time with 5 second delay. We have run the program and tested the output on each line. There are no shorts (we gave pulse to D0 and checked not only D0 but all the other lines) as well the line that was given 1 showed 3.3 V.

Thanks for your help.

Thanks,
Kiran.

 

[kirankaranki]

Removing Vcc connections

Hi -

I removed the Vcc connections. I connected PS0 and PS1 (17 and 18) to the RESET line as it's always high (when display is operational).
I removed the shorting of 44 and 45 and just connected 45 to Vcc, still the behavior was same. The first 110 rows are displayed.

I'm thinking of trying with independent power supply, currently it's powered by 3.3 v line from MCU.

Let me know if you think of anything.

Thanks,
Kiran.

 

[cosmicvoid]

I'm sorry you haven't had success. I assume you proved beyond doubt that your wiring is correct, with no shorts between lines.

Does is still work full screen if you disconnect Vcc? I don't think a separate power supply will make any difference.

If I were you, I would try changing your GPIO pin usage, like using P0.0~P0.7 for data bus and P0.8~P0.12 for control signals. Why do this? Why not? Since your other attemps do not solve the problem, maybe its time to make drastic changes. At least try this temporarily to see if the symptoms change. This will also avoid needing to shift the data strangely in your write functions.

Also, I think there is no need to avoid using P0.14.

 

[kirankaranki]

Changing port pins

Hi -

I will try out the suggestion given by you.
As well, we can use the P0.14, I had used it originally with the pullup resistor. I can go back to that.

Thanks,
Kiran.

 

[kirankaranki]

Issues resolved - Unbelievably

Hi -

The issue has got resolved. The issue was resolved by increasing the delay in the Write and Read commands.
Earlier the delay was approximately 1 micro sec, increased it to approximately 5 micro secs. That seems to fix the partial display issue.

It was a very chance discovery. When I reduced the delay (with the intent of speeding the display on the screen), even with the Vcc not connected, the partial display problem occurred. That gave the clue that it could be delay related. Not that I understand fully, why the delay should have caused the issue.

Thanks a lot for your help in resolving the issue. Your guidance has been invaluable.

Warm regards,
Kiran.