Archive for July 7th, 2009
My buddy Eks recently acquired a “guaranteed broke” Tektronix 492 spectrum analyzer that turned out to have a defunct memory board: the ROM holding the initial boot firmware has a bad checksum. He verified that by swapping in a memory board from another 492 and found it worked perfectly.
The original board used Mostek MK36400 8Kx8 masked ROMs, but they can be replaced by either 27HC641 or (in a pinch) a quartet of 2716 EPROMs. Being a stickler for authenticity, Eks picked up some 27HC641 chips. That means we need a device programmer, as none of the burners we have know anything about 27HC641s. There are other ways of getting the job done, but this has the advantage of getting me some face time with my role model for being a Renaissance Man.
To make a long story somewhat shorter, the 27HC641 is a 8Kx8 EPROM in a 24-pin package with the usual 12 address lines, 8 data lines, power, ground, and a single chip-select / output-enable / programming-voltage pin. Normal EPROMs in 28-pin packages have separate pins for all those functions to make life easier.
Anyhow, the CE/VPP supply must provide 30 mA at 12.5 V as well as the usual minuscule FET logic currents at 5 V and 0 V. The VCC supply must cough up a staggering 90 mA during normal operation at 5 V and 30 mA at 6 V during programming. Both supply voltages must switch between three levels: unnaturally high during programming, 5 V for normal operation, and 0 V for output-enable and during chip removal / installation in the programming socket.
This being an entirely one-off project, I used good old LM317T regulators with a handful of transistor switches to vary the voltage and clamp the output to ground. The CE/VPP supply looks like this:
An Arduino will drive the gates of Q2 & Q3, with all the programming logic and timing handled by software. The shortest VPP pulse is a millisecond long, so that’s not a real restriction, and the verification can happen at nose-pickin’ speed. That simplifies a lot of other things about the project, too.
Q3 selects the output voltage: gate high = 5 V, gate low = 12.5 V. The scope shot shows the gate driven with a 500-Hz square wave, which is about the right width for the programming pulse.
I prototyped this on a solderless breadboard (ptooie) as shown above with 5% resistors, so the actual voltages aren’t quite nominal. The readout says 13.28 and 5.3 V, which will need some trimming to get inside the EPROM’s 5% spec.
The 1 nF cap at the LM317 Adjust terminal encourages stablity by knocking off the high-frequency stuff and slowing down the transitions just a smidge. The datasheet suggests up to 10 µF, which turns the transitions into triangles.
The LM317 can only supply current to its load, so reducing the output voltage requires the load to draw current from C3. Because this is essentially a DC application, C3 can be quite small: there won’t be any other switching going on during the programming pulse. The datasheet recommends 1 – 10 µF, but definitely more than 5 nF.
The LED is actually a key part of the circuit, as it draws current to pull the output voltage downward: more LED current = faster transition time. However, higher C3 = slower transitions.
Seen at a higher magnification, the falling edge of the output waveform shows a decay that lasts 50 µs or so. The LED draws maybe 12 mA at 13 V, so the voltage across C3 should drop at
(1/100 nF) x (12 mA) = 120 V/ms
Applying a straightedge to the early part of that curve looks like 25 V in 100 µs; call it 250 V/ms, maybe a bit less.
What’s a factor of two among friends, particularly given the tolerances on ceramic caps?
T1 and Q1 (I don’t know why Eagle’s models use both T and Q as transistor prefixes, it’s probably an international thing) switch the output line between the LM317 and ground; I suspect just turning T1 off would work as well, but this way the chip pin is firmly held to 0 V, where it should be, regardless of leakage and other oddities.
Because Q1 crops both sides of the transistion, the rise and fall happen in nanoseconds rather than microseconds.
So, now that I know this will actually work, I can build a PCB and write some firmware…
Memo to Self: make sure the code waits for the output transitions. Methinks delayMicroseconds() will be a constant companion.