LCD2004A LCD SCRAMBLING (Brew Pi)

A group of us are working on a better design for a circuit board that connects temp sensors, heating and cooling relay and a LCD to a Arduino. The issue that they have been getting building it that sometimes it gets LCD Scrambling and no one has worked out exactly what is causing it only coming up with theories what might be causing it. Has anyone worked on a project and had this issue before? If you need more info on the design of the board or anything you can find it at the link below.

Hi and welcome.

7e64d53d4cc39a8f04ad93bc26e0d3de4ad82e34.jpg
21cd67d52a34a800d60c1197acd996e83bef647b.jpg
e54a8b3b86bdd7c1021e047643cea1bba379e1d4.jpg

I think i see some points for improvements.
The schematics don’t seem to be 1 to 1 to the PCB.
The schematics lack component names and numbers, but they are present on the PCB.
That doesn’t help identifying which part does what.
I’ve always been told to put a decoupling capacitor as close to the device it is to serve.
And i’ve always understood that this is especially important for the 74HC595.
I’m guessing now, but C4 isn’t as close to the '595 as it can be, and the connection from the capacitor is first lead to pin 13, then lead to pin 8.
I’m not sure that is the best way to go, perhaps someone with extensive experience with those '595s can chime in.

I assume that you get corruption when relays are not being used? I ask used because they generate big EMC spikes even if a flyback diode is used and can put noise pulses on the critical clock lines.

So if it is not a relay noise spike problem then since it does work mostly I suspect that the real problem is not the hardware but the way the software is driving it.

I assume the LCD has a standard HD44870 type controller. Since you can't read the display "busy" state you have to include delays between instructions. Some instructions require a 2000us delay others need less time.

The timing of the controls signals is also important to meet the data/command setup and hold times, for example the minimum enable high time is 450ns and it requires >37us for the command to settle after the falling edge, during this time the command bits must be stable. Since you may be clocking bits in at 8MHz that is a long time to wait! If you have a logic analyser or oscilloscope you can check timings by sending repeat patterns and checking the data sheet timings are being complied with.

Examining your code would be tedious so I am not volunteering :)

The issue that they have been getting building it that sometimes it gets LCD Scrambling and no one has worked out exactly what is causing it only coming up with theories what might be causing it. Has anyone worked on a project and had this issue before?

Lots of times. Search for topic headings that include LCD and weird, scrambled, jibberish, etc.

You will find that a capacitor directly across the LCD power terminals frequently solves the problem.

Don

floresta: Lots of times. Search for topic headings that include LCD and weird, scrambled, jibberish, etc.

Didn't we see one a few years back where somebody was building a kegerator refrigerator (keg inside a refrigerator with a tap in the door) and used a LCD to display the temperature of the keg inside and had an issue when the refrigerator turned on/off?

I'd be looking at voltage noise issues since at least according to the homebrew thread referenced above, the same problem occurred when using an LCD with an i2c backpack. That would be using a completely different way of interfacing to the LCD (which is much slower) and a different library.

I'v personally seen ground bounce issues when using LCDs cause corruption and I've also seen noise issues with 595 shift registers. A 595 can even create its own noise when latching the outputs particularly if lots of output pins are changing levels. Better wiring with fewer and shorter runs helps the first and decoupling caps right up close to the 595 power pins can help the latter.

--- bill

bperrybap: Didn't we see one a few years back where somebody was building a kegerator refrigerator (keg inside a refrigerator with a tap in the door) and used a LCD to display the temperature of the keg inside and had an issue when the refrigerator turned on/off?

I'd be looking at voltage noise issues since at least according to the homebrew thread referenced above, the same problem occurred when using an LCD with an i2c backpack. That would be using a completely different way of interfacing to the LCD (which is much slower) and a different library.

I'v personally seen ground bounce issues when using LCDs cause corruption and I've also seen noise issues with 595 shift registers. A 595 can even create its own noise when latching the outputs particularly if lots of output pins are changing levels. Better wiring with fewer and shorter runs helps the first and decoupling caps right up close to the 595 power pins can help the latter.

--- bill

It's likely the same project. How much shorter than they are currently? And how would you make fewer runs? You able expand more on the changes you suggested?

colenz:
It’s likely the same project. How much shorter than they are currently? And how would you make fewer runs? You able expand more on the changes you suggested?

As MAS3 pointed out it is difficult to tell what is on the PCB since the schematic part names don’t align with the PCB mask.
Is there a PCB layout somewhere where we could look at the actual board traces etc…

What Arduino board are you using and how is the arduino being powered?

How is the LCD hooked to the shield? Is is soldered directly or are wires/ribben cable being used?

Which LCD library are you using?

In terms of ground bounce, that can happen if have multiple runs off a ground connection.
Example:

Put these the LCD and interface components into a breadboard.
Run the main power and ground to the top rails, then run power and ground wires from the top
rails to the to the bottom rails.
If you power and ground the 595 from the top rail, and power and ground the LCD from the bottom rail,
you will have issues. The “ground” on the lower rail will bounce up above ground when the 595 latches its outputs creating issues for the LCD.
(ground isn’t always 0v ground even though they are all connected with wires)

Another thing that can aggravate this is if the LCD library is cheating (violating the hd44780 signal timing) in how it handles the E signal.
The hd4478 spec is very clear that the control signals are suppose to be stable before you raise E.
However, many LCD libraries do not honor this. While it usually works, it could potentially aggravate the situation when ground is floating around since the settling time for the signals may extend beyond the few 10s of ns before the LCD actually samples the signals.

It is best to not do that kind of stuff.
Sometimes you can work around it if you put caps on the LCD power & ground pins.

— bill

bperrybap: Another thing that can aggravate this is if the LCD library is cheating (violating the hd44780 signal timing) in how it handles the E signal. The hd4478 spec is very clear that the control signals are suppose to be stable before you raise E. However, many LCD libraries do not honour this.

It is possible that compiler "optimisation" fouls this!

Paul__B: It is possible that compiler "optimisation" fouls this!

Not really unless they were using some of custom delay loop which I've not seen in any of the libraries I've looked at. The issue is whether the code does an extra bit of delay after it sets up up the control signals before it raises E. Many LCD libraries set them with no delay and on the i2c expanders they typically set E high at the same time they are setting the control and 4 data bits. While that offers higher performance and usually works, it is violating the hd44780 spec timing.

I went and looked at the IDE bundled LiquidCrystal library and it should not have this issue as it explicitly does and extra delay in the pulseEnable() function to allow time the control and data lines to settle before raising E. (much more time than is needed, but extra time does not hurt)

--- bill

bperrybap:
Not really unless they were using some of custom delay loop which I’ve not seen in any of the libraries I’ve looked at.
The issue is whether the code does an extra bit of delay after it sets up up the control signals before it raises E.
Many LCD libraries set them with no delay and on the i2c expanders they typically set E high at the same time they are setting the control and 4 data bits.
While that offers higher performance and usually works, it is violating the hd44780 spec timing.

I went and looked at the IDE bundled LiquidCrystal library and it should not have this issue as it explicitly does and extra delay in the pulseEnable() function to allow time the control and data lines to settle before raising E.
(much more time than is needed, but extra time does not hurt)

— bill

List of components in link below for the board:

https://www.mouser.com/ProjectManage...sID=ceca4ae1f4

Link to pcb shield with component markings:

The mouser link doesn’t seem to work. (it ends up just going to the main page).

But any library issue will be s/w not h/w. Where is a link that shows all s/w that is running the on the Arduino?
I found some Arduino s/w here:

But I have no idea if that is what is being used.
There were definitely some hd44780 timing violations in spiLcd.cpp code in the clear() and home() functions.

In terms of the shield, that photo isn’t enough, particularly as has been mentioned a few times,
their are issue with respect to parts in the schematic vs the board silkscreen.

What would be useful is an accurate schematic and an eagle layout that match with all components labled.
That way it will be possible to see where all the components are and both sides of the PCB traces.

If you guys want to get some help solving your issues, you need to get serious about supplying all the needed information.

— bill

bperrybap: The mouser link doesn't seem to work. (it ends up just going to the main page).

But any library issue will be s/w not h/w. Where is a link that shows all s/w that is running the on the Arduino? I found some Arduino s/w here: https://github.com/BrewPi/firmware/releases But I have no idea if that is what is being used. There were definitely some hd44780 timing violations in spiLcd.cpp code in the clear() and home() functions.

In terms of the shield, that photo isn't enough, particularly as has been mentioned a few times, their are issue with respect to parts in the schematic vs the board silkscreen.

What would be useful is an accurate schematic and an eagle layout that match with all components labled. That way it will be possible to see where all the components are and both sides of the PCB traces.

If you guys want to get some help solving your issues, you need to get serious about supplying all the needed information.

--- bill

Heres the link to the page that provides as much info as has been provided with links to the schematics in a Brd file.

http://www.homebrewtalk.com/showpost.php?p=7514148&postcount=5113

Heres a updated link to the parts list that worked for me:

https://nz.mouser.com/ProjectManager/ProjectDetail.aspx?AccessID=ceca4ae1f4

I will try ask for the software side of things and post a link.

I've not been able to see how the the LCD is attached to the shield. Is it attached directly or is a ribbon cable being used?

The links to

colenz: Heres the link to the page that provides as much info as has been provided with links to the schematics in a Brd file.

http://www.homebrewtalk.com/showpost.php?p=7514148&postcount=5113

The links to "eagle" files here do not seem to be raw eagle files . They seem to be wrapped in html stuff so eagle pukes on them. Any suggestions?

Another thing I noticed on the PCB is the silkscreen label for the LCD pins is backwards. The 1 and 16 are reversed.

This is turning into too much work to get the information.

--- bill

bperrybap:
I’ve not been able to see how the the LCD is attached to the shield.
Is it attached directly or is a ribbon cable being used?

Ribbon cable

colenz: Ribbon cable

How long? photos? This could be contributing to the issue as you can get voltage drop, signal cross talk, signal noise induction, signal reflections, and potential ground bounce from using a ribbon cable.

It is like pulling teeth to get information. --- bill

bperrybap: How long? photos? This could be contributing to the issue as you can get voltage drop, signal cross talk, signal noise induction, signal reflections, and potential ground bounce from using a ribbon cable.

It is like pulling teeth to get information. --- bill

I'll find out trying to get the right information from people has been timely. They supply a brd file and the pcb makers want a Garber file. So asked them for them to give a convertered file. I'll get them to take some pics of the flex with a measurement.

Guessing using shielded cable would help.

colenz: Guessing using shielded cable would help.

Bad guess.