Failure Is Not An Option
When things don’t go as planned it can cost you money, loss of face or even loss of lives. But the thing is, when failure is staring you in the face, what can you do about it? and what can you learn from it.
During my time in the embedded industry I have thankfully, enjoyed many successes (I wouldn’t still be in the industry otherwise!) but along the way I have made some mistakes but gained a heck of a lot out of the experience.
For example there was a time when micro controllers came only in OTP (one time programmable) versions, Non of this re programmable ‘flash’ stuff we have today.
Being OTP meant that, you needed to get that code right or else!. Certainly this is not an issue if you are producing a handful of prototypes, but if you are doing a decent production or pre production run, you can easily end up with a stack of boards which will be good for nothing!.
I faced this exact issue on a product of mine. We had produced 1000 pcbs all with one of the Microchip Inc PIC12C509 micro controllers on board. Designed in such a way that the devices could be programmed in circuit after board assembly.
The product in question interfaced to a special type of ‘touch’ switch which needed debouncing. Unfortunately in my haste, I forgot to set the default value for the debounce time to a reasonable value making the switch ultra sensitive.
Arrghh! DISASTER! Well no, not quite.
As stated above, these devices are OTP only so there was no chance of erase and reprogram!, but there was still a way. Even though erasure was not an option, programming un programmed bits was still available.
As some of you realize, when a device is un programmed (shipped from the factory) all its bits are normally set to ‘1′. Once programmed the bit is set to a ‘0′. (i.e. If the instruction/data byte needs that bit set to ‘0′…I can get into convoluted discussion here, but I shall try to refrain!)
So what? you ask. Well, if I could find where exactly in program memory the debounce value is referenced, maybe I can toggle some of the un programmed bits to a usuable debounce value. This was not as simple as I thought, due to the fact that I needed to raise the debounce value, meaning that I needed more bits set not unset. (Think about it a bit…)
Luckily for me though, the next byte after the debounce value was a return instruction followed by some unprogrammed bytes. This allowed me to change both the debounce value and the return instructions with NOP’s instruction, letting the program now skip through to the un programmed bytes where I could enter a new value and a new return instruction.
OK, so problem solved. But it may have been a different result for those who do not understand the underlying processes of what is a bit and what it means to be programmed or un programmed.
Anyway, that said, I would like to hear your ‘great escape’ from failure stories. Please drop me a line here and share your experiences.
