1997 F-Body ECM

[kur4o]

Here are some of the dwell settings in the TPU. I am trying to find why there are 3 different dwell timings

RESERVED:149E word_149E:      fdb 0                   ; DATA XREF: OC4I+65Ew
RESERVED:149E                                         ; IRQ+A2w ...
RESERVED:149E                                         ; Final dwell - $0001
RESERVED:14A0                 fcb   0
RESERVED:14A1                 fcb   0
RESERVED:14A2 word_14A2:      fdb 0                   ; DATA XREF: OC4I:loc_4FB2w
RESERVED:14A2                                         ; _TPU_scalar_resetsub_A4A4+192w
RESERVED:14A2                                         ; 2083 VALUE;
RESERVED:14A2                                         ;  #6 MINIMUM
RESERVED:14A2                                         ;
RESERVED:14A2                                         ; Dwell 1 $28 value min dwell???
RESERVED:14A4                 fcb   0
RESERVED:14A5                 fcb   0
RESERVED:14A6 word_14A6:      fdb 0                   ; DATA XREF: OC4I+667w
RESERVED:14A6                                         ; _TPU_scalar_resetsub_A4A4+18Cw ...
RESERVED:14A6                                         ; final dwell -$0002

149e is the main dwell calculated from pcm.
14a2 is always preset with $0028. Might be some scalar.
14a6 equals [149e-$0002].

I will be grateful if you can test the settings and figure what they do and the conversion factor of 149e to ms[I suspect it is the same as injector BPW but that $28 scalar might change the equation] .

I found that the pcm has built in routine for reading through obd2. It uses mode 35. If you want to try reading it I will get you the command set.

[Tom H]

Here are some of the dwell settings in the TPU. I am trying to find why there are 3 different dwell timings



149e is the main dwell calculated from pcm.
14a2 is always preset with $0028. Might be some scalar.
14a6 equals [149e-$0002].

I will be grateful if you can test the settings and figure what they do and the conversion factor of 149e to ms[I suspect it is the same as injector BPW but that $28 scalar might change the equation] .

I found that the pcm has built in routine for reading through obd2. It uses mode 35. If you want to try reading it I will get you the command set.

I will help if I can. My setup at the moment is with the ESide board alone, Tside removed/ no ribbon cable. I am not running GM code and have (so far) only 1K of ram to work with. Both program and variables: 1K. At boot the PRU ram is not available until the chip select is programmed. I can increase (a little) the available ram, but then need to bootstrap a loader. The loader would then download to the ram at $1800-$1FFF and execute. Also requires a hardware change for me because issue of a reset is needed without power down. I didn't build that in.

To test the dwell settings and their use, I need to write a program to re-flash the ESide. That needs to be done just to have enough space to work. I wish I had another PCM or two. I probably should make that happen.

I will let you know what I find.

-Tom

[Tom H]

Here are some of the dwell settings in the TPU. I am trying to find why there are 3 different dwell timings


149e is the main dwell calculated from pcm.
14a2 is always preset with $0028. Might be some scalar.
14a6 equals [149e-$0002].

I will be grateful if you can test the settings and figure what they do and the conversion factor of 149e to ms[I suspect it is the same as injector BPW but that $28 scalar might change the equation] .

I found that the pcm has built in routine for reading through obd2. It uses mode 35. If you want to try reading it I will get you the command set.

Thinking I may have found a way to help with these questions. I have found that the stock GM program in the TPU takes the VSS Input signal and creates the VSS Output to the dash. This is all done within the TPU and I can mess with certain values of conversion. *IF* the same is true of the dwell, I need to make the TPU think it is connected to a running engine and get it to make spark. With that setup, I can then mess with the parameters you seek to understand and find how the TPU changes dwell. I have located a number of locations that contain flags to the TPU. It will be interesting to see how all the various flags affect dwell ( and fuel and and...)

Perhaps I can do this using the opti-spark simulator that I wrote. I got this working (the way I think it should) but have not yet tried it out. There are two questions that remain: Polarity and phase.

I am not sure if the low res pulses are active high or active low. Somewhere back in this series of posts I tried to answer this question. I will review but if anyone can confirm if the low res is a high that transitions low when light passes through the wheel or the other way. Second question is similar: Take one of the four low res that are narrow (one transition of the hi res wide). Does the high resolution signal transition high or low in the middle of the short low res pulse. I will send some scope shots to help on this.


Note: SPFAUTSCH answered most of this in post 18 of this thread. Should have taken more time to review B4 posting.

I will try to sort it on this end and see what I can find.

-Tom

[Tom H]

OK, from my understanding, these waveforms should drive the ESide at a rate just under 4000 rpm.

This shot shows the relationship of high res and low res. Just one cylinder event shown
IMG_1717.jpg

This shot shows three cylinder events
IMG_1718.jpg

This shot shows all eight cylinder events, and the start of the next cycle
IMG_1719.jpg

Now to connect it to the Eside and TPU.

-Tom

[kur4o]

That opti generator can be used for simulating engine running for debug and reverse engineer. I hope you get it right and it is not too hard to use.

I am almost sure for the conversion factor of dwell to ms. It should be the same as the low res opti and bpw signals. X*0.01534=ms
Not sure what are the 3 dwell values needed for.

[Tom H]

That opti generator can be used for simulating engine running for debug and reverse engineer. I hope you get it right and it is not too hard to use.

I am almost sure for the conversion factor of dwell to ms. It should be the same as the low res opti and bpw signals. X*0.01534=ms
Not sure what are the 3 dwell values needed for.

I have the simulator hooked up & running. I see the Opti inputs and tach output. Caluclated input RPM (can easily be changed) is 3728 RPM. What frequency should be expected at the tach? I see 8 X that. Is the tach output = RPM / 60 * 8? If not, do you know the formula?

If you know, what things are necessary for the PCM to produce a spark signal?

-Tom

[kur4o]

What frequency should be expected at the tach?

The service manual says that 60hz output signal from pcm equals 900rpm on the dashboard.[1hz=15rpm, 248hz=3725rpm]. It is very likely a scalar for the tacho to be set at the TPU.

The spark signal will be outputted whenever there is a low res pulse sensed by the pcm.

[Tom H]

I am having a hard time generating interrupts. I see how/where they are cleared, but the interrupt enable bits seem to be buried somewhere in the $14/$15 range. I expected them to be in the control register area in $16. <sigh> This all seemed much easier to do before I started.

re-tracing code looking for errors...

-Tom

[Tom H]

Hi kur4o,

I still have no ignition control output. Simulator is connected, interrupts running, seems to count knock pulses: I think the TPU is not unhappy. I am not sure what type of drive the ignition control is, but expect it needs a pullup on the bench (?)

I have not defaulted dwell settings yet. For a quick test, can you suggest $149E = $???? $14A2 = $???? $14A6 = $????

-Tom

Here are some of the dwell settings in the TPU. I am trying to find why there are 3 different dwell timings

...

149e is the main dwell calculated from pcm.
14a2 is always preset with $0028. Might be some scalar.
14a6 equals [149e-$0002].

I will be grateful if you can test the settings and figure what they do and the conversion factor of 149e to ms[I suspect it is the same as injector BPW but that $28 scalar might change the equation] .

I found that the pcm has built in routine for reading through obd2. It uses mode 35. If you want to try reading it I will get you the command set.

[kur4o]

load 14a2 with $0028
load 149e with $00c5[must be 3ms]
load 14a6 with $00c3

The signal should be high during the dwell event. Coil is fired when signal goes low. When the signal is high the coil is charging. In that case you should see 3ms high, every opti low pulse.

[Tom H]

As yet, no ignition output. I have started to trace back to determine why. The ignition seems to be driven by a small FET next to a large resistor just below the black connector / above the heat spreader. Gate of the FET is driven by what I now believe is an ignition chip. This is the 144436 part that has come up from time to time. I believe pin 16 is the output. This the case, a bunch of questions open up...

Does this chip provide a fall back when everything else fails?
How does software control the chip? / what exactly is it's function

I see connections from the port expander + opti signals + signals from TPU:

2 Port expander pin 32
4 Comparator 2 pin 13 Opti-Spark HIRES signal
7 Port expander pin 60
9 Port expander pin 61
10 Port expander pin 7
20 TPU PIN 9
28 TPU PIN 25

Looks to me like all the food groups are there to support some sort of back up mode ops

As usual a thing that looks somewhat easy to figure out is made much more complicated by the need for fail safe.


On we go...

-Tom

[kur4o]

So 144436 must be the father of later style PCMs ignition chips. They also contain all the cam,crank sensor inputs and I guess there is a fail safe mode built in, for spark, based only on opti signals.
What will be interesting to find is there are a built in second channel or total of 4 channels of spark control for waste spark setup, like the northstar dis system.
I remember there were some empty pins that have no connection. Maybe tracing the outputs to the board undefined pins will reveal if that was left on the table.
The format of the low res signal suggest a waste spark setup. The 4 pins to the ram expander might drive the 4 outputs and the 2 pins to tpu can be used for configuration. Later style ignition chip can be software configured for single coil, waste spark,multi coil setup for v6,v8 signals.


On the dwell failing.
The irq routine shares data bidirectionally with TPU, like the firing cylinder id and all other configs. If it doesn`t run in bootstrap the dwell tests might fail for that reason.
Could it be possible that you enable execution of irq requests in bootstrap mode or it will be too much hassle.

[Tom H]

So 144436 must be the father of later style PCMs ignition chips. They also contain all the cam,crank sensor inputs and I guess there is a fail safe mode built in, for spark, based only on opti signals.
What will be interesting to find is there are a built in second channel or total of 4 channels of spark control for waste spark setup, like the northstar dis system.
I remember there were some empty pins that have no connection. Maybe tracing the outputs to the board undefined pins will reveal if that was left on the table.
The format of the low res signal suggest a waste spark setup. The 4 pins to the ram expander might drive the 4 outputs and the 2 pins to tpu can be used for configuration. Later style ignition chip can be software configured for single coil, waste spark,multi coil setup for v6,v8 signals.

It may be that the chip looks at the incoming Opti pulse stream and tests for errors. It can sample the hi&lo res signals with eclock (it is connected) and count the transitions. When I was working through the port replacement unit there were a couple of spots in the $1807 register (I call that port D) that I could not understand. Also a couple of pins that connect to the ignition chip that I could not toggle. My thinking is that both the ignition chip and the PRU are connected along with pull up resistors. That makes the lines multi-drop such that the TPU or the ignition chip can tag the opti as bad. This morning I will apply the opti signals and see if I can change the state of the two lines. This will at least bring me closer to proving both the opti simulator and understanding the ignition chip. Problem here is that there are so many un-knowns.

On the dwell failing.
The irq routine shares data bidirectionally with TPU, like the firing cylinder id and all other configs. If it doesn`t run in bootstrap the dwell tests might fail for that reason.
Could it be possible that you enable execution of irq requests in bootstrap mode or it will be too much hassle.

I am running my own ISR. It is very limited at the moment, just clearing the interrupt and returning. Yesterday I added some register reads to the ISR, nothing interesting yet. I can not run the GM ISRs because they use the RAM that I run my program from. This all will crash once the code is over-written. If you have specific actions that I should include in the ISR, let me know. Also I am using only one of the four interrupts that the TPU can generate. I need to spend some mind time looking at the GM ISRs and try to figure out the intent. At some point I will need to write routines to re-flash. At that point all the constraints re code size and so on will go away. At the moment I have few bytes that remain before I need to change from bootstrap of code to bootstrap of a loader + load into PRU ram ($1810 --> $1FFF)


-Tom

[kur4o]

I finally decoded the disassembly and found the missing pieces of the dwell targets.

load 14a2 with $0028 This is the minimum off time of the coil between charging
load 149e with $00c5[must be 3ms] This the main dwell target
load 14a6 with $00c3 This the main dwell target minus low [res time /16] or on newer calibration main dwell -#0002

Now I have to log some of these to confirm the conversion factor. I found some dwell target table for this coil to confirm the conversion.

Since you have confirmed the irq interrupts, did you managed to look what drives the OC4I and what is the refresh rate of it. This is the other main routine that is run in the PCM.
The IRQ seems time critical. Can we calculate the time needed by processor to execute. On 96-97 code there is too many new bloatware in the code and above 4000rpm most of it, is skipped or crippled like the ve lookup tables. And some of the code is skipped each XX firing cylinder number.
Now you can return to TPU dissection and nail the flashing. Tside controls vpp voltage pin of both sides, so an external vpp supply will be needed if you flash only eside.


ON my chart I never traced some of the pins on the pcm connectors. B17, B32, A1, A16, A17, A26-30, D4, D5, D17, D23.

So do you think there is some hardware limp home mode that can run the engine in a total cpu failure, or is it just for monitoring purposes.