Image Map Image Map
Page 1 of 3 123 LastLast
Results 1 to 10 of 25

Thread: Xircom Pocket Ethernet EEPROM unreadable error

  1. #1

    Default Xircom Pocket Ethernet EEPROM unreadable error

    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?

  2. #2

    Default

    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

  3. #3

    Default

    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.

  4. #4
    Join Date
    Mar 2013
    Location
    SW Quadrant of Michigan
    Posts
    284

    Default

    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.

  5. #5

    Default

    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.

  6. #6

    Default

    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

  7. #7

    Default

    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

  8. #8
    Join Date
    Mar 2013
    Location
    SW Quadrant of Michigan
    Posts
    284

    Default

    If you guys can come up with a tool, I'd be happy to run it and dump my EEPROM, assuming it hasn't rotted away sitting in the box.

  9. #9

    Default

    Quote Originally Posted by jhhoward View Post
    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.
    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 by iz8dwf; July 27th, 2020 at 04:55 AM.

  10. #10

    Default

    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
    Attached Files Attached Files

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •