TECHNICAL NOTES ON THE EEC-IV MCU - Auto diagnostics

Eectch98-Part4.fm
goes to an HSO port. Currently, there is a piece of code that is added to the
interrupt routine that allows sending an address to the EECIV via the STI line and
then echoes out the result from the STO line. It needs two hooks into the EEC -- one
for a periodic interrupt (for the STO data) and the other for the HSI interrupt.
WARNING! The sensor +5 volts is the SAME as the CPU +5 volts. Any accidental connection
of the +5 ref of the TPS sensor to the battery via a test light, and
spitzensparken and poppencorken.
The biggest problem I can see when re-calibrating an EECIV is that there is virtually
no way of figuring out what it is up to. Perhaps a ’scan port’ patch would be
useful? How I think you would need to do that is enable the EER, and modify a few
bytes of Ford code to get a hook for ours. Then out of the STO you can get scan tool
data like you see on a GM. The limitation here is someone needs to figure out the
use of any interesting memory locations and the scaling factors.
This means when you get data, the SES lamp flickers.
I think J3 pin 12 MRESET and 22 TSTSTB are the ones to use with the pause pin to
read the ROM from J3. You have the unit full on and in pause mode by putting a low
on J3 pin 8 and then putting a low on pin 12 and releasing (to reset memory program
counter I guess) and then keep strobing pin 22 TSTSTB low and reading MB after each
strobe and it seems to be reading the ROM contents. It appears STROBE pin 21 is for
reading and control from CPU but MSTROBE is for memory dump.
Another contributor wrote:
In my opinion, the whole memory was set up to be high speed, yet only 8 bits wide.
A conventional computer has to use the bus to apply an address, and then another bus
to read the data at that address. It appears that, in an EEC, the CPU can just
request "the next program byte" -- as pointed to by the "Slave Program Counter" so
there is no need to send an address. There is a second register, the "Data Address
Register", which is in charge of the data. It, however, doesn’t increment by
itself. The advantage of having both of these registers is that one can read an
instruction, download the address of some data that’s wanted, read the data, and
then read the next instruction WITHOUT SENDING AN ADDRESS FOR THAT NEXT INSTRUC-
TION. I still have to be able to load that Slave PC with another address though, in
the case of jumps and interrupts and stuff like that.
I’m guessing that getting the high and low bytes of data is even easier than I’m
showing. Why else would they call it a "16K X 16bit ROM"? If you have to ask for
the high and low bytes separately it would be more accurate to call it a "32K X 8bit
ROM"
EEC-IV Technical Notes: External Control 55 last edited: 9/29/98