Character Display Problem

[Chet T16]

So I assembled both my tuxgraphics power supplies but i'm having trouble with both displays

 

I'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?

[PeterG]

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

[IanJ]

Hi,

Post your Arduino code.

Ian.

[jahonen]

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

[Chet T16]

Thanks for the replies.

Both are running the default code from tuxgraphics and the display is soldered using a couple of inches of ribbon cable



The buttons and voltage output work correctly (i haven't tested the current limiting yet)

[Neilm]

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.

Yours

Neil

[Chet T16]

I have tried three different power supplies, two wall warts and the laptop SMPS i intend to finally run them from

There 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 too

So 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.

[alm]

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.

[Chet T16]

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 be

From the make file:

Code: [Select]

#-------------------
# 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 rdfuses
rdfuses:
$(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:m
fuse:
$(LOADCMD) -p  $(DUDECPUTYPE) -c usbtiny -u -v -U lfuse:w:0xa4:m
$(LOADCMD) -p  $(DUDECPUTYPE) -c usbtiny -u -v -U hfuse:w:0xd9:m
Checking using avrdude

Code: [Select]

C:\Users\Chet>avrdude -P USB  -p m8 -c usbtiny -v -q

avrdude: Version 5.10, compiled on Jan 19 2010 at 10:45:23
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\WinAVR-20100110\bin\avrdude.conf"


         Using Port                    : USB
         Using Programmer              : usbtiny
         AVR Part                      : ATMEGA8
         Chip Erase delay              : 10000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page
      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
W   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
           eeprom         4    20   128    0 no        512    4      0  9000  90
00 0xff 0xff
           flash         33    10    64    0 yes      8192   64    128  4500  45
00 0xff 0x00
           lfuse          0     0     0    0 no          1    0      0  2000  20
00 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  2000  20
00 0x00 0x00
           lock           0     0     0    0 no          1    0      0  2000  20
00 0x00 0x00
           calibration    0     0     0    0 no          4    0      0     0
 0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0
 0 0x00 0x00

         Programmer Type : USBtiny
         Description     : USBtiny simple USB programmer, http://www.ladyada.net
/make/usbtinyisp/
avrdude: programmer operation not supported

avrdude: Using SCK period of 10 usec
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x1e9307
avrdude: safemode: lfuse reads as A4
avrdude: safemode: hfuse reads as D9

avrdude: safemode: lfuse reads as A4
avrdude: safemode: hfuse reads as D9
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

I'm assuming the A4 and D9 bits are the only important things to compare?

[DrGeoff]

Looks like an LCD driver problem.

[bobski]

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?

[Chet T16]

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!

[bilko]

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!

So the tuxgraphics firmware is the cause of the problem then ?

[Chet T16]

Well, yes, but it's normally fine. I was just unlucky with these displays.

New firmware today solved the problem anyway

[DrGeoff]

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.

[Chet T16]

But that doesn't explain why some displays work and some don't, unless HD77480 displays aren't necessarily compatible?

[alm]

Exactly, not all 'HD44780-compatible' displays are as tolerant for protocol violations than others, and some just don't meet the HD44780 specs.

[DrGeoff]

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.

[Chet T16]

The displays were $3 ebay china jobs so i think any datasheets are unlikely!

[alm]

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.