lcd display repeats the same digit twice

only few times
did you notice 'time'
indicative of a timing error

Erik

Erik - you are now expected to log into his computer, look at the code and suggest improvements. Members on this forum can obviously not help since no code has been posted - remote debugging with zero source code is kind of hard.

hi i tried to upload code but the keil form says service unavailable,the file contains 83KB it might be the reason, if you suggest any other way to upload the file i can do that
thaks for the prompt reply

pastebin, google drive, microsoft sky drive? The internet abounds with resources...

I suggest you don't consider uploading 83K of source code. It's unlikely that anyone here would have the time to rummage through it.

hi i have changed circuit board still error not eliminated
i have checked with another lcd display though error not eliminated
i simulated the code in keil software it works without error
i have simulated in proteus VSM the code works fine
so i think there may not be nothing wrong with my code is there any common error with AT89s52 or jhd162a? is these device are temperature Dependant?
few times i found the same project worked well in the night time but it never worked in the day time,this problem happens only when i pick data from the temporary RAM to display in the LCD, but no problem when the data is taken from EEPROM of controller to display.
if the code is needed, suggest me the way to up load the code. i could not upload in the keil form. code size is 83kb

Far more likely to be an error in your code and/or hardware. A common error there would be timing...

Have you used an oscilloscope to verify that the interface timing, etc, is correct?

"i simulated the code in keil software it works without error
i have simulated in proteus VSM the code works fine"

So think about the kinds of problems that would not be evident in a simulation...

These types of displays are very dependent on signal TIMING, if you toggle or sequence signals at rates beyond those specified in their DOCUMENTATION, you will likely see corrupt or garbled displays. Get the documentation, review it, compare it to your code, and stick a scope on the physical hardware and confirm for yourself what the timing looks like, in reality.

Simulators are NOTORIOUSLY poor at reflecting behaviour of arbitrary peripheral hardware, this comes down to the low cost, and inadequate modelling. It's certainly possible to create adequate models, but it's a bit beyond the price the average punter is prepared to pay, and you basically get what you pay for.

"so i think there may not be nothing wrong with my code is there any common error with AT89s52 or jhd162a? is these device are temperature Dependant?"

The general conclusion when something works should be:

"There must be something wrong with my stuff."

You really think a simulator can prove correctness? It can detect some errors so a simulator is a valuable tool. But it isn't a reference that can be fully trusted to give results that are matching the real world.

Whenever you look at a datasheet for a component you are using, there are a large number of statements about limitations and requirements. They are basically a contract between you and the component supplier. It is up to you to fulfill all the requirements in the datasheet, or the component can't be trusted to behave as intended.

So every timing value you see in a datasheet has to be verified by you. Do you fulfill all setup times? All hold times? All rise times? All fall times? All min/max voltages? All currents? Capacitive loads? ...

There is a reason why logic analyzers, digital oscilloscopes etc are quite common tools when doing embedded development. You need real hardware tools to prove much of the parameters specified in the datasheets.