Character Display Problem - Page 1
Forum section: electronics / projects

author: Chet T16
author_rank: Frequent Contributor
timestamp: July 16, 2011, 08:12:56 pm
content: So I assembled both my tuxgraphics power supplies but i'm having trouble with both displaysI've been talking to tuxgraphics but without resolution, has anyone seen anything like this before?Supposing I over heated the atmega8 could that cause problems like this or is it more likely to not work at all? How about if i static zapped the chips?

author: PeterG
author_rank: Frequent Contributor
timestamp: July 17, 2011, 01:26:17 am
content: If the display is being controlled by the MCU then the MCU seems to be operating fine.If the problem is the flickering display, i would check for a problem in the code driving the LCD.Regards

author: IanJ
author_rank: Unknown
timestamp: July 17, 2011, 08:46:40 am
content: Hi,Post your Arduino code.Ian.

author: jahonen
author_rank: Super Contributor
timestamp: July 17, 2011, 09:07:43 am
content: I think it might be a signal integrity issue (as the problem seems to be somewhat sporadic), what kind of wiring do you have between the display and the MCU? Long wires without no neighboring ground wires connected at both ends is always quite bad (that's what I hate about typical LCD modules, or about their pinouts). I also see a breadboard on the background, could it be just bad ground connection somewhere?Regards,Janne

author: Chet T16
author_rank: Frequent Contributor
timestamp: July 17, 2011, 11:25:19 pm
content: Thanks for the replies.Both are running the default code from tuxgraphics and the display is soldered using a couple of inches of ribbon cableThe buttons and voltage output work correctly (i haven't tested the current limiting yet)

author: Neilm
author_rank: Super Contributor
timestamp: July 18, 2011, 06:12:53 pm
content: Start with the basics:How is that display driven?Is the voltage supply stable?Have all the chips been properly decoupled? If there is a lot of noise on the supply voltage to the MCU it might be causing it to reset and send spurious characters to the display.Do you have any example code that could be used to drive the display?Are you sure that you don't have a dry joint or intermittent connection? (trust me - I've been caught out by that more times than I care to remember)If you have tried all of these it will tell you something - for instance if the example code works you know that it is a coding problem. If the example code didn't work then it is a hardware problem.As you intimated that the fault is common to two systems, I would start off looking at anything that was common between the two systems, for instance the code or any hardware you used for example power supply.YoursNeil

author: Chet T16
author_rank: Frequent Contributor
timestamp: July 18, 2011, 07:02:26 pm
content: I have tried three different power supplies, two wall warts and the laptop SMPS i intend to finally run them fromThere is lcd test code provided but that gives the same problem when loaded.I had a spare atmega8 which i loaded the code to but that was giving the same problem. Originally i made one kit up with the uC in a socket. When it showed these symptoms i tried another in the socket. When that was teh same i desoldered the socket and put it in direct incase the socket was to blame but it was the very same.I then assumed that something else in the assembly was wrong so after checking over the board and not finding anything i made up the second kit (soldering everything direct)I also tried a different display that i have here incase the two for the power supply were faulty but that was showing the same issues tooSo the only thing i can see thats common to everything (aside from my soldering...) is my programming of the chips but i'd be surprised if i was lucky enough that it all works apart from the display.Loads of people have been using these kits so i can't see it being anything in the code thats the issue.

author: Unknown
author_rank: Unknown
timestamp: July 18, 2011, 09:41:11 pm
content: Did you set the fuses (especially the clock-related ones) to what the software expects? A too high clock speed might cause timing issues, especially since the program likely uses delays instead of monitoring the RW line.

author: Chet T16
author_rank: Frequent Contributor
timestamp: July 18, 2011, 10:26:40 pm
content: The RW line is grounded so i guess it uses delays as you say.Guido at tuxgraphics suggested it might be a fuses issue and has asked me to check, from what i see they're set as they should beFrom the make file:Code:#-------------------# fuse byte settings:# Atmel AVR ATmega8# Fuse Low Byte = 0xe1 (1MHz internal), 0xe4 (8MHz internal)# Fuse Low Byte with BOD = 0xa1 (1MHz internal), 0xa4 (8MHz internal)# Fuse High Byte = 0xd9# Factory default is 0xe1 for low byte and 0xd9 for high byte# Check this with make rdfusesrdfuses:$(LOADCMD) -p $(DUDECPUTYPE) -c usbtiny -v -q# use internal RC oscillator 8 Mhz (lf=0xe4 hf=0xd9)fuses:$(LOADCMD) -p $(DUDECPUTYPE) -c usbtiny -u -v -U lfuse:w:0xa4:m$(LOADCMD) -p $(DUDECPUTYPE) -c usbtiny -u -v -U hfuse:w:0xd9:mfuse:$(LOADCMD) -p $(DUDECPUTYPE) -c usbtiny -u -v -U lfuse:w:0xa4:m$(LOADCMD) -p $(DUDECPUTYPE) -c usbtiny -u -v -U hfuse:w:0xd9:mChecking using avrdudeCode:C:\Users\Chet>avrdude -P USB -p m8 -c usbtiny -v -qavrdude: Version 5.10, compiled on Jan 19 2010 at 10:45:23Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/Copyright (c) 2007-2009 Joerg WunschSystem wide configuration file is "C:\WinAVR-20100110\bin\avrdude.conf"Using Port : USBUsing Programmer : usbtinyAVR Part : ATMEGA8Chip Erase delay : 10000 usPAGEL : PD7BS2 : PC2RESET disposition : dedicatedRETRY pulse : SCKserial program mode : yesparallel program mode : yesTimeout : 200StabDelay : 100CmdexeDelay : 25SyncLoops : 32ByteDelay : 0PollIndex : 3PollValue : 0x53Memory Detail :Block Poll PagePolledMemory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------eeprom 4 20 128 0 no 512 4 0 9000 9000 0xff 0xffflash 33 10 64 0 yes 8192 64 128 4500 4500 0xff 0x00lfuse 0 0 0 0 no 1 0 0 2000 2000 0x00 0x00hfuse 0 0 0 0 no 1 0 0 2000 2000 0x00 0x00lock 0 0 0 0 no 1 0 0 2000 2000 0x00 0x00calibration 0 0 0 0 no 4 0 0 00 0x00 0x00signature 0 0 0 0 no 3 0 0 00 0x00 0x00Programmer Type : USBtinyDescription : USBtiny simple USB programmer, http://www.ladyada.net/make/usbtinyisp/avrdude: programmer operation not supportedavrdude: Using SCK period of 10 usecavrdude: AVR device initialized and ready to accept instructionsavrdude: Device signature = 0x1e9307avrdude: safemode: lfuse reads as A4avrdude: safemode: hfuse reads as D9avrdude: safemode: lfuse reads as A4avrdude: safemode: hfuse reads as D9avrdude: safemode: Fuses OKavrdude done. Thank you.I'm assuming the A4 and D9 bits are the only important things to compare?

author: DrGeoff
author_rank: Frequent Contributor
timestamp: July 18, 2011, 10:38:24 pm
content: Looks like an LCD driver problem.

author: bobski
author_rank: Contributor
timestamp: July 19, 2011, 04:48:19 pm
content: Could this be a matter of the fuse bits being inverted? I seem to recall that being an issue with different programming software or hardware or something (only browsed a thread about it... never experienced it myself). I would think that would cause more problems than the glitches seen here, but I'll throw it out there.Also, the block poll lists lfuse and hfuse as 0x00? Am I reading that right?

author: Chet T16
author_rank: Frequent Contributor
timestamp: July 20, 2011, 11:38:01 pm
content: After more testing, prodding, soldering and poking i discovered that the display works fine when i connected it to my arduino but also my 20x4 LCD works on the power supply.So Guido from tuxgraphics suggests that its probably the controller on the LCD is not able to keep up with the speed its being written to. Sounds fair enough to me!

author: bilko
author_rank: Frequent Contributor
timestamp: July 22, 2011, 06:18:13 pm
content: Quote from: Chet T16 on July 20, 2011, 11:38:01 pmSo the tuxgraphics firmware is the cause of the problem then ?

author: Chet T16
author_rank: Frequent Contributor
timestamp: July 22, 2011, 08:53:52 pm
content: Well, yes, but it's normally fine. I was just unlucky with these displays.New firmware today solved the problem anyway

author: DrGeoff
author_rank: Frequent Contributor
timestamp: July 22, 2011, 11:32:38 pm
content: As suspected, driver problem.These displays have documented timing characteristics and are synchronous in operation, so the driver must have ignored something along the way.

author: Chet T16
author_rank: Frequent Contributor
timestamp: July 23, 2011, 04:44:15 pm
content: But that doesn't explain why some displays work and some don't, unless HD77480 displays aren't necessarily compatible?

author: Unknown
author_rank: Unknown
timestamp: July 23, 2011, 06:13:49 pm
content: Exactly, not all 'HD44780-compatible' displays are as tolerant for protocol violations than others, and some just don't meet the HD44780 specs.

author: DrGeoff
author_rank: Frequent Contributor
timestamp: July 23, 2011, 11:00:31 pm
content: You would need to attach your scope or logic analyser to it and see what the timing is compared to the datasheet for the display. Quite a few of these require long delays, setup and hold times.

author: Chet T16
author_rank: Frequent Contributor
timestamp: July 24, 2011, 09:03:48 am
content: The displays were $3 ebay china jobs so i think any datasheets are unlikely!

author: Unknown
author_rank: Unknown
timestamp: July 24, 2011, 12:37:30 pm
content: Isn't there just some standard IC like the KS066 on there? Or is it the good old blob of epoxy on PCB? You can sometimes find datasheets by searching for the number on the PCB.