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.
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!
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.
This is why you use test cases during development. They can be used to examine the behavior of the code in case of circumstances that rarely occur otherwise.
It is a good idea to test all possible code paths this way, especially error detection and error recovery.
HELLO,
you proffesional poeple are soooooooooo right
GOODBYE
I call this the "Proven-Product" Syndrome. love that name.
anyhow, there is another case of the "Proven-Product" Syndrome which is that something works because some routine unrelated to where the design error is happens to be fast enough or slow enough to hide the design error. Then when something is changed in another part of the code or some change in input happens BOOM! the design error show up. I have experienced that some, when this happens, work night and day on the code they changed simply because they were blind to the cause being in code they did not change.
Erik
If you found one timing error check all the code. I had the same issues years back. Also with an I2C EEPROM. Except it worked for over 3 years. The "Good" and "bad chips back to the manufacturer. I was told the "Good" chip exceeded the timing spec. while the "bad" chip was in the middle.
I agree. Testing alone is not adequate assurance that the product really works. You need design and review and analysis to know that it works, as well as testing. The more independent "guarantees" you have, the less likely it is that you screwed them all up at once.