Z80 core module conundrums (Fluke 5440A repair)

[Rax]

Hi all,
I'm neck deep into a 5440A repair that's very reluctant to start working. There's reasons to believe the cause of the issues reside on module A2 (Front Panel Control). It's what seems to be a Z80 CPU headed 6402-based UART interface to the main controller design.

I've been investigating around the UART and the CPU to no avail. Some of the things I've found are below (more of a data dump, I'm not entirely sure where to head from here). Also, note the A2 schematic enclosed below, which is not widely available, but I'm putting it here as I'm asking for help.

I am looking at this under the following circumstances:

• A16 is pulled to allow A2 to try things out undisturbed
• I've replaced the Z80, IM6402, the RAMs (TMS4016-20NL), and recapped the board. Not a fan of scattershot troubleshooting, but some things being on sockets, why not eliminate some of the possibilities?
• The troubleshooting switches on A2 during the captures below are 0100

Some observations:

• U16/pin16 seems stuck low (goes high for one pulse, then seems to stay low permanently).
• forcing reset of the CPU by shorting C38 (actually, grounding U3/pin1) doesn't lift U16/pin16 high

I also enclose a read of A0 through A15 on the CPU upon starting the unit. Most images following in a second post.
What could cause the issues I'm seeing with A2, and what else should I be looking into?

[Rax]

Scope and LA captures and data points.

[Andy Watson]

Have you checked the EPROMS? It would only take one bit to rot to throw the program.

[nigelwright7557]

Or a RAM problem.

[Rax]

Or a RAM problem.

I swapped brand new RAM chips this morning and no change.

[Rax]

Have you checked the EPROMS? It would only take one bit to rot to throw the program.

I have not yet, but I do have five NOS chips just received and binary images and if I get some time tonight my plan is to image those and swap them in. This way I'd have the old set untouched and have run this scenario to isolate the issue.

[Rax]

Along those lines - checking the EPROMs - what are the options to check them?

For instance, I have a XGecu T48 programmer. I also have binary images of each individual ones. Are these programmers able to compare a given existing chip from my unit with its corresponding image?

And another question for the ones with experience with these UV-erase EPROMs - is it easy (or even possible) to erase them using the programmers in some unintended way?

[Rax]

Well, as soon as I post this here, of course, after many weeks or painstaking examination of different things (with the help of invaluable and very competent friends!), and of honing into a bunch of suspect possible culprits (including the EPROMs), here it is... conclusion of a consuming saga!

It seems the U23/704114 EPROM was corrupt. Once I reimaged it with the binary I got from Megavolt (huge thanks!!!!), it's back online and I seem to be getting full operation as far as I could investigate this far.

[dietert1]

An EPROMs fails all by itself when the charge representing a 0 bit diminishes.  You can accelerate that using UV light into the window. Then all 0 bits get erased after 5 or 10 minutes and the part can be programmed again.
EPROMs are meant to last 10 years or so. At moderate temperatures they last much longer yet not forever. How old is that calibrator?

Regards, Dieter

[Rax]

How old is that calibrator?

I think early '80s. Maybe 1984, going by the SM. I think it must have been pretty quickly replaced by the 5440B/5442. I don't know many people that have the 5440A, but I think it's for all intents and purposes the exact equivalent of the 5440B, except the displays and the Front Panel Controller driving them.

In my limited experience with it this far, an extremely stable standard. I've seen it generate very long 10.0000000V on my Prema 6048, sometimes exactly that during three successive 20s integrations. Never more than 15 counts off, if left undisturbed, and most of the time within the last count.