16x2 ST7066U LCD Glitch causes garbage text to scroll

Curious if anyone has seen this issue before, example videos at the bottom. :confused:

Ok, I've been working on an Arduino based Renix Jeep Scan tool for the last few months and overall it's been doing pretty good, save for some odd glitches that I have been ironing out. It reads the raw serial stream from the ECU, does the math to convert the bytes into useful readings, and then displays them on a 16x2 screen that can cycle through them.

The bug that is most illusive and annoying has to do with the LCD bugging out and scrolling a bunch of garbage characters across the screen. I have heard reports that the Fahrenheit Symbol (A custom symbol I have included in my sketch) will sometimes show up as a box or have a line through it around the time that the scrolling glitch happens.

I notice that when the home button is pressed (brings you to a main menu with a 40 millisecond delay), the garbage will scroll much faster. Sometimes the code will recover, sometimes it must be hard restarted. Sometimes it takes 5-15 minutes to happen, other times up to 45 minutes to see the issue. Most annoying part is I've never personally got the issue on my vehicle so it's harder to figure out. It also doesn't appear to happen to everyone, only a few so far out of about 40. I had one of the troubled customers send his back and it would not glitch on my truck. I'm curious if the next one I send him still gives him issues.

It seems like it has only happened on my gauge part of the code which is where it is constantly reading in the serial data, doing math to it, and displaying 4 instances of a data array which references callback pointers I think? to display each gauge.

For myself the screen has worked perfectly and I haven't had any issues with it but some of my customers do so I'm not quite sure where to go from here. I had tracked down one screen glitch issue a while ago to not having enough free RAM in the sketch so I moved all LCD Text to PROGMEM with the (f) function. Hopefully someone can point me in the right direction of what to check out next.

The LCD is being operated in 4-bit mode and pins DB0-DB3 are left floating. I checked the ST7066U Controller Data sheet and it says: "For 4-bit interface data, only four bus lines (DB4 to DB7) are used for transfer. Bus lines DB0 to DB3 are disabled."


Arduino: Adafruit Pro Trinket 5V-16MHz

LCD: 16x2 LCD w/ RGB LED Backlight, ST7066U controller, operating in 4-bit Mode
Newhaven Display NHD-0216K1Z-NS(RGB)FBW-REV1


PCB: Custom board I designed

Sketch: Renduinix v0.78; 28,302 bytes (98%, 28,672 Max), 1,037 bytes dynamic memory (51%, 2048 Max)

Arduino Libraries used: Stock LiquidCrystal.h and EEPROM.h

First Example shows the issue when the unit is bumped at the 0:14 mark. It is working properly before then.

Second Example shows the screen recover but the Fahrenheit symbol has a line through it which doesn't appear to be an underline cursor as there are multiple instances of it at 1:08.

Thanks for looking, it might be quite the head scratcher!

Quick Bump. After thinking about it some more, I'm wondering if maybe the LCD is loosing track of the commands at one point which then throws off commands after then.

Any ideas or pointers for what I should look into as far as what would cause an LCD to lose track or how to regain track of commands?

Would a different or modified Liquid Crystal library help?

When in 4 bit mode, if you ever get a glitch on the EN signal, the display and the host (arduino) will be out of nibble sync and you start to get nothing but garbage until the LCD is re-initialized as the LCD will start interpreting all the data/commands as half nibble from one byte and half from another.
Cars are a very electrically noisy environment.
You will need to have plenty of power filtering to ensure that things like fans or compressor clutches or any big load that is switched on/off don't inject noise into the power supply of the Arduino.

What are you using for power?

There are several threads with similar issues as this for a project that was involved with a keg refrigerator.
When the frig would kick on/off the display would go whacky. A better power supply and filtering fixed the issue.

More than likely it is noise related and you just need to improve the filtering, like additional caps or an inductor on the main 5v signal going into the arduino.
Also, you might some additional decoupling on the actual LCD.

How long are the wires between the LCD and the Arduino. Shorter is obviously better.

--- bill

Hey Bill, Forum never e-mailed me of your response so sorry for getting back to you so late. Attached is a picture of the PCB without the screen attached.

I think you are spot on with the nibbles getting out of sync. I can sort of re-create the issue by just unplugging the screen from my breadboard test unit and plugging it back in. I have found a bootleg bandaid to mask the issue though. I can just call lcd.begin(16, 2); every second and it will force the screen to resync with a very, very slight screen refresh.

Obviously this only masks the true problem, but it is a work around for now untill I can figure out the root cause.

As for my circuit, I designed a PCB for everything to sit on, and the traces from the screen to the arduino are about 1-2" long.

NOW, I should mention that I have a light sensor that sits in the unused pcb holes of DB5 and DB6, and bend up and near the screen contacts. I thought this might be an area for possible interference So I put a piece of electrical tape on both sides of the screen contacts so they don’t touch but the issue still seems to persist. I had a customer cover the sensor but still he got issues.

On to power, I’m using the ignition power pin supplied at the diagnostic connector for 12-15v of power. It runs through an ethernet cable to the cab. On the board, it runs through a diode and then into the VIN of the Pro Trinket which is good to 16v. The diode has close to a 1v drop too. I don’t have any kind of filtering becuase I’m not quite sure what is needed.

Now here is something interesting, the same customer noted that the screen does not bug out if the key is on but engine off. When he turns the engine on, it will then bug out. It will also not bug out when connected only to the usb cable. So it would seem to be power related.

The serial stream does transmit data a lot closer together when the engine is running though. Curious, would you think that the serial would ever cause interference like that? When the screen does bug out, the sketch still runs properly becuase you can go through the menus and change the screen color so i don’t think it’s a ram corruption error. I would be rather surprised if it could, but just figured I’d ask.

Thanks for the help!

So quick update, I can actually get my scanner to bug out on my own vehicle sometime if I rev it really hard so I’d have to agree it’s definitely a power interference issue. I guess I’ve got some looking into do, any helpful hints or links on where to start for power filtering?

Alright, figure I'll finish this thread off since I hate dead end threads with no resolution. I found out that this problem did not occur with my version 1 boards but it did with the version 2 boards.

In V1 there were 2 ground traces from the lcd ground and R/W pin, one went to the arduino, and the other went to the jack that goes to vehicle ground which also had a separate path directly to the Arduino.

In V2 I removed the first ground trace so the only path the screen had was through the jack and then down to the arduino so I guess it was picking up some kind of interference from the vehicle. I have since added a jumper wire from the screen to the arduino and guess what, no more glitches!

So a seemingly trivial modification to my desgn was the cause of this very elusive and tricky bug, what a pain. So lesson learned, treat grounds with respect as they can make all the difference.

Thanks for those that have looked or have given input, hope this helps others out!