hi to all from last two 3 day's i strucked with some the problem. i have already done the i2c routine for AT24c04. Which works fine i can read from that and can write in. now i am going to use the LCD and printing the string on that i also developed small VB6 application to send the string to LCD. now what i tring to do the string which i passing from PC should be printed to LCD and to be stored in EEPROM. But the problem is that the string is printing on LCD but not get stored to EEPROM. EX.ABCDEFGHIJKLMNOP is the string which i pass to LCD it properly printing on LCD.but not get stored in EEPROM. When i read EEPROM it show's me the A C D F H J L N P these parameter get stored in eeprom. before this project i have complited lot much EEPROM contain instrument in which i can READ and WRITE EEPROM Without any problem.and still working so nicely. canany one tell me what is the peoblem.
nobody can help you with code they can not see
Erik
thanks for showing intrest but i solved it the problem with the STOP to START time delay by incresing this delay all thing work fine but i wondered how the same thing working fine from last 2 years. and now rise the problem.
That is typical of timing errors, or anything else that has not been properly designed to work throughout all the tolerances of all the parts!
You have just been lucky for 2 years!
By some happy coincidence, you just happen to have had parts just at the "right" ends of their tolerance spans so that your timings just happened to work.
I call this the "Proven-Product" Syndrome.
Your luck has run out as something has drifted with age, and/or you have new parts that operate in a different part of their tolerance band. Depending on how marginal your system was in the first place, this could require only very small changes!
This is a perfect demonstration of why just saying something "works" is virtually meaningless - it needs to be specifically designed to guarantee that it will always meet all specifications for all conditions within all allowable tolerances.
And "testing" doesn't mean just trying it and seeing it "work" - you need to test at all limits, and check all possible error conditions.
The original code maybe didn't perform several back-to-back write operations.
The original code maybe didn't perform several back-to-back write operations yes!!!! the delay timing as per data sheet is 4.7 µsec and i am using the 24MHz Crystal for and provided 5 NOP so it is much much greater than they said.so i am not lucky from last 2 years i work a lot for this if there is some mistake (but i dont think so) i am ready to learn.
You are so right Andy.
As I once wrote, in another context:
"It does not matter that it works. A program can contain deadly potential failures, sometimes so obscure that it takes the eye of an expert to detect them (this is not one of then, though), and to function normally most of the time. We just cannot be oblivious to detail."
Is the full code in assembler or did you inline the NOP instructions?
Have you verified that your 5 nop really resulted in > 4.7us pause, when compiling with the current version of the compiler?
OK, so the "luck" in this case was that you hadn't exercised the flawed part of the code before!
So, again, the fact that it's been "working" for 2 years doesn't guarantee that it's bug-free - just that the bugs haven't manifested themselves yet!
As Erik keeps saying, testing doesn't prove the absence of bugs - just that you haven't managed to find them yet!
View all questions in Keil forum