I have a big and awkward project to do, and that's pull the data from some EECVs
The main project is the retrieve and save the multiple different versions, and see what can be done about programming.
Moates has just stopped making the QH which would have been ideal for at least extracting the data, if anyone has one they are getting rid of, I'd be interested.
There was the SonOfSucka about, I've managed to find the schematics of the original EECSucka, but it looks like there were some extra bits added for EECV, I'm guessing to do with bank switching.
If anyone has the zip of the SonOfSucka on a hard drive, I'd be interested in looking at that.
I have pulled some info from the internet archive/wayback machine and some of that does look pretty useful.
If that fails, I might have a crack at an Arduino based reader/ROM dumper.
I'll post some info below to keep any archive of it alive.
Another project might be to figure out how to reprogram the N70005FWCHCA chip you'll often see inside of them. I have seen legends of a Ford eeprom programmer, one did exist at some point but now lost to the sands of time.
The EECV knows how to flash it, so it can be done, just need to figure out a way. No datasheets seem to be available for it, but I'm guessing a logic analyser on it should be able to figure out what is done.
There was also some older info around on a homebrew J3 adapter, with the PLD code, that could be useful to make some sort of open source J3 adapter with more modern parts. Currently it seems like the Xilinx PLD is becoming obsolete, but there should be plenty of others around that can take its place.
So- what I have gathered about the N70005FWCHCA so far, it's a custom Intel chip, double latched.
Most flash memories, certainly the old stuff would have 16 address pins which would put in the address in binary/parallel so each pin for be a high or low for a 1 or a 0. These tend to be 16 bit wide, so it can ask specifically for any of the 65535 possible addresses. If it were 8 bits wide, it could also ask for 255.
Once the chip gets the address, it will output the data at that address on another 8 data pins to give the 8bit value. You can obviously have 16bit/32bit etc now as well, but on these ones, there were 8bit.
Why the N70005FWCHCA chip was odd, is it only had the 8 data lines connected, and these do turn up at the J3 port. The trick is it would send a signal to the chip saying address coming in, and send two bytes of the address (8 bits) down the data lines instead, then the next two bits, and then finally read the 8 bit data out of those lines.
So instead of 16 in and 8 out, it would put half the address in, then the next half, then switch to an output for the data.
The J3 adapters and the PLD (programable logic device) would be able to plug into the J3, disable the on-board chip, and the PLD would be able to understand these latching inputs, and fetch the data out of another flash memory chip, and feed it back into the EEC.
Some saved info on the details from Andrew March's page from 20 years ago
Son of EECSucka (EEC-V)
This version dumps the entire ROM by taking full control of the MBUS including the BS0 and BS3 bank select pins. The software is capable of dumping the full 224kB in a four-bank EEC-V.
Here is a step by step description of the dumping process:
0. PAUSE and RST are tied to ground permanently and power is applied.
1. Start with MRST high, DI high, IT high, ST high and MB0-7 from the dumper in tri-state
2. Set BS0 and BS3 to either 01, 10, 00 or 11 to select required bank
3. Bring MRST low
4. Bring DI low to give control of MB0-7 to the dumper
5. Place byte 0x00 onto MB0-7
6. Generate low pulse on ST and return it high
7. Place byte 0x00 onto MB0-7 (ie no change from steps 5 and 6)
8. Generate low pulse on ST and return it high
9. Place byte 0x20 onto MB0-7
10. Generate low pulse on ST and return it high
At this point the Slave Program Counter inside the ROM is loaded with address 0x2000 of the selected bank. This is the first location of the program memory in each bank. Note: at the moment I am not entirely sure why loading a 16-bit address counter requires ST to be pulsed three times. Perhaps the first ST pulse causes BS0/BS3 to be latched.
11. Bring DI high to give control of MB0-7 to the ROM
At this point the EEC is driving out the byte at address 0x2000 of the selected bank
12. Bring MRST high
To get the next byte at address 0x2001 simply increment the SPC address counter in the ROM by pulsing ST low again. Keep pulsing ST to get subsequent bytes until the whole 56kB from 0x2000 to 0xFFFF in the current bank has been retrieved.
To get the contents of the next bank, simply repeat the numbered procedure above from step 1 using a different bank selection code.
The hardware design of the dumper is a little bit sneaky. Notice that initialising the Slave Program Counter involves writing either the value 0x00 or 0x20 on to the MBUS at various times. In other words, the dumper only has to control just one bit (MB5) to generate these two values. This is achieved by a single latch output that sets the value of MB5 via a 10K resistor while the remaining bits (MB0-4, 6, 7) are held at logic zero by pulling them down through 10K resistors.
Here is a distribution kit for Son of EECSucka containing schematic and software including source code.
The hardware design is based on a manual modification of the original EECSucka PCB above. Differences can be determined by comparing the schematic drawings supplied in each of the distribution kits.
The EEC-V version seems to add an extra step for bank selection, which luckily is noted down, but it is ancient, and needs an old PC with a parallel port.
You might be wondering why I don't just read stuff through the OBD port like a normal person, technically it should be possible, but I've no info as yet on the datastreams to read/write these ECUs, and here's the kicker, why I can't just buy a lead and read it-