1997 F-Body ECM

[Tom H]

I think that STY clear memory from 1400-15ff. It looks like it copies the value from 1400 and stores it[ $100 cycles word ] from 1400-15ff. 1400 looks like one of the injectors bpw so at reset should be cleared.

I think 16f0 needs more examination to figure what is going on at the hardware level. I am sure that 0003 sets some pin high or low on the ram chip, and some switching happens there. We have the microcode but no clue of the op codes it uses. Cracking the instruction set will open the door. Did you managed to define the memory range accessible to eside. I think that writing to the shared memory is a function of internal switching in the RAM chip. That extended ram chip might do more than we thought.

I posted yesterday but somehow it got lost. It's OK though because part of what I wrote was because of a programming error. I will try to re-write it but corrected.

The STY instruction stores content of IY register at the address IY points to. You would expect:

$1400 14 00 14 02 14 04 14 06
$1408 ....
.
.
.
$15F8 15 F8 15 FA 15 FC 15 FE

My thinking is that the upper byte is discarded and the lower byte used as a portion of the internal microstore address.

I have been working on the $16F0 register. I have been able to change it, change it back and have the part work. I tried writing to the microstore, but see no change in operation. This tells me that something (another register) is involved. I plan to work through that this morning.

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

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

[In-Tech]

BTJT(bit test jump true, can't remember the opcode) can be your friend. I am not involved with your project but occasionally listen in. :)

[Tom H]

Hi In-Tech -Carl, hope you are enjoying the v e r y s l o w progress.

I came back to coding half an hour ago and found the missing interrupt enable bit. The register at $1496 contains 5 active bits (that I know about). Where X is idontknow and 1 is a bit used in the code that I know about...

$1496 : $1479 --> XX11 XXXX : XXXX 111X

EDIT
ACCA Bit 4 (bit 12 of ACCD)is the interrupt enable for the HC11. This is driven by the TPU and has several different functions. The enable bit I describe may (not yet determined) only enable one of the functions.
EDIT

Register at $16F4 is used to clear interrupts active bits I know about are
$16F4 : $16F5 --> XX11 11XX : XXXX XXXX

Some small progress today

-Tom

[Tom H]

Bootstrap code is responding to interrupts from the TPU. Makes the job of discovering registers just a bit easier. Another problem has come up though, I am getting watchdog hits. Some problem in my code. Probably somewhere in a display routine because 1888 baud is just so slow. Takes 32ms just to display an address. I probably need to reset comms a bit faster or just find my bug.

-Tom

[kur4o]

This will reset cop. You will need to loop through it every xx ms to keep COP alive.
ldab    #$55 ; 'U'
stab    COPRST          ; Arm_Reset COP Timer Circuitry
ldab    #$AA ; 'ê'
stab    COPRST          ; Arm_Reset COP Timer Circuitry

Might be also cop related
sei
ldab    #$50 ; 'P'
stab    byte_1806
ldab    #$A0 ; 'à'
nop
nop
stab    byte_1806
cli

Here is the usage for 16f4 on 94-95 code. Might give you some clues.

RESERVED:16F4 word_16F4:      fdb 0                   ; DATA XREF: __RESET-45F2w
RESERVED:16F4                                         ; OC4I+2BEw ...
RESERVED:16F4                                         ; #1800 loaded at reset and oc4i
RESERVED:16F4                                         ; #0004 at sol_sub
RESERVED:16F4                                         ; #1000 at irq
RESERVED:16F4                                         ; #800  at irq once at cranking
RESERVED:16F4                                         ; #0002 at irq

[In-Tech]

Hiya Tom and others following along as I am. In another life I had to monitor a bit and send its life to "my code" as it could change as many times as 8 times a second. Pretty cool compared to static code :)
Btw, I am enjoying what you are doing.
-Carl

[Tom H]

This will reset cop. You will need to loop through it every xx ms to keep COP alive.
ldab    #$55 ; 'U'
stab    COPRST          ; Arm_Reset COP Timer Circuitry
ldab    #$AA ; 'ê'
stab    COPRST          ; Arm_Reset COP Timer Circuitry

Might be also cop related
sei
ldab    #$50 ; 'P'
stab    byte_1806
ldab    #$A0 ; 'à'
nop
nop
stab    byte_1806
cli

Here is the usage for 16f4 on 94-95 code. Might give you some clues.

RESERVED:16F4 word_16F4:      fdb 0                   ; DATA XREF: __RESET-45F2w
RESERVED:16F4                                         ; OC4I+2BEw ...
RESERVED:16F4                                         ; #1800 loaded at reset and oc4i
RESERVED:16F4                                         ; #0004 at sol_sub
RESERVED:16F4                                         ; #1000 at irq
RESERVED:16F4                                         ; #800  at irq once at cranking
RESERVED:16F4                                         ; #0002 at irq

Hi,
Thanks for your post. I do have both watchdog timers covered in the code. I think perhaps I did not account for some time and am letting the timer expire. Other possibility is that I did not set up the chip select to the $1800 range correctly. In bootstrap the $1800 range doesn't exist until you initialize it. I have a few minutes now and will scout through it all.

Good data re the $16F4 range in the earlier build. Given this, there were structural changes between builds. Not just a tidy up.

Here is a snip o code:

*************************************************
* IRQ SERVICE: SOURCE IS TPU
*************************************************
688C  FC 10 0E    	LDD    $100E		; TCNT: READ TIMER COUNT
688F  FD 02 F4    	STD    $02F4		; IRQ SERVICE TIME

6892  14 00 02    	BSET   @$00,$02		; VECTOR ACTIVE FLAGS

6895  B6 16 F4    	LDAA   $16F4		; TPU INTERRUPT STATUS REGISTER
6898  FC 16 F4    	LDD    $16F4		; FOUR BITS, $3C00 ARE ACTIVE

689B  85 10       	BITA   #$10		; 
689D  26 18       	BNE    $68B7		; 

689F  85 20       	BITA   #$20		; 
68A1  26 46       	BNE    $68E9		; 

68A3  85 04       	BITA   #$04		; 
68A5  27 03       	BEQ    $68AA		; 
68A7  7E 68 19    	JMP    $6819		; CYLINDER FIRING EVENT INTERRUPT

68AA  85 08       	BITA   #$08		; 
68AC  27 03       	BEQ    $68B1		; 
68AE  7E 68 85    	JMP    $6885		; 

68B1  14 45 40    	BSET   @$45,$40		; SPERIOUS INTERRUPT
68B4  7E 89 17    	JMP    $8917		;

-Tom

[kur4o]

bset    byte_0 $80 ; 'À
lds     #$1FFF
ldaa    #1
staa    INIT            ; RAM and I_O Mapping Register
ldaa    #$99 ; 'Ù'
staa    OPTION          ; System Configuration Options
ldaa    #0
staa    TMSK2           ; Timer Interrupt Mask Register 2

I guess some of the lines in this code is responsible for the extended ram config. It is the first thing to do after a reset.

I also noticed some differences with the 16f4 on 96-97. There are some error set

bset byte_48 4
bset byte_62 4
bclr byte_62 8

if the interrupts are not configured properly. I will have to trace them.