• Please review our updated Terms and Rules here

Xircom Pocket Ethernet EEPROM unreadable error

J

jhhoward

Member
Joined
Sep 1, 2019
Messages
39
I am trying to connect my Sharp PC-3000 palmtop to my network using a Xircom PE3-10BC pocket ethernet adapter by connecting it to the computer's parallel port. I'm having a problem when I run the PE3TEST.EXE diagnostic program it displays the error "Adapter address EEPROM unreadable". This does show that the adapter is detected though, as there is a different error message if you run the program without an adapter present.

The adapter is connected via a wall plug and the status light glows green when there is an ethernet cable attached, and red when unplugged. So it doesn't appear that the adapter is entirely dead.

The only thing which is a bit odd in my setup: the Sharp PC-3000 has a proprietary miniature parallel port. The only cable I have for it has a Centronic 36-pin male port on the end that looks like this. I assume this cable was originally intended to be plugged straight into a printer or something. I bought an adapter that has a female Centronics connector on one side and a standard female DB-25 on the other. The label on it says 'RS232 CENTRONIC GENDER CHANGER'. Does anyone know if perhaps this could be causing a problem?

Unfortunately I have no other machines with a parallel port to test the Xircom adapter with. I see that you can buy USB to DB-25 cables, so maybe there is a way I can use one of those to test the adapter via DOSBOX? I also have no other parallel port peripherals to test if there is a problem with the Centronics connector. Anyone have any ideas for a cheap and easy way of testing a parallel port?

Any suggestions?
 
I've had this happen to me recently too. I have the Xircom on the shelf for a later repair.

The short story is that there is a serial EPROM on the board that has failed. It holds the MAC address, the manufacturing timestamp, and possibly some other data. It should have been readable for decades, but they are old enough now where bit-rot is setting in.

The part is soldered to the board, which is a pain. Modern equivalents are available, but they have larger capacities. I think it is possible to clone an existing adapter, but the part I don't have figured out is the desoldering and programming, which is why mine is waiting. It's not rocket science, but I'm far better with software than board level repair work.

Cloning is technically the wrong thing to do, but it will work. You can change the MAC address once you know the format, assuming that you also fix whatever checksum the used.


Mike
 
Well that's a bummer but not completely unexpected. Even if it were easy enough to replace the EEPROM I expect it will be quite a challenge to work out what the contents should be without cloning a working adapter. It does make me wonder if it could be possible to dump the EEPROM without physically removing it from the adapter.

It would be neat if someone were able to clone one of these adapters with modern parts as they are quite difficult to find these days. An ESP8266/ESP32 based adapter could even let you connect over Wifi. Are there any open source PE3 drivers? If the protocol is documented somewhere then potentially you could even use the same drivers.
 
I purchased one of these not too long ago, NIB/NOS. I haven't had a chance to test it yet. I hope I didn't spend money on something that is a dud. If it is still good, I'd be happy to extract the EEPROM contents if it can be done without the chip needing to be extracted, since that is beyond my current capabilities.
 
So after some research online I found this attempt to write a Linux driver for the PE3. It was done by reverse engineering the DOS packet driver.

Unfortunately it was never finished but it did get as far as reading the EEPROM contents. I had a quick look at the code and it would probably be possible to adapt it to just dump the EEPROM contents without needing to disassemble the adapter itself. This could be one way of cloning an EEPROM to fix a broken adapter. Alternatively it looks like it might be straightforward enough to generate new contents from scratch as the EEPROM is only 16 bytes. Here is the function that reads it:

Code: 
/*
 * Download the EEPROM contents from the PE3
 *
 *     returns zero if the checksum is OK, otherwise non-zero
 *     Note: this will only work on little endian machines
 */
 
int pe3_readeeprom(struct device *dev)
{
	unsigned char com[38] = { 0,0,2,0,4,4,6,4,5,7,5,5,7,5,4,6,4,4,6,
	                          4,4,6,4,5,7,5,5,7,5,5,7,5,5,7,5,4,6,4 };
	unsigned long time;
	int bit,check,junk,i,j;
	int eeprom[16] = { 0x00 };

	for (i=0;i<16;i++) {
		if (i/8==1) {
			com[23] = 4; com [24] = 6; com [25] = 4;
		} else {
			com[23] = 5; com [24] = 7; com [25] = 5;
		}
		if ((i%8)/4==1) {
			com[26] = 4; com [27] = 6; com [28] = 4;
		} else {
			com[26] = 5; com [27] = 7; com [28] = 5;
		}
		if ((i%4)/2==1) {
			com[29] = 4; com [30] = 6; com [31] = 4;
		} else {
			com[29] = 5; com [30] = 7; com [31] = 5;
		}
		if (i%2==1) {
			com[32] = 4; com [33] = 6; com [34] = 4;
		} else {
			com[32] = 5; com [33] = 7; com [34] = 5;
		}
		for (j=0;j<38;j++) {
			pe3_command(dev->base_addr, com[j], 0x04);
		}

		for (j=15;j>=0;j--) {
			w_dtr(dev->base_addr, 0x71);
			w_ctr(dev->base_addr, 0x0c);
			w_ctr(dev->base_addr, 0x04);

			if (pe3_mode==1) {
				w_ctr(dev->base_addr, 0x25);
				bit = r_dtr(dev->base_addr) & 0x01;
				w_ctr(dev->base_addr, 0x04);
			}
			else {
				w_ctr(dev->base_addr, 0x05);
				bit = (r_str(dev->base_addr) & 0x08)/8;
				w_ctr(dev->base_addr, 0x04);
				junk = r_str(dev->base_addr); /*What this for?*/
			}
			eeprom[i] = eeprom[i]+(bit<<j);

			pe3_command(dev->base_addr, 0x04, 0x04);
			pe3_command(dev->base_addr, 0x06, 0x04);
			pe3_command(dev->base_addr, 0x04, 0x04);
		}
	}

	dev->dev_addr[0] = eeprom[13]/256;
	dev->dev_addr[1] = eeprom[14]%256;
	dev->dev_addr[2] = eeprom[14]/256;
	dev->dev_addr[3] = eeprom[9]%256;
	dev->dev_addr[4] = eeprom[8]/256;
	dev->dev_addr[5] = eeprom[8]%256;
	
	time = (eeprom[11]/256)+(eeprom[11]%256)*256+
	       (eeprom[10]/256)*65536+(eeprom[10]%256)*16777216;

	printk("pe3: Manufactured on %02ld/%02ld/%4ld at %02ld:%02ld:%02ld\n",
	       (time>>23) & 0x1f, (time>>28) & 0x0f, 1990+((time>>17) & 0x3f),
	       (time>>12) & 0x1f, (time>> 6) & 0x3f, (time>> 0) & 0x3f);

	for (i=0,check=0;i<16;i++)
		check += eeprom[i];

	return (check & 0xffff);
}

It then occurred to me: is the EEPROM only used by the driver for the MAC address? If no other chips in the adapter read the EEPROM then it could be possible to patch the driver with a hard coded MAC address and to skip reading the EEPROM entirely. That way the adapter could still work without a working EEPROM chip and no hardware modifications needed.
 
Nice work! I need to recreate this - I just want a simple DOS program so that I can read the EEPROM from a good, known working device before it goes bad too.

And I think your idea about patching the driver is probably spot on. If you found where it reads the EEPROM and can figure out what it is doing with the contents, then there is no need to risk repairing the physical device. Just using a patched driver to simulate the reading of the EEPROM should be good enough. (Honestly, except for the MAC address I can't imagine what else would be interesting in it. It does have the manufacturing timestamp and probably a serial number, but those are not critical to sending and receiving packets.)

What tools did you use to examine the packet driver?


Mike
 
The code I posted is from the attempt at a Linux driver and isn't my work. It looks like it should be possible to makes some changes and compile with OpenWatcom to build a DOS program to do the EEPROM dump though.

I haven't looked at the packet driver in too much detail yet but Reko decompiler did a fairly good job at disassembling it. I don't have much experience with reverse engineering so any tips are welcome :)
 
jhhoward said:
The code I posted is from the attempt at a Linux driver and isn't my work. It looks like it should be possible to makes some changes and compile with OpenWatcom to build a DOS program to do the EEPROM dump though.
Click to expand...

It would be much better to post also the code for the pe3_command() function, that would help if one wants to re-use that code.

Frank
(I see there's a link at the original drivers, so there's no need actually to post the whole function here, sorry...)
 
Last edited:
I took the code from the Linux driver and adapted it to dump the EEPROM contents and compiled to a DOS .EXE using OpenWatcom. Source and binary attached. With my adapter the contents of the EEPROM appear to have all the bits set (0xFFFF for each word)

@Paralel you may also want to use the official diagnostic tool to test that your adapter is working correctly. It is included in the driver package here and called PE3TEST.EXE
 

Attachments

  • pe3tst.zip
    15.5 KB · Views: 2
I took apart the adapter to have a look inside. It is very easy to take apart - just slide the red rubber grip loop off the one side and then pry it open with a credit card. There are no screws, it just pops open.

A photo of the board is below. I had to crush the quality somewhat to be able to attach to the post but it is still readable. It is the PE3-10BC model which has both BNC and RJ45 connectors

pe3-circuitboard-reduced.jpg

Some of the notable chips on the board:
ST C06CM1 - EEPROM chip (datasheet) is just to the left of the main Xircom chip

PE-65745 - Lan isolation transformer (datasheet)

Xircom 2001773A / MB87328 - Xircom custom chip

Fil-Mag 91 SM - ???
 
iz8dwf said:
DC-DC converter, 12V out, isolated (as far as I remember, I haven't worked with old school boards in 20 years or so).
Click to expand...

I know you can power these using a PS/2 passthrough cable so perhaps this is for ensuring a clean 12V?

Looking at the EEPROM chip docs it is possible to write new data to the chip easily enough (assuming it isn't damaged). I'm sure there must be a way to actually do this by just writing a DOS program without any hardware modifications needed. The only problem is the Xircom interface is completely undocumented so there is no way to know how.

The EEPROM chip itself is really small so would be very tricky to remove from the board. Would it be possible to solder wires directly to the pins (whilst the chip is still on the board) and hook up to an Arduino to reprogram?

Alternatively if I could read the voltage of the pins it might help if trying to reverse engineer the Xircom protocol for accessing the EEPROM.

Any other ideas?
 
The coupling transformers and the DC/DC are part of the requirement for ethernet cables to be completely floating respect the host's electronic power rails. If you notice, also the BNC connectors were insulated with a plastic ring from the mounting hole/tab.
As for the EEPROM, you can either remove it and try to reprogram or substitute it, or you can try to reverse engineer the protocol. If you hook wires to the circuit, you end powering the whole board unless you at least disconnect the power pin on the EEPROM chip.
Programming the chip with the rest of the circuit also powered might or might not work, and you could also introduce new problems.

Frank
 
Has anyone dumped a working EEPROM's contents? I'd like to be able to alter the MAC address and flash new chips. It looks like there's many modern EEPROMs that are package and signal compatible and can be programmed with SPI.
 
Paralel said:
Sorry for not getting this done yet. I've been neck deep with a broken water main and 6" of standing water. I promise I will get to it soon.
Click to expand...
That sounds awful, sorry to hear it. Best of luck to you!

I also need to test programming these EEPROMs. These EEPROMs are Microwire which is a subset of SPI. I bought a cheap USB SPI programmer and will see if I can cajole it into working with these chips.
 
I don't have a working adapter to pull the EEPROM contents but based on the code from the attempted Linux driver I have created a small program to generate EEPROM values with a randomly assigned MAC address. I've attached the C++ source and a Windows .exe

It generates a random MAC address, a manufacturer time stamp based on the current time, and a checksum value which should pass the driver test.

One solution would be to use this generated EEPROM content to patch the DOS packet driver to use it instead of reading it from the hardware. It would take some reverse engineering of the driver but is theoretically possible.
 

Attachments

  • geneeprom.zip
    58.1 KB · Views: 3
You must log in or register to reply here.
Back
Top