Quote Originally Posted by Tom H View Post
Taking your questions somewhat out of order...

There are two processors Tside and Eside that communicate over SPI. The scheme used is a bit different depending on direction, here is how:
Tside sends a set of parameters to Eside. The "mastership" of the bus is swapped each byte sent. This reduces interrupts. Data from T -> E is the same each transfer block (32 bytes). The T->E has a paged scheme, transfering 19 bytes of data each block + 10 bytes that are paged. There are eight pages such that over 8 transfer cycles, 80 bytes are sent. This is enough to send all the statistics required for OBDII. This is my best try at a general summary. Getting into the details is a bit more difficult, so I will leave it here unless you have some specific question...

The VPW comms is provided by a chip external to the processors. It is accessed only by the TSide so read and write to the ESide must be done by passing through the TProcessor. The SCI is internal to the processor. For '96 and '97 the Eside SCI is not used: that is all the ALDL comms is looked after by the TSide. Once again any data destined for ALDL from the ESide must be passesd to the TProcessor over SPI for tx on the SCI/ALDL. Chip used for VPW is Motorola MC68HC58 Data Link Controller. The DLC is addressed at $1060 & $1061.

There was a request to separate PCM info from tools info. There is a second set of posts regarding tools to read and write the PCM. All of my tools have used a home brew cable that I use to access the PCM. The tools I wrote connect to the PCM through this cable over USB based NRZ (serial) comms. The cable is set up to act much like the age old ELM327 except that it has capability to send large frames required to download/upload. Have a look through
http://www.gearhead-efi.com/Fuel-Inj...7-F-Body-Tools
At some point I will add the 4X feature and enable both read and write. For now the work on my system.

Hope this answers some of your questions.
-Tom
This makes quite a bit more sense.
I could see the addressing to 0x1060 and also 0x1061, but it didn't quite line up with what I was expecting with the HC11 reference manual.
The only reason they looked interesting was they were checking specific hex values that I use in the later model ECU kernels for the DLC status. (ie.. checking for a completion code).
In comparison to working with the P01/P59/P04/P12 ecus, this does seem to be a bit more complicated with the dual processor setup.

Nice work on the tool! Looks like the circuit is a derivative of the ELM from what I can see.
I program with the OBDX Pro tools since I am the programmer for them, Pete (My colleague) does all the circuit designing and testing.

Looking through that thread, look like you have already created an application to read (0x35) the ECU data. Did you have plans to continue to add in the writing capability also?