[Lupo]

Is there currently any hardware solution to read data directly from a EEC4 memory device,
reading the data directly as the EEC4 would see it (in binary form)?

The problem I have is this:
I have a Taurus SHO, with and EEC4 computer. A long time ago, they had a chip solution called "LPM", which consisted of software, and a chip. The chips were special in that they could only contain calibration information from x6000(hex) and on. Any information written to the socketed EPROM on this LPM device is always read starting at x6000, and not x0000 when plugged into the EEC4.
I think this was done to make it impossible to include any program code, and make it so only calibration code could be overwritten on the EEC4. Because you cannot override the program code with this chip, each calibration has to be specific to one of the 6 or so SHO ECUs, and are not compatible with each other. Also this calibration information happens to be scrambled when you burn it to the EPROM, so at some point, this LPM chip descrambles the information before the EEC4 reads it.
The LPM chips are not made anymore, getting hard to find, and only work with this old LPM software.

Question:
Is there any hardware solution that has an edge connector like the EEC4/5, and can read a chip as the EEC4 sees it? This way I could get the straight unscrambled calibration information, which I could create a complete binary with by adding program code.
With a complete binary, I can write it to a normal EEC memory device, which would work on any SHO EEC4, because the program code is included. I could also take the binary file and read it directly into CalEdit, and use tweecer.

I think there are more than a couple good secrets hidden in the LPM calibrations and software.
Anyways, thanks for any help you might have!

[cgrey8]

I believe what you want is offered in Moates hardware. Moates sells chips, EEC tune extractors, and chip burners. Moates also sells a device called the Quarterhorse which will hold multiple EEC tunes (in total and unscrambled), let you flip between them on the fly, and will also datalog the EEC if you have a definition that knows where key pieces of info in the tune are. It even lets you make edits to the active tune on the fly while the engine is running without blipping the engine...unlike the TwEECer.

Read over the FAQ about what to know before buying a TwEECer or Quarterhorse for more info. Once you've read that, read over the thread about the differences between the TwEECer and Quarterhorse for even more specific info about the differences.

The catch is going to be whether BinaryEditor supports your EEC's strategy or not...and if it does, how well it supports the strat.

[tvrfan]

For just a straight read of the ROM, there were plans on the web for a simple home made cicuit, called the EECSUCKA I think - it used two TTL chips, and a bit of software for a PC.

A.

[86GT]

The Moates QH can read the entire range. So can the Burn2 with the F2E.

BTW
Adam Marrer and SHO Nut have all of the SHO strategies all broken out and working fine. Give them a ring. There is no need to re invent the wheel.

[94SS]

The Moates QH can read the entire range. So can the Burn2 with the F2E.

BTW
Adam Marrer and SHO Nut have all of the SHO strategies all broken out and working fine. Give them a ring. There is no need to re invent the wheel.

Do you have to worry about destroying the QH or EEC when reading a stock .bin if you try and read the EEC with your quarterhorse that has a non compatible boxcode burned to the QH?

[86GT]

no think of the QH as a pass thru device. It will simply read the tune and place it in BE where you can save it

[kylixrd]

I have an LPM in an '89 SHO with with a '90 B9B1 EEC. I have also designed my own J3 port adapter that uses a normal EPROM. Part of this project was to create a J3 port emulator so that I could test and make sure my J3 adapter was working correctly. Naively, I thought I could also read my LPM from the SHO... nope. I get nothing back using the J3 simulator, whereas the simulator works great with my own J3 ROM adapter.

After a lot of googling and reading... I've discovered, as have you, that the SHO LPM's need some "unlock pattern" before they'll begin to spill their guts. I know that there are some that know the "magical incantation" one needs to cast in order to get the LPM to react, but so far those that "know" aren't talking... for whatever reason. They're not being made anymore and the official hardware to read/write them is also very old, >15 years...

Does the LPM "peek" in on the MBUS as the CPU is booting up and expects a certain execution pattern? While "peeking" at the bus, does it wait for a "write" to a certain address in the RAM? Even if the data is "scrambled" when written, it *must* be unscrambled in order for the EEC to think that it is reading from its own internal ROM.

I've also built up the "EEC SUCKA" circuit and wrote some PC programs (for the J3 simulator too) to read the stock ECU ROM. I've read an A9L and it compares, bit-for-bit to a downloaded A9L.bin file... so I know that circuit is working.

So if this is the place for EEC Geeks... I'm sure someone can at least drop some hint...

Kylix.

[86GT]

I have an LPM in an '89 SHO with with a '90 B9B1 EEC. I have also designed my own J3 port adapter that uses a normal EPROM. Part of this project was to create a J3 port emulator so that I could test and make sure my J3 adapter was working correctly. Naively, I thought I could also read my LPM from the SHO... nope. I get nothing back using the J3 simulator, whereas the simulator works great with my own J3 ROM adapter.

After a lot of googling and reading... I've discovered, as have you, that the SHO LPM's need some "unlock pattern" before they'll begin to spill their guts. I know that there are some that know the "magical incantation" one needs to cast in order to get the LPM to react, but so far those that "know" aren't talking... for whatever reason. They're not being made anymore and the official hardware to read/write them is also very old, >15 years...

Does the LPM "peek" in on the MBUS as the CPU is booting up and expects a certain execution pattern? While "peeking" at the bus, does it wait for a "write" to a certain address in the RAM? Even if the data is "scrambled" when written, it *must* be unscrambled in order for the EEC to think that it is reading from its own internal ROM.

I've also built up the "EEC SUCKA" circuit and wrote some PC programs (for the J3 simulator too) to read the stock ECU ROM. I've read an A9L and it compares, bit-for-bit to a downloaded A9L.bin file... so I know that circuit is working.

So if this is the place for EEC Geeks... I'm sure someone can at least drop some hint...

Kylix.

I dont know much about that processor, but i can tell you this. On some of the processors there is a solder trace on the main board that is not complete and this will cause what you are seeing. If i can i will try to find a picture of it. All you have to do is complete the trace and that is it. There is no secret handshaking on the EEC4 or 5 J3 port.

[kylixrd]

I dont know much about that processor, but i can tell you this. On some of the processors there is a solder trace on the main board that is not complete and this will cause what you are seeing. If i can i will try to find a picture of it. All you have to do is complete the trace and that is it. There is no secret handshaking on the EEC4 or 5 J3 port.

I was referring to the LPM chip module itself. I was trying to read the tune from it using a J3 simulator I built. I can read the eec just fine using the eec sucka circuit I built. The LPM I have is a sealed module with the J3 connector (old Autologic, I think). There is also a few wires that stick out from the device near the connector. They're cut really short. I understand that those are for an external selector switch since this particular module supports multiple tunes. As for traces, there's no traces available on this module since it is completely sealed with an epoxy.

When I attach this module to my J3 simulator, I cannot read anything from it. I can attach other modules and the simulator works fine. I don't want to reprogram this module, I just want the tune.

Kylix

[86GT]

ah i get it now. Do not read the chip serially. If you do that is the security measure. The eec never reads more that 200 bytes is a row. Make your reader jump around untill it reads it all like the EEC would do.

[kylixrd]

ah i get it now. Do not read the chip serially. If you do that is the security measure. The eec never reads more that 200 bytes is a row. Make your reader jump around untill it reads it all like the EEC would do.

Interesting... I'll update my software to do that and give it a try. If I read every other block of 16 bytes, is that sufficient? I'm under the impression that it only responds to addresses >= 6000H, so reading 6000H-600FH, then 6020H-602Fh, 6040H-604FH, etc... then come back through and read 6010H-601FH, 6030H-603FH, etc.. As long as I reset the DAR enough, it will not trigger the security lockouts...

I guess that is what folks mean when they say the data is "scrambled"?

Thanks!

Kylix.

[86GT]

each manufacture has a different limit on the consecutive reads. Just try a few different patterns and see what happens

[kylixrd]

each manufacture has a different limit on the consecutive reads. Just try a few different patterns and see what happens

I've spent some more time on this and I'm beginning to think that maybe the LPM module is either dead or there is some other magical incantation needed. I set the DAR to even addresses starting at 6000H, and then toggle ST to read the odd address. I still get all FF from it. I have a same era A9L that I've taken apart to see what pins are actually being used on the J3. The EEC-V BS0 and BS3 pins are unconnected, and my simulator had those set to BS0 - 0 and BS3 - 1. I disconnected them and let those pins float thinking that may be the module actually looked at them. I put an oscilloscope on the pins and can see that I'm sending data for the DAR. I don't however, see that the module is dropping ROMDIS when being addressed. I scanned the entire range non sequentially from 6000H to FFFFH and still got FF for each byte. I'm not really certain that the module is even trying to drive the MBUS since my circuit has some pull-ups. I even changed my application to allow me to do each phase of the read cycle independently so I can inspect the J3 statically. As long as the J3 module's internal logic is static, it should work at whatever slow clock speeds I use.

[Lupo]

The data is written to the LPM in scrambled form, so even if you get the data off, you still need to unscramble it, to put it back in the normal binary form.
I would imagine that the LPM unscrambles somehow before the the EEC reads it.
I also image that the LPM is protected so you cannot read it sequentially; all you would get is "FF" down the line.
but you are absolutely correct in that the LPM only addresses from 6000h, making it a calibration only chip.
Anyways, I do have the hardware/software to read a "block" LPM, but the resulting 32K file is scrambled. So then I mapped out exactly how it's scrambled, and wrote a piece of software that assembles it back to normal binary form. Problem solved.
I can also rescramble any normal binary tune and put it right back on the LPM.

[kylixrd]

The data is written to the LPM in scrambled form, so even if you get the data off, you still need to unscramble it, to put it back in the normal binary form.
I would imagine that the LPM unscrambles somehow before the the EEC reads it.
I also image that the LPM is protected so you cannot read it sequentially; all you would get is "FF" down the line.
but you are absolutely correct in that the LPM only addresses from 6000h, making it a calibration only chip.
Anyways, I do have the hardware/software to read a "block" LPM, but the resulting 32K file is scrambled. So then I mapped out exactly how it's scrambled, and wrote a piece of software that assembles it back to normal binary form. Problem solved.
I can also rescramble any normal binary tune and put it right back on the LPM.

In theory, my J3 simulator should be able to pretend to be the eec and assert the various signals in the same manner that the eec would. The idea is that it should be able to read the LPM as the eec would. IOW, if the eec sets the DAR to 6024H, it should be able to read the byte at that location, regardless of any internal "scrambling". The eec expects that when it sets the DAR to a value, it is going to get the byte at that address.

As for reading the module, I'm not reading it sequentially at all. For instance, reading like this:

. set DAR to 6000H, read byte, <strobe ST to bump DAR to 6001H> read byte.
. set DAR to 6040H, read byte, <strobe ST to bump DAR to 6041H> read byte.
. set DAR to 6080H, read byte.... same as above
. set DAR to 60C0H, read byte..
....
. set DAR to 7FF0H, read byte..

I fill 256 byte blocks based on the above algorithm before proceeding to the next. It was my understanding that you cannot set the DAR to an odd address and must use the "set to even address, Strobe ST" technique to read an odd address.

Thanks for confirming more data. I've just not seen a solid description of exactly what pattern of signals the LPM expect to see on the J3 port in order for it to divulge its secrets. Maybe it is expecting some pins other than the MBUS, IT, ST, and DI to be in a certain state? There are the MRESET, RESET, RAMDIS, and ROMDIS pins, which may have to be in a particular state...

Thanks

Kylix.