I do, I do! After spending weeks intermittently puzzling over sporadic, but semi-deterministic odd behaviors on the chip I was hacking firmware for at work (you know, like return instructions that didn’t return), and throwing in "good-luck NOPs" until mysterious problems just as mysteriously went away (and hoping they didn’t return), I go and manage to dig up an errata sheet and find the following:
Certain code sequence and placement may cause
the corruption of a few bits in the instruction fetch
when the part is used above 4 MHz. A corrupted
instruction fetch will cause the part to execute an
improper instruction and result in unpredictable
outputs.
Microchip cannot predict which code sequences
and placement will cause this failure. If this failure
mechanism exists in your system, it should be
evident during statistically significant preproduction
testing (minimum suggested sample
size 100 units) of your particular code sequence and placement.
Yeah, that’s nice and helpful. Umm…we have *2* units. (How do products like this make it out the door?) Anyway, if my travels ever take me near Microchip Systems HQ, I am planning a free seminar on embedded systems. (Umm…Title will be ‘Innovative boot-up procedures’)
QOTD: “I recently saw a distraught young lady weeping beside her car. “Do you
need some help?” I asked. She replied, “I knew I should have replaced the battery to this remote door unlocker. Now I can’t get into my car. Do you think they (pointing to a distant convenient store) would have a battery to fit this?” “Hmmm, I dunno. Do you have an alarm too?” I asked. “No, just this remote thingy,” she answered, handing it and the car keys to me. As I took the key and manually unlocked the door, I replied, “Why don’t you drive over there and check about the batteries–it’s a long walk.”
Leave a Reply