There are probably many people who think that microcontrollers are bug-free. After all, they are glorified integrated circuits; a hard-wired jumble of infinitesimal transistor logic gates. There should be no unexpected behavior, as long as you operate the device within the rated voltage and temperature parameters….
Wrong!
What we tend to forget from our CPU architecture classes is that a CPU actually has a program inside. Known as microcode, its primary function is to interpret each instruction into the right electrical signals to drive the various parts of the CPU. For example, an addlw 0x7F
instruction might involve directing the ALU’s input to the next word in program memory (0x7F), and then telling the ALU to add it to WREG, with output set back in WREG. The microcode for addwf MyVar
would be different again; it needs to get a value in RAM, and set the result back there too.
Well, where there is a program, there will definitely be bugs.
My first experience with a microcontroller bug cost me several weekends of frustration, fretting, and frantic but fruitless rework. Here’s how it happened:
Oscilloclock Gone Wild
It was the early days of the Prototype, And things were looking great! My dream was coming to fruition! Except… every once in a while, the clock would go absolutely berserk. Seemingly at random, it would start displaying crazy, meaningless images, and controls would cease to function. Sometimes it would recover; other times, it would exhibit brain death – requiring a hard reset.
April Fool’s? No – it’s a PIC bug!
No amount of testing or experimentation could tell me what the problem was. I rewrote huge blocks of code. I removed massive chunks to simplify the code. I drank more and more coffee. Sleepless nights and grumpy days ensued, wasting my precious youth!
Continue reading →