Tektronix 2465A troubleshooting

[stfjohn]

Hi everyone. My Tek 2465A suddenly showed the following problem: at power up the message "TEST 04 fail 13 <017F> appears. I tried to replace the microprocessor, the ROM and also the RAM (also the battery), but nothing changes. By moving pin 501 to "CAL", and trying to calibrate the device, the procedure does not work: simply the device checks the various tests, reconfirming the FAIL to test No. 04! Can anyone help me please? Thanks.

[JKKDev]

By replace do you mean reseating the current components or actually installing a new/known good ones in?

Also, is after everything is done (the self check has finished) the TRIG'D LED illuminated?

[stfjohn]

Thanks for your replay.
Yes, new components. The only difference: I installed a D4464C-15 RAM, instead of the D4464C-20, but I do not think this is a problem.
No, the trig 'd led is not illuminated.

[stfjohn]

I correct myself: the trgi'd Led, after self check has finished, is illuminated!

[MarkL]

Did you try finding this error code in the service manual?

[Simon Spiers]

Before you get too involved make sure the rom battery is not dying!

[Testtech]

Power supply? Always the first thing to check!

[JKKDev]

I correct myself: the trgi'd Led, after self check has finished, is illuminated!

According to the service manual this indicates a Kernel error. Which other front panel lights are also illuminated?

[stfjohn]

Thanks everyone for your contributions.

Mark L: I could not find in the manual this error code!

SimonSpiers: the battery is new.

Tessttech: Power supply checked: all OK!

JKKDev: no other front panel light is illuminated.

[stfjohn]

In the past, sometimes the oscilloscope suddenly autoreset itself: it was enough to reset the various sets and everything was normal again. Lately this phenomenon was repeated more frequently. For this I had thought that the problem was in the RAM or in the battery .... But, even having replaced the above mentioned components, now reappears the error code, and there is no way to recalibrate the oscilloscope!

[MarkL]

...
Mark L: I could not find in the manual this error code!
...

I'm not sure where you're looking, but it's in there:

  https://www.tek.com/manual/2465a-and-2467-service-manual

Page 6-11.

You had some corrupted calibration data.  The calibration data is stored in the RAM and the RAM is kept powered by the battery.  The corruption could have been caused by whatever is causing the spurious resets, or maybe it was simply that the old battery was dead or dying.

But now that you've replaced the RAM and the battery, unless you took steps to back it up, the calibration data is gone and your scope will need to be recalibrated as per the procedure in section 5 of that manual.

You should at least check that the power supply is in spec, as Testtech mentions, if you intend to proceed any further.  Otherwise, if you complete the calibration, or have someone do it for you, you could lose the data again.

[stfjohn]

Dear Mark L,
The power supply is perfectly within the specifications! The problem is that there is no way to recalibrate the oscilloscope! Following the procedure, after having selected the test cal n. 1, as soon as I press the "upper coupling" button, the display shows "cal 01 pass" .... Of course I have moved pin 501 to "cal", but I get the same result as if I had left it on "no cal "! So I can't complete the calibration....

[stfjohn]

Basically the oscilloscope does not even allow me to start the calibration!

[MarkL]

Dear Mark L,
The power supply is perfectly within the specifications! The problem is that there is no way to recalibrate the oscilloscope! Following the procedure, after having selected the test cal n. 1, as soon as I press the "upper coupling" button, the display shows "cal 01 pass" .... Of course I have moved pin 501 to "cal", but I get the same result as if I had left it on "no cal "! So I can't complete the calibration....

Something doesn't sound right.  It shouldn't even display the cal menu choices if the cal jumper is in the NO CAL position.  A short video of what you're doing and the scope's response could be helpful.

You could try running CAL 05 as a simple test.  That just allows you set the run hours and power cycle count.

 

[stfjohn]

But it is just like that: either with the jumper in the "no cal" position, or with the jumper in the "cal" position, the result is the same: obviously something does not work! How do I insert a video? Forgive my ignorance about ....

[MarkL]

The "<017F>" in the error message indicates a cycle error, which can happen if the CAL/NO CAL jumper is removed and you boot the scope with an error.  It's also possible it's the result of random data in the RAM since you replaced both it and the battery.

I wouldn't expect a cycle error to affect the ability to run the calibration routine, but you could try clearing it.  You have to do this EXACTLY:

  Scroll to EXER 03 (CLEAR CYCLE ERROR) and press
  the following switches in sequence:

    TRIGGER COUPLING upper (starts exerciser),
    TRIGGER SOURCE lower,
    TRIGGER MODE lower, then
    TRIGGER COUPLING lower (exits the exerciser).

This is in the service manual, pg 6-18.

The "<017F>" should disappear.  Then try the CAL 01 routine.  Or try power cycling and then the CAL 01 routine.  On the next power cycle the "<017F>" should not return, but you'll still get a TEST 04 FAIL error because there's invalid calibration data in the RAM.

[stfjohn]

MARKL, Thanks again for your reply. I replaced the integrated "U2410" (Cmos 4512) and finally I managed to enter the calibration menu. I calibrated the instrument and ... now the message "TEST FAIL 04 02" appears! According to the service manual it should correspond to "out of limits bit 1 set". Mah!

[stfjohn]

Now the message "TEST FAIL 04  12" appears....

[MarkL]

The error should not just change by itself.  That's now a checksum error, indicating something in the calibration constants has been corrupted.

Given all this odd behavior, and the spurious resets you mentioned before, I think you might have a data bus or address bus problem.  This may be hard to track down.

You replaced U2410, which sits on the the data bus, and that changed the behavior.  But problems persist, so that chip was probably not the problem.  But what's interesting is that it changed the behavior enough to allow the CAL routines to run.  So this would tend to indicate the problem is on the data bus.

I think I would start by looking at the data bus signal levels on both sides of U2450/U2350.  They both straddle the internal and external data buses and each is responsible for one direction.

Using the processor "E" signal as a trigger, make sure the levels are good TTL signal levels (< 0.7V and > 2.1V, usually much > 2.1V), and always stable around the rising edge of E.

What equipment do you have for troubleshooting?

EDIT: Fix typo.

[stfjohn]

Markl,
I followed your advice: here are two images (trigger on "E" microprocessor): input (pin 4 U2450) and output (pin 5 U2450): in both cases the TTL signal is not stable ... All inputs and all the outputs are similar; also with regard to the U2350.

[MarkL]

I'm sorry, I made a mistake.  The critical edge for E is the *falling* edge.

However, even triggering on the wrong edge, there's some strange looking results in your screen shots, so I thought I'd better set this up and try it myself before you invest too much time with this approach.

The idea was to try to find anything that's not satisfying setup/hold times, or two outputs fighting each other which would result in an undefined TTL level.

The two data buses are Dx and BDx, respectively for the processor and external bus (B probably meaning buffered).  U2350 drives BDx-->Dx for bus reads, and U2450 drives Dx-->BDx for bus writes.

In order to verify signal levels, it would be more proper to trigger when actual reads and writes are occuring.  Such a trigger would use the enable signal low on the driver (U2350 or U2450), the processor VMA high (Valid Memory Access), and that pattern clocked by the falling edge of E.  In short, the trigger definition would be:

  nEN = 0  (probe U2350 or U2450)
  VMA = 1
  E = falling edge

By using the nEN signal on U2350 you can look at bus reads, and nEN on U2450 for writes.  If you go through again and look at both Dx and BDx (x=[0..7]), you should get results similar the screen shots below.  (These are from a 2445A, which is the same as far as the processor section is concerned).

The signal should always be stable on the falling edge of E, except when looking at BDx on bus reads.  This is because Tek is reading from peripherals that are either not installed in the system, or the chip being addressed is not driving all the pins of BDx, leaving those signals to float to any level.


These types of problems are sometimes really hard to track down.  The above may not show you anything of interest.  It's only a guess as to where to start.

If you can find something that fails consistently, it could help.  The scope has a number of automated tests that can be put in a loop.  You already know that TEST 04 fails, but you could try the other tests, and perhaps let some of them loop for a while.

Some other ideas:

If you push A/B to put the scope back into operation after the TEST 04 FAIL, can you find anything that doesn't work or has a weird behavior?

If you put the CAL/NO CAL jumper in the NO CAL position, does it still show you the CAL routines in DIAG mode?

If you look at the cal data with EXER 02, do you see a lot of parity errors (indicated by an "X") in locations 01 to 6E?  Is there any noticeable pattern to the data being displayed?  Like runs of 55 or AA?

[MarkL]

Ok, here's another thing.

Unfortunately, another mistake from me (bad day, I guess).  I said:

...
You replaced U2410, which sits on the the data bus, and that changed the behavior.
...

That is not true.  I was looking at the wrong chip.

You reported that replacing U2410 changed the cal menu behavior.  U2410 reads the CAL/NO CAL jumper, the front panel scan status, and ('m guessing) the scope type 2445A vs. 2465A.  It's controlled by U2301 and its results are gated onto the bus by U2220.  There isn't much else involved, so why did a new one change the behavior of the cal menu?

Both U2301 and U2220 sit on the data bus.  I'm wondering now about their health.  Maybe take a really close look at their operation, including power and GND pins.

The front panel exerciser, EXER 01, might be worth verifying that everything works as expected.

I have to preface this with I don't think shotgun is a good troubleshooting approach, but since you don't seem to mind replacing chips, you could try U2301 and U2220, unless there's a better explanation of why a new U2410 changed the cal menu.

EDIT: Fixed typo.

[stfjohn]

Here an image very similar to your photos...
But, as in the previous photos, the signal is well squared on the inputs, and quite dirty on the outputs. In A/B Menu everything works well, except the annoying presence of numerous question marks on the bottom readout.
EXER 02 shows several parity errors: 80FF00  X; AOFF00  X; BOFF00  X; COFF00  X; FOFF00  X .
Another strangeness: I put the integrated I had replaced (U2410) (obviously I had installed a socket) and (unbelievable!) everything works like the new one! I do not understand anything any more...!

[MarkL]

Here an image very similar to your photos...
But, as in the previous photos, the signal is well squared on the inputs, and quite dirty on the outputs. In A/B Menu everything works well, except the annoying presence of numerous question marks on the bottom readout.

Those are just saying that the calibration data is bad.

EXER 02 shows several parity errors: 80FF00  X; AOFF00  X; BOFF00  X; COFF00  X; FOFF00  X .

That's only 5 locations.  There are 256 locations.

What about the other locations I mentioned 01 to 6E?  01 to 6E are the only ones where the scope stores a valid parity bit.

Another strangeness: I put the integrated I had replaced (U2410) (obviously I had installed a socket) and (unbelievable!) everything works like the new one! I do not understand anything any more...!

Are the calibration menu entries still showing up with the jumper the NO CAL position?

Does this scope have any options installed?

You really need to find a symptom, any symptom, that you can reproduce easily.


I'm not saying it's impossible to find the problem on this board, but this is all sufficiently strange that you might want to weigh your time against getting a new A5 controller board, part # 670-9052-00.  There are several on ebay from a seller in Greece for USD$75, and with "Make an Offer", so you can probably get it for less.

[stfjohn]

Thanks again MARKL.
The locations 01 to 6E do not show parity errors. The parity errors start from the location 6F (00FF  X) and are very many.
CAL and NO CAL positions now work perfectly.
The scope have CT and DMM options.
I think I'll buy the A5 card as you suggested, even if I would have liked to understand where the problem was related to the existing one ....