Electronics > Repair
Keithley 199 repair FIXED another one
samofab:
Hello everybody.
A while ago I bought a badly beaten Keithley 199 from Israel. I found it hilarious that I used hammer to fix a precision instrument, but none of the internals were broken and after a good hammering it powered on and all of the functions worked. In addition it seemed that it is within spec as far as I could test it (<0.09%).
It did have one problem, and that was that it displayed UNCAL when powered up and refused to save any settings when powered off. I thougth to myself: just a broken E2PROM - order a new one a I have a fine instrument (i did check the usual suspects before: supply rails voltage, noise, signals on PROM). Well, it turns out that replacing Xicor X2816C doesn't help - it still didn't save any settings (in addition beeing completely uncalibrated with empty PROM). So I put the old one back inside and used the instrument as is. It was slightly annoying, but for observing small current changes in microcontrollers it was perfect. And you can read the display from the next building :-D
Still it bothered me and as I had some free time, I hooked up signal analyser and tried to figure out what is its problem. Turns out that data and address lines are pushing data around and that timings on OE, WR and CE required for writing to PROM look within spec.
The only possibly weird thing is signal from PAL address decoder to CE - see attachment, all other signals are nice squares when using oscilloscope.
When saving settings (GPIB address, line frequency and MUX) there isn't a lot of data to push to PROM, but my OpenBench logic sniffer makes it hard to look at it as Keithley is writing a byte every 100ms. The first four bytes are 0x00, 0x0, 0x0, 0x01, I doubt that there are many more (write cycle finishes in less than a second).
Does anybody have any ideas? Am I looking at completely wrong place?
staze:
Boy that's some noisy data. So, where is that scope trace taken from?
Since I recently fixed my Keithley 199, I kind of wonder if it might be a similar issue. Mine, the hex inverter between the analog and digital board was bad, and producing crap. But, I'm guessing that's not bad in this case since the meter works, you just can't save data to the eeprom.
Do all the voltage rails check out fine (again, guessing so since the meter works)?
samofab:
Scope trace is taken from pin 15 of PAL address decoder wired to CE input on PROM. All of the other outputs on PAL are nice signals.. I'm wondering how PAL's fail... Because if this one failed, it did so in a very non-destructive way as reading from PROM wouldn't be possible without working CE. Signal is suspicious, but I doubt that this is the root of the problem. Trouble is I have nothing to compare it to. Perhaps it is normal for CE signal to occur once every 100ms on write. And even though it's an ugly signal, it's still above treshold for logical 1 all the time (.. when it should be).
If you have a working K199, perhaps you can put the scope to this pin and see if behaves similiary when storing settings.
All of the power supply voltages are fine, even when measured directly on the chips - no significant noise or voltage drops.
It's a complete overkill, but without a better logic analyser, I'm thinking of wiring a microcontroller to data pins and dump the exact bytes that get written (should get written)...
Thanks for reply...
staze:
--- Quote from: samofab on August 26, 2013, 10:41:21 pm ---Scope trace is taken from pin 15 of PAL address decoder wired to CE input on PROM. All of the other outputs on PAL are nice signals.. I'm wondering how PAL's fail... Because if this one failed, it did so in a very non-destructive way as reading from PROM wouldn't be possible without working CE. Signal is suspicious, but I doubt that this is the root of the problem. Trouble is I have nothing to compare it to. Perhaps it is normal for CE signal to occur once every 100ms on write. And even though it's an ugly signal, it's still above treshold for logical 1 all the time (.. when it should be).
If you have a working K199, perhaps you can put the scope to this pin and see if behaves similiary when storing settings.
All of the power supply voltages are fine, even when measured directly on the chips - no significant noise or voltage drops.
It's a complete overkill, but without a better logic analyser, I'm thinking of wiring a microcontroller to data pins and dump the exact bytes that get written (should get written)...
Thanks for reply...
--- End quote ---
I'll see if I can pull my 199 off my bench this weekend and scope that pin. I'm guessing it should look better than that...
weird.
What are you grounding off when measuring? hmmm.... I'll take a look at the schematics too... but yeah, that does seem weird. And I'd obviously assume you're using a 10x probe, and 1M scope termination (just making sure the scope isn't dragging down that pin).
And sorry, what is the designation of the PAL? U1? Have you checked C1? Or any of the other pins out of U1? I'd be curious if any other pins are showing bad signals. It also looks like pin 23 on U8 should be a clock? Same as pin 16 on U1 (the PAL). I'd be curious how that looks. Pin 17 should also be a clock, that feeds U16 (74HCT374 pin 11), and U15 (same pin, logic chip).
Actually, looking at the schematic, I'm kind of curious about U17 (74HCT02). Looks like it controls the reset, as well as the NVRAM write enable.
All that said, I'm just stabbing in the dark since I didn't deal with the digital board much on mine. But I'll try to check pin 15 on U1 when I have a chance. I just kind of wish U1 wasn't such a black box...
samofab:
When measuring, I'm grounding the probe on the nearest chip ground. So in the case of U1, I have ground on pin 10. Using x10 probe. All of the other outputs on U1 are nice squares. I also measures power supply with oscilloscope exactly over pin 10 and 20, which corresponds to C1, too. No way to be really sure if C1 is OK unless I take it out, but I reckon that bad C1 would produce some artifacts on the power line directly on the chip.
PAL's are not entirely blackmagic. They are stateless in the sense that if you have 10 inputs and 8 output, all you need to do is walk all input combinations and record the outputs.. not that it helps in my case as I'm not sure if it works correctly :-D (And I'm not really an expert, I might be completely wrong..)
Pin 23 on U8 is not clock, but the same CS (chip select) system that tells the chip that address/data on the bus is intended to it. Well it may work as a clock in the sense that its transition from low to high is used to latch data (not sure if that is the case on this particular chip). (again nice squares on this pin with oscilloscope).
I was thinking about the function of U17 and I think that it partly reponsible to make sure that writing to PROM is disabled on power up. There is a combination OE/CE/WE mentioned in the datasheet to this effect. Beeing a simple gate, I checked it and it most certainly works as it should.. NORing all the way :-D
I'm thinking of pulling U20 out and see if the weird signal persists (PAL may not be guilty). And while I have it out of the board, I might as well find a programmer to read its contents and write them to the spare PROM that I own.
Anyway, if you would be so kind to look at that signal and tell me how it looks on your end, that would eliminate a lot of guesswork. And I'm principally not interested in the analog domain, but how this signal behaves when writing.. will you see the same single drop to 0 on start, and then 100ms of silence, or is it supposed to push out something more. I guess in principle that it might be possible that PAL got one additional fuse blown in the course of its heavy life and that there are two side effects: weird signal in analog domain and more importantly: decoding less than it should.
Navigation
[0] Message Index
[#] Next page
Go to full version