Changes between Initial Version and Version 1 of EPROxygen

Timestamp:

Jul 12, 2012, 9:31:54 PM (12 years ago)

Author:

pulkomandy

Comment:

--

EPROxygen

@@ +1 @@
+= EPROxygen : using SEEIT EPR-02 under UNIX =
+
+So, I have this ROM programmer and dumper I bought some time ago. It's a parallel port based one and the software is for MS-Dos.
+I've had some problems with that software, failing to write some bits from time to time (another programmer worked fine with same file and same ROM). Moreover, I wanted to program an AT29C040A flash memory and noticed that didn't work. I mailed SEEIT support to ask for an updated software, but they told me the product was deprecated, and I needed to buy a newer, more expansive replacement, requiring Windows and an USB port.
+
+Well, I'm not willing to spend that much money on a programmer Iwon't use often enough. So I decided to spend some time instead and write a driver for the one I have.
+
+== The hardware ==
+
+[[Image(http://membres.multimania.fr/webmasterbhe/24301-opt.jpg)]]
+
+I started by having a closer look at the programmer hardware. It has a DB25 connector, some 74HCTxx chips, some transistors and some less familiar (for me) components on the power supply area. The power supply comes from a 12V power adapter.
+
+So, let's see how that works.
+
+The bulk of the logic is made of 74HCT574 8-bit registers. There are 5 of these, and most of the outputs are connected directly to some ROM pins.
+
+||=Address=||=Name=||=Description=||D0||D1||D2||D3||D4||D5||D6||D7||
+||4        ||LH    ||Select low or high data nibble for reading||||||||||||||||||(no use for the data)
+||5        ||Control||Various control bits for the ROM||A16||/A17||/WE||A18||/OE||VPP25||VPP24||/CE||
+||6        ||Voltage||Controlling the VPP voltage||VPP1||VPP3||VCC32||DOE||VConA||VConB||AOE||VconC||
+||7        ||Nothing||Free address||||||||||||||||||||
+||C        ||Nothing||Free address||||||||||||||||||||
+||D        ||A0     ||Low address byte||||||||||||||||A0 to A7||
+||E        ||Data   ||Data byte (write only)||||||||||||||||D0 to D7||
+||F        ||A1     ||High address byte||||||||||||||||A8 to A15||
+
+ * VPP24 powers on the transistor that puts VPP voltage on pin 24
+ * VCC1 powers pin 1 with VCC
+ * AOE enables the output from both address registers
+ * DOE enables the output from the data register. This also lights the green led (the red one is always on when the power supply is plugged).
+ * VCon bits adjust the VPP voltage
+
+The data bits are wired directly to the parallel port ones.
+The register selection is done with the control port of the parallel port. The 4 bits are wired to a 74HC138, so that :
+ * When C2 is high, the output is enabled (some register is selected). Else, no register is selected.
+ * C0, C1 and C3 make the address of the register to select.
+
+Reading is performed by a 74HC157. This gets either the low or high 4 bits of the ROM data and put them on the status bits of the parallel port (there are only 5 status bits so all 8 could not be read at the same time). The LH output from the 74HC138 selects the nibble that gets through.
+
+I have not completely understood the power supply. It seems to revolve around a step-up regulator, with the reference voltage made from some registers wired to the VCon bits in the Volt register. This allows these bits to change the reference voltage, so the regulator can generate 12V, 24V, or something in between (not yet checked). Two separate 5v linera regulators are also used, one of them is always on and provides power for the logic, the other one is enabled through VConC bit. This one powers the ROM being worked on.
+
+You will notice that it is possible to leave both data and address bus floating and power off, with all the control signal low. This is what the programmer does before asking to insert a ROM into the socket (which has to be done after power up, as the reset condition is a bit random).
+
+=== Some hardware fixes ===
+
+It is well known that the parallel port is not very good fir interfacing. The voltage is a bit random. On this programmer they use pull up resistors on it. I unplugged those, because 74HCTxx logic requires only 2v to detect a high level, and low level needs to be below 0.8. I measuerd about 1.2v low and 3.3v high on my computer parallel port, so the low level was still too high. I'm not sure that's ok, need to look closer with an oscilloscope to see if the data isn't too jammed because of the floating pins and slow rising time.
+
+Another thing I noticed is the ROM power supply is slightly above 6v when it should be around 5. The linear regulator is ok, but to protect it they made the 5V output go through an 1N4004 diode. This creates a voltage drop that is compensated by a resistor between the regulator "ground" pin and the actual ground, offsetting the regulator output a variable amount depending on the intensity. I simply replaced the resistor by a weaker one to decrease the voltage to something more safe for my AT29C040. The output is now about 4.5V.
+
+== The software ==
+
+Ok, now on to the fun part, writing software to drive it !
+
+I used C++, because I need fast hardware access (the AT29C040 needs timings in the microsecond range) and I still wanted some object features.
+It's easy to plug in support for other ROM/Flash types.
+
+For now the code is written for FreeBSD. I try to keep it standard POSIX but the hardware access macros are platform specific. It should be easy enough to make a linux version anyway. You obviously need a PC compatible parallel port at 0x378 I/O address (you can change this address with a command line switch).
+
+I started the AT29C040A programming algorithm with the code to read the chip ID, but I didn't get that working (I always read FF). I then tried an easier target, reading an already programmed 27C022 I had around. This one has no fancy algorithm, just put the address on the pins and read the data. It seems to work fine, but I had to add some agressive timings. I'm now looking for where the problem is with the fast code as that's required for writing the AT29 chip : it has a timeout of 150µs when waiting for bytes in a block. If a longer delay happens between two bytes, the chip decides the block is ended and start writing it back to flash.
+
+I don't have much success with these AT29C040A chips, another project using them already failed. I also have some SST 39SF040, which are a bit similar and might work better. But these come in a PLCC package so I have to build an adapter board...