Monday, October 15, 2007

fry

Today I am going to talk about frying electronics. According to arcane lore, all electronics function by means of a mysterious substance called the Magic Smoke. It is inserted into the components when they are manufactured, through a highly secret alchemic process. Whenever the magic smoke is released - for instance through subjecting the component to an electrical current many times the one specified for normal functioning - it ceases to function. This is sometimes accompanied by strong luminous or acoustic events (flash-bang). Other times, depending on the energy involved, it also results in flying sparks and shrapnel: "Timmy, put down that transistor! You might poke somebody's eye out!"
Although sometimes embarassing, especially when frying something worth a lot of money, accidentally killing electronic components is seen by engineers and amateur enthusiasts alike as sort of an initiation rite.
Frying electronics can be the result of numerous mistakes, such as:
  • applying a voltage of incorrect polarity or magnitude - this results in internal breakdown or excessive conduction, which allows large currents to flow. Large currents times some voltage equals large Joule dissipation equals melting, and sometimes pressure increase = bang!
  • allowing too great a current by wrong selection of component values - see above
  • using a small resistor instead of a larger one (ohmically or mechanically) - ouch, it burned my fingers! Also see above.
    • in particular, short-circuiting something that can deliver a large current does indeed that, sometimes with unpleasant results.
As you can see, it's always about overstress. Some particular cases include:
  • electrolytic capacitor overvoltage - fizz, bang
  • screwdriver across electrolytic capacitor - bang, sparks, screwdriver welded to terminals, capacitor internally overheated and mechanically stressed - bad
  • diode across mains - boom, blown fuse (trust me and don't try)
  • integrated circuit inserted backwards in socket - what students do in the electronics lab in the Bucharest Polytechnic to confuse their teacher - "Teacher, the circuit is not functioning, come take a look, I guess we wired up the thing wrong! [.......] So it's defective? Well, then, could you just let us off?" - the sockets are hidden on the back of the board and the traces and resistors are on the top side, for some arguable reasons like clarity and "don't touch those ICs, we don't have many more replacements! You don't need to see how those sockets work! Google it or something." -- doesn't work :)
  • electrostatic discharge - ellusive, nasty and sneaky.
Many components such as integrated circuits are designed to shut down when overheated to try and prevent further heating. This sometimes works, but not always. Most are designed to shut down or limit their output current when short-circuited, but not all. Some are even designed to survive reversing their supply voltage, but again, some aren't :) In any case, most will not survive severe overvoltage. Resistors, capacitors and diodes are not designed to survive overstress and will heat up. Some will fail open-circuit, so the heating stops quite rapidly, but others will continue to heat up until they blow violently. Bad, m'kay? In any case, open-circuit is a relative term. Under sufficient voltage, any material or gap becomes conductive.

There are also more interesting ways of frying electronics. We had some "Digital Computers" labs where we would design some simple stuff involving digital logic and stuff it into an FPGA and test it. Worth mentioning is the famous "Automatic coke dispenser" that was simulated using switches for dropping coins and LEDs* for releasing bottles as well as for internal diagnostics. *) Under the right conditions, any diode can emit light in the form of thermal radiation. Most can only do it once.
The coke dispenser never worked, partly because it was very easy to do the equations wrong, partly because the state machine was hand-designed and hand optimized instead of being written in some behavioural language, and partly because there was no switch debouncing. But, it taught us about whistling bits into an FPGA and reminded us how to hand-design stuff.
Another interesting one was the "robot ant" that navigated through a maze. It had VGA output but that module was already written so it was very cool (dude! video output dude! on the fucking monitor dude!) but not that challenging. The ant always looked like it had a blind desire to mate with the walls, but hey, it was all done in hardwarde. Sort of.
Years passed and one of my friends had to go through this lab. He asked me: is there some way you can fry an FPGA by misconfiguring it? I immediately said no, thinking of the usual mistakes one might do when generating the configuration bitstream, the same mistakes one would do when doing classic C programming for instance. After all, an FPGA is a very, very expensive thing to fry and you wouldn't want to be able to do that in software. Not easily at least. And the guy was sincerely concerned and I had to calm him down. And then I thought, well, if you wanted to fry it, I guess you could very well do that. (Don't!) You could for example take the clock and use an internal PLL to multiply it 6, 7 or even 10 times, maybe even way beyond what the chip is specified to properly function at. Then you would clock all the possible flip-flops with that, and tie all the combinatorial logic to it for good measure. That would surely overheat the chip in no time. If you're lucky, you might even blow up the power supply. If you're really lucky, the power supply might think you're short-circuiting it and shut down, preventing you from frying anything. Anyway, don't do such stuff.
Then (read hack a day!) I learned of a design that can really fry itself by software. It's a brilliant design actually, if proper protection is added. But it's just for proof of concept. Say you want to control a switching power supply by software. Need I say more? :) There's no greater opportunity for self-frying than this. This said, I would never trust software to keep me alive. I don't really know why we allow so many bugs to exist. I mean, when you design something physical, errors can creep up, but usually you do all the calculations and show that the stuff is going to function as planned. Not with software. Nobody does state diagrams and flowcharts anymore. In high school, we used to laugh when the teacher was trying to push flowcharts onto us. "What? Flowcharts?! That fucking looks like it's from an old sixties manual, I want to write some code!". Well. I admit it, I myself hate both flowcharts, Petri nets and proving algorithm corectness. Hell.

No comments: