LCD cross-talk

Last post
20 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi freaks....

Freaks I'm using an LCD 16x2 and the LCD Codevision library where it just use the last four data pins of the LCD. The thing is I'm getting cross-talk on this data pins from the enable pin. I tried to put far away the traces and cables of the enable pin from the data pins but still getting cross-talk on data lines. Someone already got this problem?

My cable has 30cm, I know that is long, but it's works fine, until I got some noise on Vcc and the LCD blocks my firmware in a while loop on the LCD library.

Attachment(s): 

Regards,

Bruno Muswieck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You have a dry/bad joint somewhere on your blue trace.

The AVR has exceedingly low o/p impedance when the data lines are driven.

When the library code is reading the BUSY line, the LCD is in o/p mode. Admittedly without a very low o/p impedance, but certainly low enough to discourage any noise pick-up.

I cannot read your scope trace. I would expect a single pair of EN strobes for writing the data, followed by several pairs while it is checking BUSY (with RW=1).

Double-check your wiring connections.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is no cross-talk.

Notice the slow rise but sharp fall.

You have left/configured the pin on blue trace to be input or open-collector output.

Or in fact, it may be that you are polling for BUSY bit, and the AVR pin has to be input. The D7 pin has weak pull-up, as may be the case with AVR pin. This causes the pin to rise slowly. When E goes high when reading from LCD, the LCD drives the D7 pin hard high or hard low.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would add a moderately stiff pull down on the blue trace, if you find no other issues like those suggested above (badly-configured output, bad solder connection). Maybe 1K to ground.

Personally, I strongly suspect a hardware problem. An AVR output is less than 100 ohms (either to Vcc or to Ground). Even with capacitive coupling between lines, you should not see anything like that.

I often separate clock or enable lines from data lines with a ground line. Such as data/data/data/data/ground/enable/..., just to be paranoid about it all.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA There are some answers that have no questions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim, I still believe it looks like that because the bus already has a weak pull-up, and the bus floats with the pull-up during the time when neither AVR nor LCD is driving the bus.

If you put a 1kohm to ground, the LCD is not able to drive so high load and you can't read the BUSY flag or anything. Voh(min) is 2.4V @ 0.2mA for standard HD44780.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use [my somewhat adapted] CV library in many production designs. Perhaps tell what CV version you are using so I can take a peek at that library code? In my apps I always make the three control signals outputs in the AVR. I know that CV takes care of the data lines, but don't remember whether it makes the control lines outputs.

BTW, a tiny cap at the LCD end of the E line can be helpful with a long cable. One way to test is to 'scope probe the E line on the LCD. If the problems clear up while being probed, then the E line is probably a bit ratty and the probe capacitance helps clear it up.

2.04.5 doesn't set DDR for the control bits--best guess is you forgot to make one or more outputs.

You can put lipstick on a pig, but it is still a pig.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tend to suspect Jepael's suggestion. If so, the data lines need to be driven with a good, stiff, logic source while it is writing. If it needs to be bidriectional, then deal with that on a transaction by transaction basis.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA There are some answers that have no questions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I often separate clock or enable lines from data lines with a ground line. Such as data/data/data/data/ground/enable/..., just to be paranoid about it all.

Me too Jim... Is better to be paranoid.. :)

Quote:
2.04.5 doesn't set DDR for the control bits--best guess is you forgot to make one or more outputs.

I modify the library to separete data pins from control pins on diferent ports.. My CV version is 2.04.8a.

Thanks guys... I will check your thoughts and I make some tests on it and came back with more answers.. ;)

Regards,

Bruno Muswieck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I modify the library to separete data pins from control pins on diferent ports..

I have also done that. But can't you quickly look, and/or post a small complete test program that demonstrates the situation, and check that the control signals are outputs?

You can put lipstick on a pig, but it is still a pig.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
You have a dry/bad joint somewhere on your blue trace.

Can't be, 5 boards with the same situation...

Quote:
I have also done that. But can't you quickly look, and/or post a small complete test program that demonstrates the situation, and check that the control signals are outputs?

I will compare our lib and CV lib on data pins... But Theusch it should be on the data pins the problen, not on the control lines, because we separete the control and data pins, so we set the pins as I/O separately...

Regards,

Bruno Muswieck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi freaks...
We perfom some tests and with the normal CV library (no pins control and data changed) it has the same problem, data lines got spikes simillar with enable pin.

We tried the 1k pull-down, it has less spikes, but still got it...

Theusch, the change on library isn't on version 2.05? Where a new LCD library was avaliable where you can change the pins.

After all, my supecius are in the CV lib, it seens that after set the data pins, it doesn't clear it insted it put the pin to input...

Regards,

Bruno Muswieck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If at any point the CV library puts IO pins as inputs, with or without pull-ups, the internal pull-ups in the display would slowly charge the wires to logic high, until either LCD or AVR drives the bus to full high or low fast. With AVR having pull-ups on, it would just charge faster.

That is all I see from the scope picture. Now the question is, why is that a problem? It is not cross-talk and it is should not be the cause for the display not working, but something else, like ringing on E line.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
That is all I see from the scope picture. Now the question is, why is that a problem? It is not cross-talk and it is should not be the cause for the display not working, but something else, like ringing on E line.

When We turn on some load on the mains, around my board, on the mains create some noise and on this moment our program blocks when write/read the LCD, so I think that because of the noise the LCD controller should identify the noise as a logic level that block the program to goes on...
PS: We're shure that it blocks on the LCD functions, already tested....

Regards,

Bruno Muswieck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks more like a crosstalk, indeed. Can be ground wiring related, or, alternatively, AVR output settings. Would incline more towards improper or floating ground. For that a quick check on all LCD terminals running simple cycle can give a hint (with the scope). A brutal solution was to cut in a bus driver into the data and control lines to LCD (bearing in the mind signal direction). This shall exhibit the culprit; at least, shall help with noise immunity.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
AVR output settings

It's... The AVR data pin are programmed as input so it's floating.. On the new CV library alcd, it's fixed...

Regards,

Bruno Muswieck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nope. The library still needs to use the RD pin in the same way as the library.

The library code will write to the DB4..DB7 pins and then set the RD pin to read the BUSY status. When the RD pin is set, the LCD will use its o/p drivers when the EN pin is strobed.

The AVR will be in i/p mode to read the BUSY status. You will have a short period when both the AVR and LCD are hi-Z.

I have not studied the CV code. However it will be much the same as any other LCD 4-bit code. The only differences will be where the individual LCD pins can be assigned to any AVR pins. The old library has everything on one PORT.

I cannot read your scope trace. If you provided a shorter trace, it should be easy to see the hi-Z timing.

I suspect you would find the same problems with any LCD code that uses BUSY. Since you seldom read the LCD memory, I would use a Write-Only LCD library like danni's.

The other workaround is to call lcd_init() and re-draw every few minutes.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If OP could specify in more detail if diagrams in the first post are read or write cycle related (i.e. status of R/W signal), that would help. Shall it be READ, then it's exactly as per David's explanation.
A post:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=104894&highlight=nt7603
is worth looking too, imho.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Nope. The library still needs to use the RD pin in the same way as the library.

David I really didn't go "inside" in the CV code. But we saw on oscilloscope that the libraries has differences.
I need to perfom some tests, but your ideia of lcd_init() from time to time is good.. ;)

David, the problem is a sum of things that happen and freaze the LCD...

Quote:
If OP could specify in more detail if diagrams in the first post are read or write cycle related (i.e. status of R/W signal), that would help. Shall it be READ, then it's exactly as per David's explanation.

Kas, it's only write cycle...

PS: the tests are perfom on the LCD connection that has long wires and short wires, both have the same waves...

Regards,

Bruno Muswieck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just wanted to draw attention that possibly this is timing issue, and not much wrong with the data signals. Regular re-init for sure can be a good workaround.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Freaks, We did other test, disconnect the enable pin from LCD, and on the LCD put a pull-up on enable.. We write the LCD and observe it on oscilloscope: no more pick-up from enable on data pins, and on the data pins in the moment where there aren't data, the logic level doens't goes up to Vcc...

So the data pins are configurated as input and the "noise" are pick-up thorught the LCD hardware, from enable to data pins..

Regards,

Bruno Muswieck