my code is 110% correct; eg no errors and runs properly. see.
int _val; int myfunc2(int val) { _val = val; return _val; }; int Bar(int val) { return _val + val + 1; }; void myfunc1(int val) { _val += Bar(val); }; etc etc etc
it doesnt give me the right answer sometime.
HEEEEEEEELLLLLLLPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
"when a chip's datasheet says it takes at least time {T} after the falling edge on pin X before pin Y has settled on valid data, what you not do is read Y immediately after pulling down X. You delay it as long as feasibly possible, typically until immediately before pulling down X again."
that's slightly different. here you have a case of a moronic programmer writing a moronic piece of code that would NOT work regardless of cpu frequency, peripheral speed, or any other external conditions, as it is in direct contradiction to the datasheet.
basically, the programmer has no idea of what s/he is doing and that's in direct contradiction to the early statement of the bug being exposed only under the right combination of cpu frequency, peripheral speed / etc.
The programmer just admitted to having written bad code that should never have worked - and yet it did!!
I think most experiences programmers have been in the position, at some point, of looking back at their code and thinking, "how on earth did that ever work??!"
here you have a case of a moronic programmer writing a moronic piece of code that would NOT work regardless of cpu frequency, peripheral speed, or any other external conditions, as it is in direct contradiction to the datasheet.
Sorry, but you still don't get it.
That code does work in its original surroundings. It works by coincidence rather than by design, but still...
The CPU was, in fact, so slow that even a read "immediately" after pulling down the clock was still happening long enough after the clock edge that valid data was available by then.
"That code does work in its original surroundings. It works by coincidence rather than by design, but still..."
not sure about that. sounds like 1) whether it had worked had nothing to do with a) cpu frequencies; b) peripheral speeds; or c) external devices, and 2) the only reason it worked is that the cpu was NOT functioning as it should per the datasheet.
that contradicts the notion that the bug is the result of a) cpu frequencies; b) peripheral speeds; or c) external devices.
"The CPU was, in fact, so slow that even a read "immediately" after pulling down the clock was still happening long enough after the clock edge that valid data was available by then."
that's irrelevant to this discussion, had the cpu worked as described in the datasheet. so the bug here is really the hardware bug, not a software one, except that the moronic programmer couldn't realize it.
the only reason it worked is that the cpu was NOT functioning as it should per the datasheet.
What on earth are you talking about? Hans-Bernhard Broeker presented a perfectly logical explanation for the observed behavior.
except that the moronic programmer couldn't realize it.
Such mistakes are rarely related to one being a moron. Everybody makes mistakes, and as specified already- sometimes it the environment, not the code itself!
On the contrary - it is entirely pertinent!
It is actually quite a common type of mistake - especially when using a "slow" CPU with a "fast" peripheral.
And it is exactly the type of problem that can give the situation of the OP; viz, the code builds fine, works most of the time - but occasionally fails.
It's even likely that the code would work fine in an instruction set simulator like the one in uVision.
2) the only reason it worked is that the cpu was NOT functioning as it should per the datasheet.
Interesting how you assume to know whether or not my CPU here was functioning acccording to its data sheet. Particularly since you certainly don't have the slightest which CPU that might even was.
that contradicts the notion
The "that" you're referring is pure speculation on your part, so there's no way it can contradict anything.