When I attended a Microchip PIC seminar in the mid 1990's (when they were all EPROM-based, not flash, so erasable ones had a window), we were told to keep the window in the package covered even when programming so it would work right, even though leaving it uncovered would not give nearly enough light in the short amount of time to cause any erasure. Ten years earlier however, I worked in applications engineering at a VHF/UHF power transistor manufacturer, mostly in power MOSFETs, and we regularly had light on the bare dice when they were in circuits putting out their RF power. I suppose the much greater thickness of the layers in the silicon prevented trouble. The MOSFETs put out up to 150 watts each, continuously, at 175MHz. The bipolar transistors put out up to a thousand watts each (pulsed), at 450MHz IIRC. These were mostly for military radars.
I once had a device that worked... but only in the dark. The problem was a sleeper -- and had nothing to do with unconnected CMOS inputs. Another time I accidentally created a situation where a program relied on the contents of one uninitialized byte of memory (which, after power-up, was unfortunately about 95% consistent).
barrym95838 wrote:
You didn't tell us the story, doc!
[the uninitialized-byte problem is described here]
I wrote:
As for the system that only worked in the dark, that was much simpler. I was using an EPROM-based microcontroller (MC68HC705), and in those days I never bothered to cover up the little window in the EPROM because I didn't know any better and had never had a problem. Fortunately, when my luck ran out a colleague informed me that photoelectric effects can upset the chip, and it really is best to cover the window so it's kept in the dark.
Users browsing this forum: AhrefsBot, claudebot and 0 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
The problem was a sleeper -- and had nothing to do with unconnected CMOS inputs. Another time I accidentally created a situation where a program relied on the contents of one uninitialized byte of memory (which, after power-up, was unfortunately about 95% consistent).