Hi Harvey:

I do not know what kind of processor just yet. I thought I got an abbreviated copy of the service manual without schematics. I am now looking at another service manual that also has no schematic. There is a block diagram in the service manual of the A9 CPU Board which shows the EEPROM coupled directly to the processor, but I doubt this is true, and is over simplified.?

I put out post to see if I can find a schematic so I can start tracking down these suspect lines.?

Rich

On Feb 12, 2022, at 10:16 PM, Harvey White <madyn@...> wrote:

?

OE is generally derived from the processor's read/write outputs (what kind of processor is it? 68xxxx series).? IIRC, it's likely a read/write level combined with a "valid memory address (i.e now do something).? The EEPROM likely needs a CS, which is derived generally from a combination of the address lines.? The combination of the CS and OE lines allow the EEPROM to put data on the DQn lines.? WE is likely derived from the same process as the OE, but enabled only when a "write permission" line (likely) is enabled.? This allows the processor to enable or disable writing to the EEPROM with a lockout/permission bit.

Intel style processors have no read/write level, but separate read and write strobes.

Apologies if you knew this already, it's just general information.

The main point is that the EEPROM does *not* generate the OE, CS, and WE strobes, external circuitry does.? Faulty chips can drag that down, though.? Very unlikely that the WE goes anywhere else than the EEPROM (and source).? OE is likely going everywhere and you'd know if it were bad.? CS, once derived, likely goes only to that chip unless it has its own buffer to the data lines.

Harvey

On 2/12/2022 9:09 PM, Rich Miller via groups.io wrote:

This I do not know yet. I was able to trace OE to another chip (U402). CE and WE go off to another section of the PCB. Need pull down a schematic and have a closer look. The service manual I downloaded did not have a schematic, but I am sure there are some out there.

Rich

On Feb 12, 2022, at 8:58 PM, Harvey White <madyn@...> wrote:

?

Looks like the idea of trying to read it, then putting a new one in is a good thought, however, what's driving the WE?? Is there a lockout we don't know of?

You may have a fragile EEPROM, but the driver for the pins may be bad as well.

Harvey

On 2/12/2022 8:34 PM, Rich Miller via groups.io wrote:

Hi Harvey:

Well the results are not good:

STANDBY:

CE = 4V - Should be between 4.5 - 5.5V

OE= Cycles between 0 - 4.5V (Like there is data on this pin)

WE= 5V

WRITE: Tested when attempting to write Random Characters in Test 56

CE= Same As Above

OE= Same As Above

WE= Same As Above

The above does not match the table found in the data sheet. CE & OE should not be pegged to anything near Vcc attempting to write to it or in standby. This would certainly explain my ability to write to the EEPROM.?

Rich

On Feb 12, 2022, at 4:32 PM, Harvey White <madyn@...> wrote:

?

Ok, you could perhaps use some #30 wire wrap wire as a probe on the socket itself

The 0.025 square ww style/breadboard pins are way too big.?

Harvey

On 2/12/2022 4:18 PM, Rich Miller via groups.io wrote:

Yes, I have the tools, but need to dig in and see if there is an alternate point to attach to those lines. I have some pins that I use with my Logic Analyzer, but they are too thick to insert into the PLCC Socket Probing Point. I think my probing wire/pins were designed more for breadboards. I was trying to utilize those, and quickly realized that was not going to work well, or safely, so I stopped.?

I was hoping maybe I could find another IC as a driver/buffer, and use my mini grabbers to have a look. That would be a much more secure method. I am going to spend sometime looking over the A9 Board Schematic to see what this tells me about how the EEPROM is connected. ?

On Feb 12, 2022, at 3:30 PM, Harvey White <madyn@...> wrote:

?

Ah, depends on what the DMM does with pulses (if any).

you don't need a logic analyzer except to perhaps trigger the scope.? I'd look at that line and the one it was shorted to, and better yet, the CS and RD (or WR) lines at the same time.? It doesn't matter so much what the LA says is a 1 or 0, it matters what the chip thinks.

You've got the tools, then.? Don't have to worry so much about a workaround.

Harvey

On 2/12/2022 3:25 PM, Rich Miller via groups.io wrote:

I was simply probing the pin with a ProbeMaster fine point probe connected to my DMM. I do have a Logic Analyzer in my MDO3102, but I would have to see where the data line is coming from. I would be surprised if it were unbuffered, but you never know.

Rich

On Feb 12, 2022, at 2:07 PM, Harvey White <madyn@...> wrote:

?

Digital oscilloscope, storage oscilloscope, peak reading voltmeter, regular oscilloscope in a dim room.?

You're measuring the voltages (right now) as static voltages?? That may not be helpful.

PLCC chips are rare, and professionally (non Chinese), the reader plugins may be a bit nasty in price.

Adaptors can be made if you have the right socket.? Sockets may not be hard to come by.? There's a company that makes PC boards for adapting various types of chips, they may have something that could help.? (Don't remember the name).

Logic analyzer *could* help a bit.

If you can isolate the driver for the chip by unplugging things, then you can manually drive the data driver to the chip.? Since it's a data line by nomenclature (DQx), it may be either the processor unbuffered, or this might be the processor buffered.? If the buffer lines run to other chips, then if they work, the driver is likely good.? Shorts on the data lines may not be fatal.? Looking at this with a scope, especially if in a repetitive loop, could be very helpful, if you can generate that.

If the equipment has a provision for signature analysis, then that puts the processor in a cyclical read of all addresses, which should force a read of the EEPROM's address space, which you can trigger a scope on, and get an idea.

So possibly options.....

Harvey

On 2/12/2022 1:07 PM, Rich Miller via groups.io wrote:

Hi Harvey:

I have no way to check the voltages while writing to it (at least not reasonably). I think its time to invest in a EEPROM writer/reader for PLCC.

Rich

On Feb 12, 2022, at 12:49 PM, Harvey White <madyn@...> wrote:

?

If you can remove the eeprom, and then check the voltages when writing, that might tell you if the driver for DQ6 is damaged.? If you could read the EEPROM in another setting (PLCC adaptors are rare), then that would tell you if the chip were good.

Harvey

On 2/12/2022 12:44 PM, Rich Miller via groups.io wrote:

Hello All:

Today, I took another look at the issue, and made an interesting discovery. The AM29F010-70JC EEPROM Pin 20 (DQ6 line) was damaged while installing the PLCC package into the socket. I straightened it out, and reinserted it. It is now making contact, but I am not sure if the pin moved over to the adjacent Pin 19 (DQ5). Right now, when I measure the voltage at Pin 20 its at 2.5V, and when I attempt to write the bit to invoke the options it drops to about 1.75V. I am still getting the Failure when attempting to load the options.

So its clear someone has been in here before. I now worry that I might not be able to recover anything from it. I certainly do not think it can be written to any longer. Would anyone by chance have a replacement RevD??

Rich

On Feb 12, 2022, at 5:53 AM, Harke Smits via groups.io <yrrah@...> wrote:

? Rich,

There is nothing wrong with just reading the contents of the EEPROM. Then store the original safely and program another one for a test. I’ve done that a couple of time for spectrum analyers. Works great, can do no harm.?

Good luck,

Harke

(Send from my iPad4)

Op 12 feb. 2022 om 10:41 heeft Rich Miller via groups.io <av8torrich@...> het volgende geschreven:

? Leon:

That is good information. In a little while, I am going to test my S400 Jumper to make sure when I toggle #8 on the dip switch, I am getting continuity.?

The idea of having to pull the EEPROM and write to it does not sit well with me. I worry I may render the analyzer inoperative if I accidentally corrupt the files held within it. Anything I can do to avoid I will try.

Rich

On Feb 12, 2022, at 4:10 AM, LeonP <leon.pavlovic@...> wrote:

?Hi Rich,

I've done an option upgrade 14 days ago on my 8753D (with the CPU 000 board, which is probably also in your VNA). I've got the same error, because I did not flip the jumper (there is no A9 dip swich on the CPU 000 board, but is the S400 instead). After I've correctly flipped the S400 #8 switch, the option upgrade went flawlessly.
Greetings,
Leon