Repair of HP 8753A with ROM 1L Fail fault

I have just repaired an HP 8753A vector network analyzer which was reporting ROM 1L Fail at power up. As more equipment which is otherwise perfectly good is failing because of eprom corruption, I thought it might be of interest to know that such faults can sometimes be corrected.

I tried the usual things first - re-seating all the socketed devices on the processor board and checking under a binocular microscope for defective solder joints.

This instrument is no longer supported by Hewlett Packard / Agilent, so the options were either to find somebody with a set of eproms which I could copy or to try and fix the ones I had. The first option proved difficult, so I tried the second.

Unfortunately, all the sticky labels had fallen off the 6 eproms, so it was not easy to determine which one was faulty. The most likely cause of the problem was a leaky storage cell, so I hoped that it might be possible to find the faulty location and correct it.

The first problem was to identify the eprom type, as the markings were HP specific, not AMD's standard part numbers. By probing the processor board to determine which pins were connected to an 8-bit bus and which to a 16-bit bus it was possible to work out the number of address pins and hence the size of the devices. They appeared to be Am27512. I checked the markings against photographs at

and found that one of them had a code which corresponded to an AMD

27512 - 250ns. I placed one in an eprom programmer which was able to read the id code from the eprom and this confirmed that they were indeed Am27512.

I then tried reading the contents at 5.0V and re-reading the contents at progressively lower supply voltages. (A quick Google search finds several reports on forensic examination of eproms where it has been possible to recover data from supposedly erased memories by lowering the supply voltage to change the thresholds of the sense amplifiers.) I used a Dataman 48LV which allows arbitrary setting of device supply voltages, together with appropriate level translation of the i/o signals.

I found that for 5 of the 6 eproms, the contents were unchanged from

5.5V to between 3.1 and 3.9V. Once the contents had started to change, a 100mV additional drop in voltage caused many additional errors. One eprom (U24) behaved quite differently. The contents remained constant down to 4.4V, then one location changed from 0xBB to 0xBA. It was then possible to drop down to 3.9V before the next location changed and 3.8V before a third location changed. At 3.7V there were 19 errors.

I saved the memory contents at each of 5.0V, 4.2V and 3.9V. As a first try I programmed a new eprom (a 27C512-150CD was the closest I could get from Farnell) with the data extracted at 4.2V and re-assembled the analyser. It worked!

I can't be totally sure that the fault is corrected, as changing a different bit might have generated the same checksum. If HP used a CRC check rather than a checksum this would be highly unlikely, but I don't know how they verify the code integrity.

I have saved Intel hex files for all six eproms, so if anyone else needs this code I can make it available. It is revision 1.0 firmware. If anyone has their own copy, it would be useful to compare theirs and mine as a better way of confirming the code integrity.

If anyone has revision 1.1 (the latest as far as I know) I would also be very interested in a copy.

John Walliker