1997 F-Body ECM

[Tom H]

Got to the bottom of the "no interrupt"/reset problem. Bootstrap places a rom in memory that re-directs interrupts with a scheme they call pseudo vectors. In earlier testing I wanted to get that rom out of the way so I turned it off. If you try to use interrupts in bootstrap with the rom off, it vectors to the usual spot in the $FFxx space. Since there is the GM flash up there it will run the GM ISR. This was un-planned un-expected operation, but completely the way it works. My bad.

Turned on a bit in HPRIO at $103C to enable the rom and now working as expected. Oh well, there goes three hours. Now, back to looking at the TPU.

Initial look with the scope shows that the interrupt lines up with the start of each low res pulse.

-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.

[Tom H]

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.

I am not sure I understand your request, but here is what I know about the output compare 4:

* OUTPUT COMPARE 4 INTERRUPT SERVICE
*
* TIMER PRESCALE IS SET TO $0, TIMER INCREMENTS
* EACH E CLOCK. OUTPUT COMPARE 4 IS TRIGGERED
* EVERY 39,322 TICKS OF ECLOCK. ECLOCK IS SOURCED
* FROM THE 12.5829MHZ CRYSTAL. ECLOCK IS CRYSTAL 
* FREQUENCY DIVIDED BY FOUR: PERIOD OF 317.9NS
*
* TRIGGERED EVERY 12.5MS --> 80TIMES/SECOND
4978  FC 10 0E        LDD    $100E        ; TCNT: READ TIMER COUNT
497B  FD 02 FC        STD    $02FC        ; 

497E  FC 10 1C        LDD    $101C        ; TOC4: OUTPUT COMPARE 4 REG
4981  C3 99 9A        ADDD   #$999A        ; 39,322: COUNT + 12.5MS
4984  FD 10 1C        STD    $101C        ; UPDATE

4987  86 10           LDAA   #$10        ; TFLG1: CLEAR OUTPUT COMPARE 4
4989  B7 10 23        STAA   $1023        ; INTERRUPT

[Tom H]

RE the OC4 interrupt service...

Note that part way through the service a CLI instruction is executed. That results in nesting of interrupts for reduced latency. Some very good software to keep all this under control. Given all this, the TPU will interrupt the OC4 interrupt once the time critical ops at the start are taken care of.

-Tom

[kur4o]

As far as I get it, OC4I is called based on some timer that is updated regularly when the routine is executed.The chip config and timers is some area I am not really familiar with it, so if you shed some lights on the problem will be great.

Now on 94-95code we have

; public OC4I
OC4I:
ldd     TOC4H           ; Output Compare 4 Register (High)
addd    #$99A
std     TOC4H           ; Output Compare 4 Register (High)
ldaa    #$10
staa    TFLG1           ; Timer Interrupt Flag Register 1
brset   byte_1 2 loc_3A1A

If I get it correctly and there is not something else uncharted the OC4I is executed every 0.7813982ms.

Now I have some other question related with interrupts.
On 94-95 code eside can communicate over the aldl bus. It has E4 ID and the communication is handled by the SCISS. It works great when the engine is not running and I can log some memory regions real time for better understanding of the code. Somehow when the engine is started eside stops communicating. It just doesn`t handle the requests. Do you have ideas what can stops the pcm from servicing the SCISS requests. I will really like to get that fixed if possible. At least on lower rpms there will be plenty enough time for the pcm to handle communication.

I just found this at the very start of IRQ

ldaa    #$10
clrb
std     word_16F4
ldaa    SCCR2           ; SCI Control Register
anda    #$F
staa    SCCR2           ; SCI Control Register
ldx     #$1803
bclr    0,x 4
ldaa    PORTD           ; Port D Data
anda    #$ED ; 'ý'
oraa    #$2C ; ','
staa    PORTD           ; Port D Data

Could it be somehow related with the stopped communication.

[Tom H]

As far as I get it, OC4I is called based on some timer that is updated regularly when the routine is executed.

I hope my answer is actually to your question. If the answer here is way off base, just disregard.

The HC11 has a free running 16 bit counter. The count increases by one based on the clock frequency and pre-scale settings I gave in the other post. Each clock, the OCx function checks if the free running count is equal to it's TOCx register. If equal it sets a flag and can be configured to fire an interrupt. If you want a regular 12.5ms interrupt, you take the current count and add to it the number of clock periods that give you that time. Once time has past, the free running count reaches the value you set... you get an interrupt. In the ISR you can just add the 12.5ms constant and overwrite the OCx register. This will keep a continuous stream of TOCx interrupts.

OK, so that is my best explanation of the question I !think! you are asking. There is a much longer and more concise explanation in M68HC11RM/AD chapter 10. Just hope I didn't add confusion.

Now on 94-95code we have

; public OC4I
OC4I:
ldd     TOC4H           ; Output Compare 4 Register (High)
addd    #$99A
std     TOC4H           ; Output Compare 4 Register (High)
ldaa    #$10
staa    TFLG1           ; Timer Interrupt Flag Register 1
brset   byte_1 2 loc_3A1A

Yipes this is quite different. Are you sure the constant isn't #$999A. If not the interrupt rate is much different. YOu want to check the prescale value also.

If I get it correctly and there is not something else uncharted the OC4I is executed every 0.7813982ms.

Yes.

Now I have some other question related with interrupts.
On 94-95 code eside can communicate over the aldl bus. It has E4 ID and the communication is handled by the SCISS. It works great when the engine is not running and I can log some memory regions real time for better understanding of the code. Somehow when the engine is started eside stops communicating. It just doesn`t handle the requests. Do you have ideas what can stops the pcm from servicing the SCISS requests. I will really like to get that fixed if possible. At least on lower rpms there will be plenty enough time for the pcm to handle communication.

I just found this at the very start of IRQ

ldaa    #$10
clrb
std     word_16F4
ldaa    SCCR2           ; SCI Control Register
anda    #$F
staa    SCCR2           ; SCI Control Register
ldx     #$1803
bclr    0,x 4
ldaa    PORTD           ; Port D Data
anda    #$ED ; 'ý'
oraa    #$2C ; ','
staa    PORTD           ; Port D Data

Could it be somehow related with the stopped communication.

Yes.

ldaa SCCR2 ; SCI Control Register
anda #$F
staa SCCR2 ; SCI Control Register

This code clears the upper four bits which are all the interrupts related to character reception. IMHO GM has written it's code with great care. I find the work to be so much better than most. I would worry that other aldl operations that can take place when the engine is running would starve the cpu of it's bandwidth. Bad things might happen if the cpu can't complete it's task before the next set of interrupts fire. I have written code with nested interrupts before and if there isn't enough power to chug through all the code in the time needed, it often blows the stack and resets/crashes. Go with care on this. If you can, isolate the aldl from other modules that are not part of what you are doing. Fewer surprises

-Tom

[kur4o]

That explanation is awesome. Finally managed to figure some of the free flowing timers on both sides that were meaningless till now. The code flow also makes sense now.
The prescale is 16 on 94-95 code, which equals to 12.5ms.

Is it possible that tside runs on different frequency. I made some calculations but could`nt get it right. I might be missing something there. The engine run time counter there is known to increase each second but I managed to calculate a 0.8seconds increment. Which doesn`t look correct.

SO there isn`t any queued interrupts on hc11.

I found some code that re enables the SCSSI or set it to default on 5 second inactivity on the bus.

clr     byte_1886
bclr    byte_37 $42 ; 'B'
ldaa    #$26 ; '&'
staa    SCCR2           ; SCI Control Register
ldx     #$1803
bclr    0,x 4
sei
ldaa    PORTD           ; Port D Data
anda    #$ED ; 'ý'
oraa    #$2C ; ','
staa    PORTD           ; Port D Data
cli
ldd     #0
std     word_1882
std     word_1880

I might change the location of it to enable it on the beginning of the oc4i and keep the bus quiet on the irq execution. I also have to disable all the chatter on the bus to keep the processor happy. And keep it disabled on the higher rpms.

By looking of the size of the irq, can you estimate the time the processor needs to execute it.
Did you managed to crack the aldl and obd communication. Is the data written to external chip that manages the rest or the processor handles the timing and so on. I wonder how the scssi interrupt is invoked.

[Tom H]

Is it possible that tside runs on different frequency. I made some calculations but could`nt get it right. I might be missing something there. The engine run time counter there is known to increase each second but I managed to calculate a 0.8seconds increment. Which doesn`t look correct.

Possible yes but in my case the crystal frequency is the same on both. Eclock and so on just follow. Prescale can differ...

By looking of the size of the irq, can you estimate the time the processor needs to execute it.

Very possible. Doesn't IDA take a stab at that? If not, the time for each instruction is known and writing a disassembler isn't hard. In the disassembly, just add the instruction time. Loops are more difficult because the code won't recognize the structure of the c

Did you managed to crack the aldl and obd communication. Is the data written to external chip that manages the rest or the processor handles the timing and so on. I wonder how the scssi interrupt is invoked.

Yes&No. Early on I did some work on the aldl, but didn't know the meanings of what was being communicated. Moved my effort over to class2 where some of the output is documented in SAE docs. That allowed me to start to unravel more of the internal code. In the end, probably need to get back to the aldl. Depending on what components I put with the PCM modifications will be needed there to properly drive the other modules.


-Tom

[Tom H]

Chugging away at the TPU. Started by making a bootstrap file that correctly dumps the TPU content on demand. For now this is slow and somewhat static. I also have routines that make it easy to look for changes in each location. Using these very basic tools, I am creating a chart that details the association of TPU locations with the function. Giving a simple example, VATS uses 5 locations (16b) within the TPU map for it's function. Plan to gain as much of an understanding of the structure as possible before going to the next step.

Next step will be to move to a more dynamic set of tests. Trying to figure out the purpose of each of the component locations within each function.

A question that came up while working through this: TPU pin 23 would be connected to Red connector pin 26 if the components were stuffed. Can anyone tell me the use of Red pin 26 on whatever (B, Y, F or ?) car used this pin??

Thanks,
-Tom

[kur4o]

Pin A26[red] is not used, however I managed to trace it down to a frequency input channel. Not confirmed but it is wired internally, the same as pin A23.

There are like 6 input channels to the tpu that can decode frequency signal. There are also 4 different locations they are stored/ Maybe 1,2,3,4 cycles old for delta calculations. Here is how they are setup in 94-95 code

RESERVED:1444                 fdb 0                   ; ??some freq 1??
RESERVED:1446                 fdb 0                   ; ??TRACTION FREQ 1 ??
RESERVED:1448                 fdb 0                   ; ??PIN A26 freq 1 ??
RESERVED:144A word_144A:      fdb $74                 ; DATA XREF: IRQ:loc_52F7r
RESERVED:144A                                         ; IRQ+BFr ...
RESERVED:144A                                         ; MAF FREQ 1 raw
RESERVED:144C                 fdb $75                 ; ??VATS FREQ 1??
RESERVED:144E                 fdb 0                   ; ??some freq 1??
_________________
RESERVED:1464 word_1464:      fdb 0                   ; DATA XREF: sub_7CFE+107r
RESERVED:1464                                         ; sub_7CFE+10Br
RESERVED:1464                                         ; ??Some freq 2??
RESERVED:1466 word_1466:      fdb 0                   ; DATA XREF: sub_7CFE+10Er
RESERVED:1466                                         ; sub_7CFE+112r
RESERVED:1466                                         ; ??TRACTION FREQ 2??
RESERVED:1468 word_1468:      fdb 0                   ; DATA XREF: sub_7CFE+115r
RESERVED:1468                                         ; sub_7CFE+119r
RESERVED:1468                                         ; ??PIN A26 freq 2 ??
RESERVED:146A word_146A:      fdb $7F                 ; DATA XREF: IRQ+C5r
RESERVED:146A                                         ; IRQ+C9r ...
RESERVED:146A                                         ; MAF FREQ 2 RAW
RESERVED:146C word_146C:      fdb $7D                 ; DATA XREF: OC4I+14Br
RESERVED:146C                                         ; OC4I+14Fr ...
RESERVED:146C                                         ; vats freq 2 raw hard address
RESERVED:146E word_146E:      fdb 0                   ; DATA XREF: sub_7CFE+12Ar
RESERVED:146E                                         ; sub_7CFE+12Er
RESERVED:146E                                         ; ??Some freq 2??
_________________
RESERVED:1482 word_1482:      fdb 0                   ; DATA XREF: SPIEsub_6EF6+24r
RESERVED:1482                                         ; SPIEsub_6EF6+28r ...
RESERVED:1482                                         ; TTS (TS_word_23b) word_65
RESERVED:1482                                         ; RAW INPUT FROM VSS SENSOR 2
RESERVED:1484                 fdb 0                   ; ??some freq 3??
RESERVED:1486 word_1486:      fdb 0                   ; DATA XREF: OC4I+566r
RESERVED:1486                                         ; OC4I+56Ar
RESERVED:1486                                         ; TRACTION FREQ 3
RESERVED:1488                 fdb 0                   ; ??PIN A26 freq 3 ??
RESERVED:148A word_148A:      fdb $BF                 ; DATA XREF: IRQ+CFr
RESERVED:148A                                         ; IRQ+D3r ...
RESERVED:148A                                         ; MAF FREQ 3 RAW
RESERVED:148C                 fdb $2F                 ; ??VATS FREQ 3??
RESERVED:148E                 fdb 0                   ; ??some freq 3??
_______________________
RESERVED:14A4 word_14A4:      fdb 0                   ; DATA XREF: sub_7CFE+131r
RESERVED:14A4                                         ; sub_7CFE+135r
RESERVED:14A4                                         ; ??sOme freq 4??
RESERVED:14A6 word_14A6:      fdb 0                   ; DATA XREF: OC4I+55Fr
RESERVED:14A6                                         ; OC4I+563r ...
RESERVED:14A6                                         ; TRACTION FREQ 4
RESERVED:14A8 word_14A8:      fdb 0                   ; DATA XREF: sub_7CFE+13Fr
RESERVED:14A8                                         ; sub_7CFE+143r
RESERVED:14A8                                         ; ??PIN A26 freq 4 ??
RESERVED:14AA word_14AA:      fdb $C0                 ; DATA XREF: IRQ+D9r
RESERVED:14AA                                         ; IRQ+DDr ...
RESERVED:14AA                                         ; MAF FREQ 4 RAW
RESERVED:14AC word_14AC:      fdb $2F                 ; DATA XREF: sub_7CFE+14Dr
RESERVED:14AC                                         ; sub_7CFE+151r
RESERVED:14AC                                         ; ???VATS FREQ 4??
RESERVED:14AE word_14AE:      fdb 0                   ; DATA XREF: sub_7CFE+154r
RESERVED:14AE                                         ; sub_7CFE+158r
RESERVED:14AE                                         ; ??Some freq 4 ??

I believe the labelled vss sensors uses pin A1 and pin A32. A1 is not used on 94-95 applications, but on 96-97 there is a crank position sensor wired there.