[TheEnd]

Hi guys,

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-

[jsa]

Hi guys,

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.

BURN2 and an adapter can read EEC-V.There was still some around the web last week.

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.

Sounds familiar. I think I have it archived away somewhere. Should be able to dig it out and post it.

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.

Drewtech Mongoose can flash the over ODBII.

So- what I have gathered about the N70005FWCHCA so far, it's a custom Intel chip, double latched.

Read the manuals from here;
https://github.com/OpenEEC-Project/Useful-Docs

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-

Mongoose comes to mind again, not sure why you want to understand the data stream when it takes care of it.

Aston Martin V12...one EEC per bank aren't they?

[TheEnd]

I'll need to contact Drewtech and see what they say, what I'd be concerned with is seed keys, it's fairly frequent that manufacturers might be using the same stuff, but just change the locks so to speak.

I've got the original EEC Sucka schematics, and some info above on the SonofSucka.
Ender11 has done a lot into making a more modern version, I've been looking through Russian forums and got some info there.
The March Sucka was set up for a uni-directional LPT port, and had a multiplexer on the data lines, which shouldn't always be needed, it seems the more modern LPT ports are a little easier to work with.

His source code is there, so with a bit of unpicking, I might be able to dust off my old arduino knowledge, and be able to make something that plugs into USB on anything modern.
I have bumped into a reddit post that seems to confirm on board chip programming is possible, but 18v for flash erasing was often the sticking point, and since OBD flashing was possible, there wasn't much of a need to go further.

The V12s do have two ECUs, and they do often get wet too, and spares are hard to come by. It's even worse for the earlier V12 Vanquish, which has a PowerPC PCM150 type wedge inside of it which just aren't available yet. A lot of the parts used on them were Ford or Jaguar based around that time, and the supply chain isn't what it used to be so "just get a new one" isn't always an available option.

[jsa]

I've got the original EEC Sucka schematics, and some info above on the SonofSucka.

I've loaded all I have on the EEC-IV and EEC-V EECSucka too github;
https://github.com/OpenEEC-Project/EECSucka-Archive

Looks as though Andrew March and others were going the CPLD route before Moates products became available.

Ender11 has done a lot into making a more modern version, I've been looking through Russian forums and got some info there.

Have you got links to that?

I have bumped into a reddit post that seems to confirm on board chip programming is possible, but 18v for flash erasing was often the sticking point, and since OBD flashing was possible, there wasn't much of a need to go further.

Yes, for later EEC's using EEPROMS. I don't think the UVPROMS could be written in circuit, but don't know for sure.

The V12s do have two ECUs, and they do often get wet too, and spares are hard to come by.

Looks fairly typical of EEC-V's in general. Your pic is not clear enough to see the hardware code. If the hardware is common too another application that is more plentiful, it can be reprogrammed to AST1.

It's even worse for the earlier V12 Vanquish, which has a PowerPC PCM150 type wedge inside of it which just aren't available yet. A lot of the parts used on them were Ford or Jaguar based around that time,

Yep Ford owned them for a while.

and the supply chain isn't what it used to be so "just get a new one" isn't always an available option.

Very true. Ford's EsCos MAP sensor is also used on turbo Rolls Royce of the same era. Ford have no stock, but Rolls can supply one at a Rolls price LOL.

[TheEnd]

It's here-

https://eectuning.org/forums/viewtopic. ... 98#p129998

The schematics are there, it's direct parallel to the J3, so no need for the 74HC stuff, a multiplexer and a latch.
The code in C is in that post, which would make a good starting point.

Next up I need to go through the arduino programming stuff again and re-learn what I've forgotten.
I'm not really a programmer, but I can follow someone else's guide like a champ.

One thing to remember is the arduino is a little computer by itself, it wouldn't be able to store the data it reads, just pull it out and put it into the serial monitor, somewhere there should be something about outputting to a file though. Programming would be similar if I figure that out, the little arduino would need to have all the code. I have seen ways that TeraTerm can push a file down the serial port, but first off I should just stick to the basics of reading.

There are arduino libraries for SD cards, read and write, so it's a bit of a faff moving stuff about, but it should be possible to get it to read the data and write it to an SD card, and similar backwards if flashing works, by reading from the SD card.
Anyone smarter than me might be able to make a Windows compliment program with a UI to control it, but for now, I'd be happy with something reading it byte by byte and taking ages, as long as it gets it right.




What I'll probably end up doing is finding a cheap Mondeo EECV with a similar format, same type of memory chip inside, and also something I'd be able to see someone else's read from the ECU so I know what to expect, and see if a read I pull matches.
Granted, checksums should show if the data ended up corrupted, but it would be better to do all this on a guinea pig first.
At least that way I won't screw up the rare stuff.


Which number would be the hardware code?
On the paper label there is XR1F - 12A650 -AB, and XR1F-AA / PWB6565 on the reverse of the board
It wouldn't surprise me if it is a repurposed board from something else. It seems the hardware is very flexible, but I don't see XR1F appearing on anything else.
I have a feeling the older Vanquish one might have had XR8 on it, as at one stage I was wondering it it had anything to do with a Ford Falcon.

[jsa]

It's here-

https://eectuning.org/forums/viewtopic. ... 98#p129998

Thanks.

The schematics are there, it's direct parallel to the J3, so no need for the 74HC stuff, a multiplexer and a latch.
The code in C is in that post, which would make a good starting point.

Giveio required, 32bit era driver, though there appears to be 64bit versions floating about. Might be able to get it to work on modern hardware.

Which number would be the hardware code?
On the paper label there is XR1F - 12A650 -AB, and XR1F-AA / PWB6565 on the reverse of the board

Searched the part number and come up with
MAM-101
as the hardwsre code. Search for that only comes up with Aston units.

It wouldn't surprise me if it is a repurposed board from something else. It seems the hardware is very flexible, but I don't see XR1F appearing on anything else.

PWB printed wire board. Some times they are used in different hardware codes with diffent component counts.
XR1F is a year and vehicle model code.

I have a feeling the older Vanquish one might have had XR8 on it, as at one stage I was wondering it it had anything to do with a Ford Falcon.

Hardware code would be the same or very close if it did.

[wwhite]

It's here-

https://eectuning.org/forums/viewtopic. ... 98#p129998

The schematics are there, it's direct parallel to the J3, so no need for the 74HC stuff, a multiplexer and a latch.
The code in C is in that post, which would make a good starting point.

Disappointing. Your schematic will never work in implementation.
I'm pretty sure J3 Port Pin 22 is cycled to dump the contents of the ROM.
Your schematic doesn't have that connected.

[wwhite]

So- what I have gathered about the N70005FWCHCA so far, it's a custom Intel chip, double latched.

The EPROMS and EEPROMS have the same pinout, not too special:

The 8762/8763/87C66 EPROMs and the 87F66 EEPROM are identical devices with the exception
of memory size and type. They are all pin-compatible.

[ollopa]

Disappointing. Your schematic will never work in implementation.
I'm pretty sure J3 Port Pin 22 is cycled to dump the contents of the ROM.
Your schematic doesn't have that connected.

That seems unnecessarily rude :(
I have to disagree with you. I think it's fairly obvious that the design has actually been built, tested, and used on multiple EECs so that should give a hint that there is more than one way to read the ROM. You'll notice that both reset and pause are pulled low in the design which means the microprocessor tristates the MBUS control and data signals, completely relinquishing control to an external device. This means you don't need to use the test strobe to dump the ROM, you can simply act as the microprocessor would and control strobe, di, and it directly.

The ROM dump mode is when only pause is pulled low and reset is left high. In this mode the data lines are tristated but the microcontroller forces strobe, di, and it high which then requires the test strobe pin to dump the ROM.

[ollopa]

...I might be able to dust off my old arduino knowledge, and be able to make something that plugs into USB on anything modern.

I have something I named the "EEC Slurper" for interfacing to the MBUS from an Arduino board. Although it uses the Arduino hardware it does not use any of their software or libraries, which I personally consider a plus. Code is in Atmel Studio and could be tweaked a little bit to be compatible with the Arduino bootloader. It can dump the ROM and transfer over XMODEM or YMODEM to a terminal program like TeraTerm, HyperTerminal, SecureCRT, MobaXTerm, etc. I think the XMODEM protocol itself has a bug that was getting triggered which prompted me to implement YMODEM. I wanted to replace both with ZMODEM instead but my attention got drawn to some other project before I ever finished porting a ZMODEM implementation over.

There's an interactive serial shell that allows for manually setting MBUS signals, performing some basic operations on SPC and DAR, and of course dumping the ROM:

Code: Select all

command commands[] =
{
    {"clitest",     cmd_clitest},
    {"reset",       cmd_reset},
    {"help",        cmd_help},
    {"led",         cmd_led},
    {"mbus",        cmd_mbus_s},
    {"mbus?",       cmd_mbus_q},
    {"di",          cmd_di},
    {"it",          cmd_it},
    {"stb",         cmd_strobe},
    {"status",      cmd_status},
    {"writedar",    cmd_writedar},
    {"writespc",    cmd_writespc},
    {"readdar",     cmd_readdar},
    {"readspc",     cmd_readspc},
    {"dumpx",       cmd_dumpx},
    {"dumpy",       cmd_dumpy},
    {"testxmodem",  cmd_testxmodem},
    {"testymodem",  cmd_testymodem},
};

Maybe I'll clean it up and add a schematic after I get back home in in mid January, and put it up on github. I did this project about 5 or 6 years ago just to prove to myself that I understood how MBUS worked and now I've nearly forgotten I even made it, let alone what unresolved issues there may have been. With Moates closing up shop maybe there's a renewed interest in new J3 adapters, which I have plenty of ideas for...

[sailorbob]

The EPROMS and EEPROMS have the same pinout,

They don't, look at pins 1, 19 and 23.

[wwhite]

The EPROMS and EEPROMS have the same pinout,

They don't, look at pins 1, 19 and 23.

They are all pin-compatible.
The symbol/label are different, Bank Select (BS) vs TEST, Test Strobe vs Test Enable, Special Test mode vs NC.

[sailorbob]

That clearly shows they aren't pin compatible. Being physically the same is not the same as being pin compatible.

[sailorbob]

I'm pretty sure J3 Port Pin 22 is cycled to dump the contents of the ROM.

Using the /TSTSTB signal to dump the ROM only works on certain types of ROM fitted. Not all ROMs have that signal pin.

[wwhite]

Thank you for the clarification.

[ironmanisanemic]

FYI that flash chip (N70005FWCHCA) has been identified as a Intel 28F010 FLASH PROM. readable in most ordinary universal prom readers/burners.

[V12AML]

somebody already dumped his pcm off the j3, got it modified and then reflashed. if you want i can reach out to him. i assume you’ll want to modify it to non federal spec to get rid of the useless IMDM

vanquish was the first ptec (150 pin) with electronic throttle control built in, s-type had a whole module talking over scp just to coordinate things.

[jlowens76]

Hi guys,

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-

hey did you ever get anywhere with this? or find some help to further the project?

[DuvallLockAndKey]

FYI that flash chip (N70005FWCHCA) has been identified as a Intel 28F010 FLASH PROM. readable in most ordinary universal prom readers/burners.

Is this verified by anyone? From my information an 87C66 or 87F66 is 56KB and a 28F010 is 132KB. Also 28F010 is DIP-32

[tvrfan]

I don't think it's been covered so far, so I am adding this nugget.

As I remember -

The early EECSucka circuits did not work on EEC-V (8065 CPU). This wasn't just about the bank. The memory chips/MBUS in earlier 8061 EEC would allow just 'read', 'read', 'read' on the MBUS as the read address would be auto - incremented. I think this was outlined somewhere in one of the descriptions ??? This early circuit could get out of step and start to read garbage, because it used a short cut. It required 'padding' in the software reader to get the timing right.

As part of changes for banks, this short cut trick no longer worked on 8065 MBUS, which required a complete 'cycle' of signals to do a memory read, and so 8065/multibank readers required more logic chips. So more than just the bank select changed. But I can't remember exactly what the details were....