开云体育

495P A54 Memory Board Troubleshooting: continued

At some risk of wearing out my welcome here with multiple posts on this topic, however, I am seeing this instrument and its various circuits for the first time and can use as much experienced advice as I can get.

Situation:

495P SA s/n B030xxx: Purchased with the representation by the seller that the A54 memory board is defective. SA boots up in somewhat expected fashion, except that on-screen message identifies it as a 492AP, not a 495. However, substantial functionality is apparent but with several error messages; the initial screen is what one would expect for a 492AP and the cal signal produces typical SA traces.The microcomputer is running the 492AP firmware rather than the 495 firmware. Choice of firmware to run is based DIP option switch S1050 on the A54 memory board. When I install a known good memory board with option switch SW4 set to OPEN and all other option switches set to CLOSED, SA boots up with correct indications and no error messages; when I set option switch SW4 to CLOSED with all others closed, SA boots up as a 492AP just as it does with the defective A54 memory board.

Analysis:

After consideration of the symptoms and review of block and circuit diagrams in the service manual, it appears that the microcomputer controller in not reading the option switch setting correctly at boot up. IOW, it reads SW4 as CLOSED regardless of the switch position, and runs the 492AP firmware accordingly.

Possible causes:

Defective DIP options switch: Tested these with ohmmeter and readings are consistent with a working switch: 0 ohms closed, about 11K ohms open, which is close to what the circuit diagram suggests. These readings match those on the known good board. Can likely rule out switch on this basis.

Defective address decoder chip(s): The option switch is treated as a memory location in the controller I/O address space. Three decoder chips (U2045, U3040, U3045) are used to decode the option switch address and generate an enable signal to place the option switch settings on the 8 bit data bus to be read by the processor during boot up. This happens only once at boot up for a few microseconds at most, so somewhat difficult to trace. Decoders U2045 and U3040 are also used for other purposes on this board, and since the board is mainly functional, these dont seem to be candidates for replacement. U3045 decoder is used only for the purpose of enabling the option switches to the data bus, and if defective, would account for the problems I am seeing.

Defective U2050 74LS244 tri-state buffer: this chip enables the settings of the option switches onto the 8 bit data bus when the appropriate address on the address bus is detected by the decoder chips. If this chip is defective, it would very likely be the source of the problem.

Damaged circuit board: I have inspected this carefully with a magnifier and see nothing of concern so far. Have also checked the continuity of traces throughout the switch/decoder/buffer circuits and find no problems. The three 10mfd electrolytics on this board have been replaced.


Diagnosis:

Its probably not a defective option switch or defective U2045 or U3040 decoder, and probably not a circuit board problem. My best guess so far is a defective U3045 decoder or a defective U2050 tri-state buffer, with the latter perhaps more likely.

I welcome any insights/advice on this topic.

Rick
K8EZB

On Sat, 28 Jul 2018 08:26:52 -0700, you wrote:

If you have a dual channel scope, preferably one that does storage, or
a digital scope, or a logic analyzer, then you're looking for a
coincidence of the bus going to a 1 or 0 (at that output pin) when the
dir and OE are enabled on the driver chip. Alternatively, a chip
analyzer clip (HP, don't think that Tek ever made any) would work, and
you're looking for errors. Another option is to hold the reset pin
down on the processor, then using an HP logic pulser, see what the
output pin of the chip (bus side) does.

Your other option is to replace the chip. Note that it might be a
reasonable assumption that this particular board may be programmed to
ignore that switch, either through revision or because another option
is not enabled.

Guessing, though.

the main problem in finding this is that the switch is likely sampled
only on bootup. Hence, a relatively rare event unless you can put the
processor in a signature analysis mode (which cycles all the address
lines), that would give you a repeating pattern that would not require
a digital or storage scope.

If you had a signature analyzer, and you had the right signatures at
that chip, that would also be beneficial to know. They'd have to be
at that pin with the switch in a particular position, though.

Harvey

[Edited Message Follows]

495P A54 Memory Board Troubleshooting: continued

At some risk of wearing out my welcome here with multiple posts on this topic, however, I am seeing this instrument and its various circuits for the first time and can use as much experienced advice as I can get.

Situation:

495P SA s/n B030xxx: Purchased with the representation by the seller that the A54 memory board is defective. SA boots up in somewhat expected fashion, except that on-screen message identifies it as a 492AP, not a 495. However, substantial functionality is apparent but with several error messages; the initial screen is what one would expect for a 492AP and the cal signal produces typical SA traces.The microcomputer is running the 492AP firmware rather than the 495 firmware. Choice of firmware to run is based DIP option switch S1050 on the A54 memory board. When I install a known good memory board with option switch SW4 set to OPEN and all other option switches set to CLOSED, SA boots up with correct indications and no error messages; when I set option switch SW4 to CLOSED with all others closed, SA boots up as a 492AP just as it does with the defective A54 memory board.

Analysis:

After consideration of the symptoms and review of block and circuit diagrams in the service manual, it appears that the microcomputer controller in not reading the option switch setting correctly at boot up. IOW, it reads SW4 as CLOSED regardless of the switch position, and runs the 492AP firmware accordingly.

Possible causes:

Defective DIP options switch: Tested these with ohmmeter and readings are consistent with a working switch: 0 ohms closed, about 11K ohms open, which is close to what the circuit diagram suggests. These readings match those on the known good board. Can likely rule out switch on this basis.

Defective address decoder chip(s): The option switch is treated as a memory location in the controller I/O address space. Three decoder chips (U2045, U3040, U3045) are used to decode the option switch address and generate an enable signal to place the option switch settings on the 8 bit data bus to be read by the processor during boot up. This happens only once at boot up for a few microseconds at most, so somewhat difficult to trace. Decoders U2015 and U3040 are also used for other purposes on this board, and since the board is mainly functional, these dont seem to be candidates for replacement. U3015 decoder is used only for the purpose of enabling the option switches to the data bus, and if defective, would account for the problems I am seeing.

Defective U2050 74LS244 tri-state buffer: this chip enables the settings of the option switches onto the 8 bit data bus when the appropriate address on the address bus is detected by the decoder chips. If this chip is defective, it would very likely be the source of the problem.

Damaged circuit board: I have inspected this carefully with a magnifier and see nothing of concern so far. Have also checked the continuity of traces throughout the switch/decoder/buffer circuits and find no problems. The three 10mfd electrolytics on this board have been replaced.


Diagnosis:

Its probably not a defective option switch or defective U2045 or U3040 decoder, and probably not a circuit board problem. My best guess so far is a defective U3045 decoder or a defective U2050 tri-state buffer, with the latter perhaps more likely.

I welcome any insights/advice on this topic.

Rick
K8EZB

Harvey,

Thanks for your suggestions. I have a DSO (but none of the other gear you mention) which may be helpful, but perhaps easier just to change the IC.

RB

On Sat, 28 Jul 2018 11:48:10 -0700, you wrote:

Harvey,

Thanks for your suggestions. I have a DSO (but none of the other gear you mention) which may be helpful, but perhaps easier just to change the IC.

DSO works. Since the chip is one way only, you look at the schematic
and see where the offending pin is supposed to be output to the bus.
Let's assume it's D0, then on the input, you have a steady state 1 or
0 depending on the setting of the switch. So (looking at chip
connections:) 2 is the switch input, 18 is the bus. The chip drives
the bus when pin 1 is driven low. In your design, 1 and 19 are likely
connected together to get a full 8 bits.

Trigger the scope on a negative going pulse on pin 1. Examine the
waveform on pin 18. For the time that pin 1 is low, you should see a
low on pin 18 (the bus) assuming that the input on pin 2 is low. Don't
worry about what you see before or after, but during that time, the
output pin (18) ought to mirror what's on pin 2 (input).

Apologies if you already know this, but that's the first thing I'd do
without trying to remove anything.

All the other things (making stuff more complicated) were workarounds
if you had some things, and not others.

If the chip does not behave, then you at least have an idea of what's
going on. I'd check several switches to get a good idea of exactly
what goes on in this particular circuit.

Harvey

RB

Please don't continually re-edit your post - those of us who receive posts by email (most of us) set the same post over and over with minor edits.

Thanks
Dave

Harvey,

Will give this a try.

Thanks,

RB

Harvey,

After spending some additional time with the service manual. I see there is a way to cause the microcomputer to cycle through the full range of memory addresses on a repetitive basis. This is done by relocating a jumper on the processor board. Every time the options switch is addressed I should see the tri-state buffer enable line go low and the option switch setting appear on the output of the tri-state buffer/data bus (high for SW4 OPEN, low for SW4 CLOSED). This will repeat approximately every 154ms (if I am reading correctly), making verification much easier than if it is a one-time event with each power up. This should also isolate the problem to either the U3045 decoder or to the tri-state buffer. IOW, no enable to the buffer = decoder problem, incorrect option switch setting on the tri-state output = tri-state buffer problem. Getting closer! (I think!)

PS: Dave, Sorry about the re-editing. Necessary to correct some key typos. Now that I know this causes others problems, I'll try to get it right before posting!

RB

Rick, if I have a long message to post, I type it into something like Open Office Writer, or whatever word processing software you prefer. Once I'm happy with it, and have checked it for spelling errors, I copy and paste it into the new message. It helps me because of poor vision, because I can use a large font size while editing and the mistakes are easier to spot. I have nerve damage in one hand and Carpal Tunnel in the other hand so I find a lot of transposed character errors. This might help you, as well. I did some technical writing at my last job, and I didn't want to release any poorly written documents to the production floor. :)


Michael A. Terrell

On Sat, 28 Jul 2018 16:23:54 -0700, you wrote:

Harvey,

After spending some additional time with the service manual. I see there is a way to cause the microcomputer to cycle through the full range of memory addresses on a repetitive basis. This is done by relocating a jumper on the processor board. Every time the options switch is addressed I should see the tri-state buffer enable line go low and the option switch setting appear on the output of the tri-state buffer/data bus (high for SW4 OPEN, low for SW4 CLOSED). This will repeat approximately every 154ms (if I am reading correctly), making verification much easier than if it is a one-time event with each power up. This should also isolate the problem to either the U3045 decoder or to the tri-state buffer. IOW, no enable to the buffer = decoder problem, incorrect option switch setting on the tri-state output = tri-state buffer problem. Getting closer! (I think!)

Yes, This is the signature analysis mode. It causes the processor to
do no-ops (works on older processors and was in a lot of the TM5000
stuff as well as other scopes of that generation). The no-ops cause
the processor to execute an instruction that does nothing, it's one
byte, then it goes to the next instruction, which is the same. It
functions by hardwiring the return from program memory to the no-op
instruction for that processor.

Signature analyzers take that pattern that (ought to) "is" at any pin
having to do with addressing, and counts up the pulses at that pin,
giving you a unique code. Since the hardware is in a fixed response
pattern, the signature is constant. Since the addresses are cycling
for all possible addresses (reading, that is), you're seeing the read
cycle of that switch repeated.

and yes, you're getting closer.

Modern microcontrollers have all of the ROM and RAM (frequently)
inside them, as well as the subsystems. With the exception of a few
specialized chips, most of the circuitry not doing unique to Tektronix
interfaces (except front panel and IEEE-488) interfaces are now inside
a single chip.

Much of this (as in the code used in the 468 scopes) actually verifies
the processor by making it do certain operations, then trapping the
processor in a dead end loop if that operation fails. By looking at
the processor address pins, you can identify which processor aspect
failed. Only after that would the external parts be tested.

With modern processors, most of these tests are not needed, since the
reliability is so high. Generally, it'll either work, or not, and
doesn't go to try to execute instructions with internal damage.

Not impossible, but simply not worth it for most designs.

Harvey

PS: Dave, Sorry about the re-editing. Necessary to correct some key typos. Now that I know this causes others problems, I'll try to get it right before posting!

RB

On Sat, 28 Jul 2018 19:57:48 -0400 (GMT-04:00), you wrote:

Rick, if I have a long message to post, I type it into something like Open Office Writer, or whatever word processing software you prefer. Once I'm happy with it, and have checked it for spelling errors, I copy and paste it into the new message. It helps me because of poor vision, because I can use a large font size while editing and the mistakes are easier to spot. I have nerve damage in one hand and Carpal Tunnel in the other hand so I find a lot of transposed character errors. This might help you, as well. I did some technical writing at my last job, and I didn't want to release any poorly written documents to the production floor. :)

I've also had the email program fail at times, and REALLY hate to
re-type long answers.

easier to cut and paste.

Harvey

Michael A. Terrell


-----Original Message-----

From: Rick Boswell <frboswell@...>
Sent: Jul 28, 2018 7:23 PM
To: [email protected]
Subject: Re: [TekScopes] 495P A54 Memory Board Troubleshooting: continued

Harvey,

After spending some additional time with the service manual. I see there is a way to cause the microcomputer to cycle through the full range of memory addresses on a repetitive basis. This is done by relocating a jumper on the processor board. Every time the options switch is addressed I should see the tri-state buffer enable line go low and the option switch setting appear on the output of the tri-state buffer/data bus (high for SW4 OPEN, low for SW4 CLOSED). This will repeat approximately every 154ms (if I am reading correctly), making verification much easier than if it is a one-time event with each power up. This should also isolate the problem to either the U3045 decoder or to the tri-state buffer. IOW, no enable to the buffer = decoder problem, incorrect option switch setting on the tri-state output = tri-state buffer problem. Getting closer! (I think!)

PS: Dave, Sorry about the re-editing. Necessary to correct some key typos. Now that I know this causes others problems, I'll try to get it right before posting!