1997 F-Body ECM

[kur4o]

Thanks for the input on the SCSSI. After some trials and some bricks I managed to make the eside talk while the engine is cranking.
First I tried to reenable comms at oc4i. It didn`t worked as expected. I ended oraa $20 to the SCCR2, which make the comms worked on a very rare random basis.
I was tired of experiments and skipped the scssi disable code in the irq. This made the eside talk. It is not clear what will happen on a higher rpms, so I think to put a rpm threshold and reenable the comms at oc4i after the rpms drop. I will also cut all aldl chatter on the bus. I suspect the interrupt is activated on any aldl bus activity.

I wish I have an opti simulator for testing. How hard will be to make one like yours with a knob to regulate rpms.


The plan for cracking the tpu from the backdoor is solid. You can chart the unused pins ram locations and possible found more things left on the table from factory.
Tpu and eside exchange data each run of the irq. Eside calculates cyl fire id and sends it back to the tpu. I also found some code used for loss of sync[cyl ID] situations and resync on the fly. Really good job from GM.

[Tom H]

I wish I have an opti simulator for testing. How hard will be to make one like yours with a knob to regulate rpms.

You are welcome to the code on request. It isn't sophisticated and not finished in a nice way. Just a crude tool I knocked out to try and get an understanding. There is no "knob" to adjust RPM but it can easily be added. Do you have any dead PCMs? If yes, why not fit the code into the EEPROM and run it there. I think this was what was in my mind when I started things. My board is a tester from way back in the 1990s. It runs at 4MHZ but with 0 effort will just scale to the 12 used by GM.

Let me know what you need, and I will post. Easy way to work will be through bootstrap. I can give code, instructions++

-Tom

[Tom H]

Good fortune this morning, I got working with the fuel side and started to characterize some of the parameters. I don't have a great scope, but it looks to me as if the injector pulse width defined in the 16b registers at $1400 - 0E work like this:

GM's crystal frequency
12.5829 MHZ
12582900 HZ

Resulting Eclock frequency
3.145725 MHZ
3145725 HZ

Clock period
79.473E-9 Crystal
317.892E-9

Injector pulse width for locations $1400, $1402, $1404, $1406, $1408, $140A, $140C, $140E
n * 15.259E-6


Still a bit of uncertainty if the divisor is 48 or 50. If I squint just right I can see one or the other. One of these days I need to trade up from my army surplus scope. I will bypass the drive circuits&FETs to measure and resolve this Q.

Also got the ignition to fire this morning. Real happy with that. On we go...

-Tom

[kur4o]

That is some great breakthrough. Now can we find out what is the usage of high res signal. Is it only used for spark triggering or it does affect fueling also.
Cranking is really hard without high res signal but that is because the pcm needs some cranking before setting the code. I also traced some tpu bits changed on the error.

The pcm outputs 5v on low and high res pins and the opti drives the signal low on empty slot I guess.
The simulator should be pretty easy if I had a spare pcm.

n * 15.259E-6
That scalar is used for all time based units in the tpu. It will be nice to confirm it. Now it is something more of a guess based on Gm conversion data of bpw.

[Tom H]

The pcm outputs 5v on low and high res pins and the opti drives the signal low on empty slot I guess.
The simulator should be pretty easy if I had a spare pcm.

I thought you might already have what you would need. Otherwise, almost any of the single board computers available for a few $s can easily do. It is logistically easier if the part is 5V based but almost anything will do. Doesn't need to be Motorola at all. A PIC or an old intel 8051/31 type board would be ideal. In fact now that I think of it... your PC could output the pulse train through a parallel port under dos. I wouldn't want to use windows/linux/some big OS because the timing will be un-steady due to latency. Also the larger OSs might be slower and limit "RPM". Even so, you could try it under windows and see if it meets your need.

-Tom

[Tom H]

Still working on TPU but,

I have a question regarding MAF. My understanding is that the MAF unit produces a frequency that is interpreted by the TPU. Is the frequency proportional to air flow or air flow mass? I know mass will be affected by temperature (IAT) and pressure (Barometer) the question is, does the MAF unit factor all this in or is it actually a measure of air flow and uses software to come up with the mass rate? I think the MAF might be mis-named (?)

If anyone can provide some clarity it will be a help.

-Tom

[kur4o]

Maf is a mass air flow, It measures mass with a heat element being cooled. It is supposed to compensate for temperature and pressure, however humidity kind of screw the reading. However in the code there is only baro correction and some temperature correction for subzero temperatures. The corrections might not be output related but different engine requirements at that range.It also updates so quickly that gm put some smoothing routine to compensate for rapid changes.

The TPU outputs 4 maf values and eside gets an average of them for final calculation. It uses the raw TPU output for a maf table lookup and takes the value from table and interpolates between 2 adjacent cells. The first byte of RAW output is the vector for the table lookup and the second byte is the interpolation factor 0-255 or 0.01-0.99.

I will try to find a 68hc11 pcm to run a custom code for opti simulation. For variable rpm output I think a table for 1 high res pulse vs time vs rpm needs to be done and low res will just follow the high res.