A short section of code for a couple of filter subroutines...
A short section of code for a couple of filter subroutines...
Getting to fully understand this is hard without stepping through the code in debugger and monitor how values change. The idea is to get the final value and what it does.
I looked at EOIT filtering and maf filtering long time ago. Never could fully understood it unless I monitor real time values from memory.
The idea is first to smooth peaks or slowly increase/decrease new value for example
you have
value1 = 100
new value1= 150
scalar for filtering=10
output value=XX
When valu1 and output value equals than there is no filtering.
when newvalue1 arrives in filter routine the output value don`t get changed immediately, It changes for example in steps of 10 over time so you get smooth output
example
old value=100
new value=200
output value1 = 110 next cycle 120, next cycle 130 and so on until they equal.
With maf filtering is something similar however the values are signed so you have positive and negative correction. going 2 directions
Steveo, Kur40,
Thank you for your insight. I did work hard at this, just still a little unsure. The difference between the two entries is basically one instruction: BLT vs BCC. Those differentiate/branch the code for +ve and -ve. I guess I will write some code and test out the routines. All this just eats time.
-Tom
Last edited by Tom H; 02-06-2023 at 12:10 AM.
The branch you are seeing could be for
case1 new input value -higher than previous
case2 new input value -lower than previous
So it can filter in both direction. I think the code is just for smoothing peaks or rapid changes. So you don`t get erratic signal, jumping back and forth.
I will compare the code with 94 code eoit smoothing, it may be the same or very similar.
Ok Tom I found the code in 94 bin, but it is not referenced at all, just sits there as a code that is not used.
However the code looked familiar and indeed the maf smoothing routine uses the sequence[unsigned].
Static analysis will not help you. I managed to figure what it does, only when logged real values from ram.
The idea is to smooth rapid erratic changes of maf output on high deviations. When you stomp it for example. It uses a maf pumpshot scalar to smooth output for different conditions.
Looking at logs it does that ,old maf = new maf over time updated in increments based onscalar.
so if maf jump from 50g/s to 200 g/s code doesn`t jump that much it smooth the jump over several cycles to 50-70-100-150-200 for example.
Finally getting back to the knock system and it's relation to the TPU. Switching away from the "tools" thread for these posts. The VSS system had both tools and system info and caused me to place it there. Reading back it might have been better here but what's done is done. Once again, a good deal of this post is probably common knowledge but I thought to write up what I have done. It exposes more of the internal workings of TPU
(Circa 1997) which is key to understanding this PCM.
-----------
Already discussed are details of the knock module and it's interface to one or two contact microphones (knock sensors). The knock module takes these input(s) and generates a knock signal based on the envelope of the engine vibrations. The knock module output is a 10V signal which is driven to a low state when knock is present. The voltage divider (R145, R146) default this signal to the active knock detected state if the module is not installed.
The knock signal is transferred to the ESide of the PCM over the ribbon cable on pin 16. Anyone following this needs to take care because the ribbon is not well marked as to where pin 1 is. I have posted PDFs (somewhere in this thread) that allow you to follow my take on the position of pins as well as resistor/capacitor/IC numbers and reference designators.
For my bench testing I have connected an OPTI_SIM to the OPTI_SPARK inputs. This bit of hardware is used to generate all the opti signals. This permits me to "run" the PCM at any RPM I wish for as long as I want without waking neighbors. For my first tests I set it running at 3000 rpm. This gives me a good trigger for my scope while I generate knock events. The revised software for the opti-sim permits me to generate a knock signal at any crank/cam angle and to control it's width.
The first test I did was to determine if the LT1 featured a knock window design. To my surprise, I found it does not. I generated knock signals every 10 degrees from 0 to 90 and found that the TPM counted knock events in every case. This suggests that the knock system is not very sophisticated. Nothing like some of the GM patents I have been reading through.
The circuit is simple enough although quite hard to follow. In the end the knock signal connects to the TPU on pin 2. The TPU input is probably multiply sampled to prevent metastability issues. Sampling is done in this way because the input is generated from analog and has no time relationship with EClock. A single sample will hit the metastability window every now and again. When the window is hit the input will toggle for a while before settling. This event would create incorrect knock counts. Once conditioned, the input can be reliably sampled using CPU EClock divided by 48. If I produce pulses at the TPU of something just over 15uS the TPU increments it's knock count by 1.
The knock count is an incrementing 16 bit count[Correction --> 15 bit]. I plan to look into how overflow is handled and other details in the next post. The TPU address of the knock count is $1460. This address is latched by the first 8bit read and the count is provided by the next two read operations. In the code sequence looks like this
sei ; Disable interrupts because the operations must be done together
ldaa $1460 ; Read latches the word
ldd $1460 ; Address 0 not used, both read from $1460 but transfer the 16 bit word [Correction 15 bit]
[Correction start
lsrd ; Shift right 1 bit
Correction end]
cli ; Re-enable interrupts
A couple of things stood out to me:
- Knock count system is quite simple in the way it is done.
- It has a lot in common with the way VSS and even VATs is done.
From here I will go through the software to understand how the count is used. Probably post the findings.
-Tom
I put some fundamental fixes in this text & marked them. Looks like the lsb of the word provided by TPU is invalid. I will try to find out why this was done...
Last edited by Tom H; 07-07-2023 at 01:45 PM.
Hi,
Working through the knock system and how the knock count is used by software...
To determine if/how much knock was present the CPU keeps track of each read of the TPU. Each time it reads a new value the difference between the previous and current value is the knock count for the cycle. At power up the CPU initializes that previous value so that it can be depended on when the first interrupt fires.
Before getting into the operational side of knock count, the design is set such that if the knock module on the TSide is missing, the input is a continuous knock detected. P0325 will set if knock is present for a second or so. I guess this might lead to a false diagnostic but if the engine is making enough noise to trigger the knock system --> you probably have much greater problems that don't require the PCM to find.
The real use of the knock count is in the setup of spark advance. I have traced a good number of these paths but the overall design isn't yet clear to me. I will keep working through the TPU interrupts to gain a better understanding of this. If ever I understand it all, I will post it.
In my earlier post, there was/is some confusion regarding the number of bits the knock count contains. The ESide software uses 15 bits only. Each time the count is taken from the TPU the count is shifted right. I believe this is intended to reject knock detection that is under 30uS wide. The full 16bit count is transferred to the TSide and both ALDL and class II diagnostic schemes indicate all 16 bits. I have tested and found that I can generate knock pulses of 15uS and see them reported while the ESide rejects them. Interesting, but not of much use.
The 16 bit knock count is transferred from ESide to TSide over the SPI bus. Bytes $09 and $0A of each frame contain the 16bit count as generated by the TPU. In debugging a false knock problem, this count could be of use. There are a great number of things to look for but here are a few suggestions.
- Running the engine with no load the count should not increase. An increasing count indicates that false knock is present.
- Running the engine under load the count will properly increase where knock is present. Should count increase values of one (a single count) be found, this indicates the system has noticed a
very short duration knock and rejected it as false. This suggests that metal to metal contact has happened somewhere and needs to be eliminated. Finding the source of false knock could be
quite difficult. Everything matters here from a loose bolt, motor mounts, exhaust heat shields and so much more.
The value of knock count can be found with PID 125E using the standard mode $22 request.
In my case: 4C 10 F0 22 12 5E 01 <CRC>
The knock count is also sent over ALDL. Without taking too much time re-tracing all the ALDL scheduled messages, the note I have in the disassembly is: ALDL ID: $F4, MODE: $01, SUBMODE $00 it should be contained in bytes 53 and 54 ($35 and $36) of the message. To take this reading over ALDL, I sent the message: F4 57 01 00 B4 where the last digit pair is checksum. In doing this the PCM responded:
F4 91 01
00 62 00 00 00 00 00 00
00 00 00 00 00 00 80 02
00 FF FF 00 FF 02 76 04
00 28 02 01 03 3F 88 01
67 65 67 65 00 80 80 80
80 00 00 00 00 00 00 00
65 20 00 00 7A 20 00 80
00 00 00
F0
In the above $7A20 is the expected count. To make any use of the count, it needs to be sampled two times and subtracted to find if the count is going up.
In any case, TSide doesn't make use of knock count at all and only takes a copy to provide test & diagnostic information.
-Tom
EDIT: I missed a part of the code where the knock count is divided by two before sending it over to the TSide. This changes some of the above, I now believe the count is 15 bit everywhere. This excludes some of the suggestions I made regarding single counts. Actually difficult to get at the lsb of the tpu count to find out why it is there. Wonder if it is used as a flag for overflow ??
Last edited by Tom H; 07-10-2023 at 01:15 PM.
Before getting on to the ignition timing and knock retard I find that a greater knowledge of the basic TPU workings is needed.
Can anyone explain how the TPU syncs up to the motor? I have found that the TPU register at $1432 keeps track of the number of degrees since the last low res pulse. The OPTI has four slots that are one highres pulse wide and four other slots that are 6, 11, 16 and 21 wide. This results in a number that can be used to uniquely identify four cylinders. I assume that it may take 180 degrees rotation before sync with the engine can be achieved.
Should there be info out there, it would save a bunch of time... the interrupt service is going to be difficult for me to completely figure out with not much to go on.
-Tom
Tpu feeds eside with low res reference minor loop[Time based scalar that pcm converts to rpm], There is also high res count that is degree based[0-720]Each slot is counted falling and rising edge to get the count.
With that info pcm calculates cylID.[code is at the very start of IRQ vector].
To sync up there is max 2 cylinder rotation needed. Based on the extremely fast cranking time. pcm also provides some advance and retard data and EOIT target and Dwell time to tpu and there, the black magic happens, some internal loops in the tpu that are still unclear.
There must be at least2-3 running counters for high res counts.
To get minor loop, the tpu counts time between 2 low res events and output data to eside. [formula is ???/scalar] ??? differs between eside and tside by 1/3.[Different interrupt clock??]
Also the engine can run only on low res signal, but it runs like crap.
To get cylID I think pcm counts the high res pulses between low res open slots. There is ram scalar that represent cyl id. Count is also non constant, there might be some slight +-3-5 degrees. 87 is the odd equal lenght opti cylinders, 77 67 57 47 represent the even variable length slot on opti signal. When you monitor those you can see how good is the opti signal, since they vary +- 3-5 and if outside range pcm sets a low res DTC.
Last edited by kur4o; 07-22-2023 at 08:23 AM.
Thank you once again Kur4o for your insight!
I believe that the TPU address $1432 is the high res count you speak of. Is it the same in your earlier code? (my hope is that there was no change to this)
I believe that the TPU address $15CC is the time between low res pulses. The TPU takes the processor ECLK (3.15MHZ or so) and further divides it by 48. The resulting clock is a nice binary number: 2^16 or 65536 HZ. This is the clock used to measure time between high res which then is turned into rpm.
In my code, there are four separate services for TPU interrupt. Not all the details are worked out yet unless you can explain the function. I refer to them by the hex code returned from what must be the interrupt source register ($16F4 ?same for you?). So, I named the interrupts type $0400, $0800, $1000 and $2000. My code has all the OBDII stuff and might have increased complexity in the service. The service starts by capturing a bunch of info about when the service started and so on. This must have been used by GM engineering to keep track of the real time used in servicing interrupts, stack needs and other.
Code then heads into the "real" part of the service. TPU address $1482 is similar to the $1432 except that '32 is cumulative where as $1482 is updated each low res with the count since the previous. With engine speed from the $1482 code first checks for over-rev.
Interested to know just how different the earlier $EE code is?
Just digesting the rest of your post, again thanks. -Tom
The earlier code is almost the same, at least for eside. I have compared the IRQ and it is identical. The only difference is the VE and MAF calculation. on later code both are run and than at the end pcm decides which value to use. Or some blend of both.Since there is no time at higher rpms some code is not updated every cycle.
Irq is triggered every low res pulse on eside[so code is not run without low res pulse being sensed.. I just remembered that tside have special interrupt for low res and calculates the low res time by its own, while tside gets it from tpu.
Tside is much different by the extra obd2 crap being added. I don`t think trans code has much changes.
Tpu while being the same function have updated registers locations and code, so some internal changes can be expected.
Apologies for interrupting, but does this mean that on the earlier Eside, the VE and MAF do not both run? I was under the impression that "both run and some blend of both is used" was true for all of these PCMs, not just the 96-97 OBD2.Originally Posted by kur4o
As for the Tside differences, what about '97 versus the '1333? The 'Vette had some early OBD2 implementation stuff that wasn't present in the '8051, so I'm curious if those changes were carried forward to the '97, or if the '97 is totally different in that respect.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
NomakeWan: I just can't contrast the difference, still trying to get my head around the one version.
kur4o: I believe the TPU has four sources of interrupt. The one you describe I have labeled as type$1000. Do you see code similar to the following at the start of your TPU ISR??
I re-wrote the ISRs to help me with debug... each can output a pulse such that I can trigger my scope. The TYPE$1000 service is for the rising edge of low res. I believe (not checked yet) that the TYPE$0800 fires when the spark is sent. Probably checks to see the pin toggled and not shorted or such. Last two interrupts are ?? along with the sperious interrupt that just returns.Code:************************************************* * IRQ SERVICE: TPU SOURCED INTERRUPT ************************************************* IRQ_TPU: ldd CPU_TCNTH ; TCNT: READ TIMER COUNT std TPU_IS_S_TIME ; TPU INTERRUPT SERVICE START TIME bset <byte_0000 $02 ; IRQ VECTOR ACTIVE FLAG ldaa word_16F4 ; TPU INTERRUPT STATUS REGISTER ldd word_16F4 ; FOUR ACTIVE BITS: $3C00 bita #$10 ; TYPE $1000: LOW RES RISING EDGE bne TYPE1000 bita #$20 ; TYPE $2000 bne TYPE2000 bita #$04 ; TYPE $0400 beq loc_68AA jmp TYPE0400 ; CYLINDER FIRING EVENT INTERRUPT loc_68AA: bita #$08 ; TYPE $0800 beq loc_68B1 jmp TYPE0800 loc_68B1: bset <byte_0045 $40 ; SPERIOUS IRQ INTERRUPT jmp TPUIRQ_COMPLETE
Any knowledge about the other sources of interrupt?
-Tom
[edit] bunch o bad typo's fixed...
Last edited by Tom H; 07-23-2023 at 01:14 PM.
How does the low res rising edge relate to TDC of that cylinder? My guess is that they align(?)
It looks to me like each of the rising edges of low res indicate TDC of one of the cylinders. I have not yet confirmed/matched up the low res slot width with the cylinder. There are quite a few things to work out just to get there.
[
To the tuners here: How important is the accuracy of the low res pulse relative to the actual engine position? It seems to me this would be critical. Is there a calibration to offset the inputs if the distributor is not in *perfect* time with the engine? Answers here are a great help because they let me guess about what I see in the code.
]
I have isolated each of the four TPU interrupts and placed scope triggers in each routine. This lets me look in detail at what the service is trying to accomplish. I know each of the software builds is different in the code loaded into the TPU. This affects some (all?) of the register assignments. I am working through the register set to identify the purpose and how it is configured. What follows is for the '97 code but not all address assignments will have changed from earlier code.
Register $15D8 in the TPU is the latched high resolution count as at the last low resolution rising edge. Since this is a 4stroke V8, this count should always be 90 with a good opti-sparker. In my case I am simulating the optispark, so the math works perfectly. This register is used for diagnostics and to set spark timing. The register is used with register $16C2 to diagnose a dead low resolution signal. The test however is quite crude. It doesn't look for the 90 degrees that it should always be. The need for not having false triggers of SES had the designers looking for two revolutions of the engine without seeing a low res. The engine will still work fine unless some upset happens where the PCM goes out of sync with the engine. This could easily happen on startup or other events.
Think your opti might be on the way out? Wondering about the quality of the opti you just installed? Looking at location $0245, perhaps logging it for a bit while going through the gears will tell you about the stability of the opti. If you see a constant 90 ($005A) this indicates things are in good order. See a higher number from time to time? That would be a bit of a head scratcher... perhaps indicates dirt on one of the low res windows. Lower number indicates missing high res pulses. This could result from dirt on a high res window but more likely the optical module is on the way out.
This is how far I got, will keep plugging at it.
Here is a snip of code for your interest:
Code:* OPTISPARK TEST * P1371 DISTRIBUTOR IGNITION LOW RESOLUTION CIRCUIT loc_6008: ldaa byte_203E ; DTC TEST ENABLE: CALIBRATION: $3F bita #$08 ; P1371 DISTRIBUTOR IGNITION LOW RESOLUTION CIRCUIT beq loc_6063 ; TEST DISABLED sei ; DISABLE INTERRUPTS ldaa word_15D8 ; HIRES COUNT AT LAST LOW RESOLUTION RISING EDGE ldx word_15D8 ; READ REGISTER pshx ; PUSH COUNT ON STACK ldaa word_16C2 ; UNLATCHED HIGH RESOLUTION PULSE COUNT ldd word_16C2 ; READ REGISTER cli ; ENABLE INTERRUPTS tsx ; POINTER TO LATCHED COUNT subd $00,x ; DIFFERENCE: CURRENT COUNT LESS LAST LOW RES COUNT pulx std word_0245 ; HIGH RES COUNTS SINCE LAST LO RES RISING EDGE ldaa byte_0248 ; P1371 CLEAR DTC COUNT adda #$01 ; INCREMENT sbca #$00 ; PREVENT OVERFLOW staa byte_0248 ; UPDATE ldd word_0245 ; HIGH RES COUNTS SINCE LAST LO RES RISING EDGE cpd word_204B ; CALIBRATION: $02D0, 720, P1371 FAILURE THRESHOLD bls loc_604F ; TWO REVOLUTION NOT PAST SINCE LAST LO RES RISING ldaa byte_0247 ; P1371 SET FAULT COUNT adda #$01 ; INCREMENT sbca #$00 ; PREVENT OVERFLOW staa byte_0247 ; UPDATE cmpa byte_204D ; P1371 SET DTC THRESHOLD bls loc_604F ; BELOW DTC THRESHOLD bset <byte_0062 $01 ; SET P1371: DISTRIBUTOR LOW RES CIRCUIT FLAG bclr <byte_0062 $02 ; CLEAR P1371: DISTRIBUTOR LOW RES CIRCUIT FLAG bra loc_605D loc_604F: ldaa byte_0248 ; P1371 CLEAR DTC COUNT cmpa byte_204E ; P1371 CLEAR DTC THRESHOLD bls loc_6063 ; BELOW DTC THRESHOLD bset <byte_0062 $02 ; CLEAR P1371: DISTRIBUTOR LOW RES CIRCUIT FLAG bclr <byte_0062 $01 ; SET P1371: DISTRIBUTOR LOW RES CIRCUIT FLAG loc_605D: clr byte_0248 ; P1371 CLEAR DTC COUNT clr byte_0247 ; P1371 SET DTC COUNT loc_6063: jmp loc_6311
Posting Permissions
Reply With Quote
Bookmarks