1997 F-Body ECM

[sherlock9c1]

That first group of terms (including the compressor and low-cut filter) is pretty standard audio theory which you can find on any modern sound board.

As to your resonant frequency discussion - I would think that it's the ringing of the components you'd be most worried about, particularly the crankshaft. I doubt the piston would ring at all; perhaps the rod, but it'd be more likely to ring laterally than longitudinally? (I'm guessing here). The crankshaft is the part most likely to deflect and resonate because of a sudden impact. Any resonance inside the combustion chamber would be at the speed of sound, resulting in an extremely high frequency with such small dimensions and low mass (of the air).

BTW I appreciate your thoughts towards changing resonance. I went down the same road over the past year preparing a forged stroker motor and finally decided to modify a Fluidampr to fit my B-body setup, since it is an effective multi-band damper. The stock elastomeric damper is a single-frequency damper; ATI is also single frequency but it is tunable (by ATI), though I don't know how one would get data back to ATI. So... I waited for a long-discontinued LT1 Fluidampr to show up on Ebay and then modified it and my accessory drive to work on my application.

[dzidaV8]

For knock filter theory, perhaps this document from 1995 can shed some light?

EDIT: I've also discovered most of the meanings behind the spreadsheet I had posted earlier in the thread: http://www.gearhead-efi.com/Fuel-Inj...ll=1#post85161

I found a Delphi patent for a programmable knock filter here: https://patentimages.storage.googlea.../US5594649.pdf

The phrasing in this patent document perfectly jives with the spreadsheet. As such, the descriptions and units are as follows:

SBST = Software-based Self-test? Internal GM test routine?

FIRST STAGE (Bandpass Filter)
FREQ = Frequency (kHz)
GAIN = Gain (multiplier)
Q = Q Factor

COMP GAIN = Compressor Gain (ratio of input power to output power beyond threshold)

LPCF = Low-pass Filter Cutoff Frequency (Hz)

NOISE CHANNEL
GAIN = Gain (multiplier)
OFFSET = DC Offset Voltage (mV)
ITC = Increasing Time Constant (ms)
DTC = Decreasing Time Constant (ms)
IGN = ???
AOT = ???

ID RES K Ohms = Resistance value used to ID filter on ID pin (kOhms)

This patent and PDF are very interesting. I'm pretty sure the TI PDF explains a system that is used in LS1 type PCMs, as knock filtering parameters are set there by software. LT1 will still have what that paper describes as simple strategy, without any DFT/FFT.

[Tom H]

Some more work completed on knock sensor that I will bring up later...
Discussions on test beds came up and I hooked mine up. I have control of the engine speed the PCM sees so I set it quite low (250RPM). I then set the MAF frequency quite high. I set it high because the LEDs I use to visualize the injector pulses are set up to be normally on and off when the injectors are to be energized. When I turn on the ignition, I see the fuel pump turn on (so my 50hz vats signal is ok) and the injectors firing in sequence along with the ignition control. --> so far so good.
Over the next while I plan to simulate the analog input signals (ECT, IAT, Throttle, MAP and so on). My intent is to understand the interrupt structure of the TPU.

Here are the results of the MAF input frequency vs. air flow reported by the PCM. I used OBDII mode $22 parameter 10 to read the MAF result and my test bench to generate the frequency.

FvsAFlow.jpg

-Tom

[kur4o]

That is some great progress on the pcm simulation. Too bad I don`t have much time to play with it right now.

One thing that has bothered me is injector behaviour on startup. On first pulse, second pulse[ batch or sequential] matched with low pulse res signal. Does it have some synchronization for the first spark output event, measured with low res pulses.

Simulating ECT, IAT, Throttle, MAP with some variable resistors is easy. Not perfect but will do the job done. Or some knob with predefined resistor values, for faster changes.

I do plan to get some arduino board. Can you point me to the right direction on some cheap china crap ones that will do the job done.

[Tom H]

One thing that has bothered me is injector behaviour on startup. On first pulse, second pulse[ batch or sequential] matched with low
pulse res signal. Does it have some synchronization for the first spark output event, measured with low res pulses.

Simulating ECT, IAT, Throttle, MAP with some variable resistors is easy. Not perfect but will do the job done. Or some knob with predefined resistor values, for faster changes.

I do plan to get some arduino board. Can you point me to the right direction on some cheap china crap ones that will do the job done.

I plan to look at the startup. I almost have the synchronization between PCM and engine figured, but as always there are just a few things...
I think (TBConfirmed) that the initial pulses are batch. I need to find this in the code though because I don't have a storage scope. Perhaps if I
slow the Optisim down to just a few RPM I can see the event with the LEDs.

To now I have used resistors to provide analog input. Analog done by a micro has just one advantage for me, I can control two inputs at once.
To simulate an acceleration, hitting the throttle changes one analog. The result of this should be a drop in the MAP analog.
Would be nice to work through the O2 sensors this way also. Another COVID make work project?

For Adruino, I just shopped the easy way: Amazon. The second link is the one I got...
https://www.amazon.ca/Board-Controll...3301609&sr=8-6
https://www.amazon.ca/WYPH-ATmega328...%2C392&sr=8-10
Note that these are Canadian amazon listings. U.S. likely has better for less.

All the boards from my order worked, the compiler is easy to learn and the results can be tested in just minutes. I will retire most of my test boards, just don't need them now. Programming in a C++ IDE makes doing any small project a snap.
Thank you for mentioning it to me!

-Tom

[kur4o]

Thanks for the link. I will search by the pic for something similar locally.

If you can slow down rpm and check inj and spark firing will be great. I am really interested on which low res pulse the est fires the coil and injectors start pulsing.

[Tom H]

If you can slow down rpm and check inj and spark firing will be great. I am really interested on which low res pulse the est fires the coil and injectors start pulsing.

Tried a few things this morning. I am running into trouble turning on/off the ignition. So a few questions about the PMIC:

I know that when the PCM wants to enter a low power state it does so using the reset line. Reset causes the PCM to enter standby. When the PCM wakes from standby (ignition turned on) it checks tags in both internal ram and external ram. If tags invalid it cold resets and starts. case where tags are valid it skips into the warm reset.

Could someone with a bench setup check for me the voltage on the ignition positive before the PCM is turned on? I do not see mine turning off and wonder if some load is needed?

-Tom

[Tom H]

I do not see mine turning off and wonder if some load is needed?

Don't think it's load that is needed. Once it's turned off, software controls entry into standby. More of a look needed here as well.

I continued looking at the startup but not from "key on". I just kept cycling between engine stopped and 100RPM. When I move the optisim to 100rpm I see two batch (all injectors on) pulses. Then the sequential pattern starts. My test equipment just doesn't cut it for this work though. I think the batch mode begins on the first lo res. Once again I would like to see what the spark does. On would expect that because spark is directed to the correct cylinder by a mechanical rotor/cap that time with the engine is not a factor. Thinking about the opti wheel, it will take up to two low res pulses before synchronization between PCM and engine takes place. I believe this is why there are two batch fires. -Your thoughts??

-Tom

[kur4o]

The 2 batch fire events are likely the first and second prime pulse widths. The are calculated by fuel mass needed to soak the cylinders with fuel. I looked at the code and on first and second low res pulse the inj are triggered by special crank fuel tables], after that it uses fuel based on airflow[ sequential, based on your observation. For spark, the est line goes low and high, charging and firing the coil[high time=charge the coil, low=fire the coil]. It will beneficial to know the relation between est pulsing and low res pulse number at crank. There might be some syncro needed for tpu to get the pattern.

[Tom H]

I have also found code relating to prime pulses. Can you tell me if there is a flag bit that selects between batch fire and sequential? Interesting to find this/not sure if your address&bit would be the same as the later PCM.

-Tom

[kur4o]

It is a function of tpu to select batch vs sequential. There might be some flags that are set but are not figured yet.
Usually some one time bits are set at first and second prime than the pcm runs all code. I will look again at the code, might find something now that it is confirmed there is 2 batch fire. So all 8 fires at the same time or they are 4 by 4 fired.

[Tom H]

So all 8 fires at the same time or they are 4 by 4 fired.

The test I did...
- Power PCM
- Apply no pulses
then
- Apply 100RPM pulses

I have injector lines hooked to 1K2 ohm resistors to my input 12v. There is an led ground to injector on each. LEDs are lit when injector is off. Observation by eye only is all eight go off twice, then begin to sequentially blink in the firing order. I have arranged the LEDs on a perf board in the fire order so you can see the pulse ripple one to the next.

Short answer is for what I have, batch is for all eight.

Now to speculation. I think the TPU is set up with a 0 thru 719 count representing the position of the engine. It takes one or two low res pulses to establish synchronization with the engine. This is because every second pulse low res pulse is made with the small window in the opti wheel. If the first is the short pulse, the second will establish position. Since it is possible that the engine stops just at the last bit of a longer pulse, that could be mistaken for a short pulse. I see a recovery for this in software.

[Tom H]

Had a look at the TPU interrupt structure. It's complexity in terms of getting me to understand it is that it's hard to figure out what the source of the interrupt is. I needed to understand all the code before working back to understand the source.

The PCM keeps a great number of statistics that are no part of diagnostics. The number of interrupts of a given type and the time spent servicing them are all monitored. These statistics are available to the code that supports the GM test set only (or if you do some custom work).

All TPU interrupt services start by logging the start time which is based on the 'HC11 internal count. CPU then reads the TPU register at $16F4 to determine which interrupt fired.

My interest today is in the interrupt that returns $0400. This interrupt is generated each time the ignition control (IC) output returns to high. This is when the spark is generated and when the CPU tests the level of ignition control.

Service for the "400" interrupt begins by acknowledging the interrupt (the int pin will go inactive if no other interrupt sources exist). The code then runs the internal A/D on CH7. This is an un-scaled measurement of the IC pin. The test is with 4.5V... if IC has gone to/above 4.5V, all is well. Otherwise a fault of P1351 is counted.

I would be interested to see if the earlier LT1s have a similar test. If you could find it... here is how:

1) Find the ESide vector at $FFF2. My ISR is at $688C...yours will likely be different in the earlier s/w.

2) At the ISR, a few instructions in, you will see a read from $16F4. The result will be tested a few times and at some point test ACCA for #$04. The jump that follows if this bit is set is to the isr for 400.

3) The ISR starts by clearing the interrupt with a write to $16F4

If you have a look for this, let me know what you find.

-Tom

[Tom H]

In order to gain a better understanding of the ALDL communications built into the 1997 LT1 PCM, I needed to go right through the code. Not sure that I am much the better for understanding it as the usage is very limited. I will post what I understand to save others some time time.

The ALDL communication system in this PCM is based on a hardware based NRZ serial port. Motorola 68HC11 documentation refers to this port as Serial Communications Interface (SCI). ALDL drives TTL levels using a driver chip that buffers the output and has a drive enable. The drive enable is connected to the Port Replacement Unit (PRU) port B, bit6. The SCI is a full duplex device. The PCM uses the SCI as half duplex by only enabling the transmit or receive at a given time.

(For this next bit, look at the ISR_Vector.txt file)
Software drives this port using three interrupts, one for receive and two for transmit. The routines for driving the port are all in bank 0. The vector for the SCI interrupts must be in the range of memory available to both banks of FLASH: range $0000 - $7FFF. On interrupt, the service routine remembers the bank currently in use such that it can be restored before Return from Interrupt (RTI). The software then filters through the interrupt sources: first receive, then transmit empty, last transmit complete. Important to note that if the receive interrupt is enabled, the transmit interrupts are not. Reverse is true, if the transmit interrupts are enabled the receive is not.

- Receive interrupt
Software tests if the receive interrupt is enabled. If disabled, it moves on to service transmit empty otherwise it continues with receive. Software tests for a receive character ready, exits if not (restore bank and RTI) or processes the byte if ready.

- Transmit empty interrupt
Software tests if the transmit empty interrupt is enabled. If disabled, it moves on to service transmit complete otherwise it continues with transmit empty. Software tests for a transmit empty, exits if not (restore bank and RTI) or processes the byte if space in the transmit buffer is available.

- Transmit complete interrupt
Software tests if the transmit complete interrupt is enabled. If enabled software continues with transmit complete sercice. In the case transmit complete interrupt is present, software:
- Configures the interrupts for receive interrupt
- Turns off the ALDL transmit driver
- Adjusts flags
- Restores the bank if necessary
- Executes a return from interrupt


The next paragraphs detail operation of the service for each of the interrupt types

- Receive service
The interrupt service for receive is placed in bank 0. Since it is only called by the SCI interrupt, the bank is already set. The service begins by reading SCI status and data, adjusting flags and pointers. The receive status is checked for errors before proceeding.

/*
Errors are most likely a result of "noise" on the line but can be systemic. For example the junk serial cables often used to look at the ALDL stream sometimes default to standard baud rates. Drivers for 64bit Windows10 all take an 8192 baud rate but actually use 9600. Any baud rate that is in error by 5% will fail. Because of real world effects baud rate needs to be accurate to about 2% for the system to work well. Above 2% or so, the noise flag will often be set. BTW, this also affects bootstrap mode for those who might use it.
*/

(For this next bit, look at the Descriptors.txt file Ref. $F665)
The receive service keeps count of received bytes and maintains a checksum count. The first byte it receives is the "ID". The ID byte is used to detect a coresponding structure from a link list of structures. Software loops through the list looking for a match between ID byte and the structure. In the case of my PCM you can see that a match will be found for IDs $40, $42, $91, $95, $F4. IDs for which a match is not found in the link list are treated as not valid with this exception: IDs in the range of $E0 - $FF which are not matched in the link list are processed but not responded to. This permits testers with various IDs to communicate with other devices on the ALDL.

(For this next bit, look at the Receive.txt file)
Once detected, the structure controls how the message is processed and the PCMs responses to it.

Going back to the receive byte count, the second pass through the receive routine sets the message byte count. Message byte count sets the number of bytes the transmitter expects to send. This can be checked against the receive byte count ensuring that the whole message was sent/received. This byte is transmitted with a value of $55 plus the number of data bytes. Data bytes include all of the message except ID, Length and checksum. The first data byte is often given the meaning "Mode" and in some cases the second data is "Sub-mode".
I have a GM document that specifies "All high speed messages have an assigned mode number." however I do see some exceptions in this code. As usual not having all the GM documents makes things a bit of a guessing game.

Going back to the receive byte count, the next pass through the receive is data if any exists. The expected data count from the structure is checked to see if data is expected. Where there is no data in the message, this byte is checksum. While the expected count from the structure is not yet reached, each pass through this routine will buffer the receive data.

Once the receive byte count reaches the expected number of bytes from the structure, the last byte received is checksum. The checksum always adds to zero and is checked for each message. Once the checksum is verified, a response is generated based on if a structure was found and the content of that structure.

(For this next bit, look at the Decode.txt file)
Each message is processed differently based on it's ID byte.
--> ID = $91
This message is sent by the abs system to the PCM. I am not sure how the second data byte is named... could be sub-mode or just first data. In any case, bit 3 of this byte determines how spark retard request is done when the abs detects slip of the rear wheels. When set, retard is in response to this ALDL message. Otherwise pin C12 of the PCM is used to signal spark retard. This message also carries rough road data. When the ABS detects rapid acceleration and deceleration of the wheels, this is designated as a rough road. It sends the data in this message to let the PCM know that changes in rotation speed of the crank are not due to mis-fire.

--> ID = $95
This message is sent by the abs system to the PCM. I believe that this ID may be used to indicate the use of a second manufacturers abs system. This message carries the rough road data described above but no indication that ALDL can be used for traction control spark retard.

--> IDs = $40, $42
If anyone on the list has details of these please post! I looked at this a bit and believe it to be one of
- A still born anti-theft system
- An anti-theft system used other vehicles with different cal
- ?
The system seems to time stamp messages and send that time (with math mods) as part of the response. The systems BCM <just a guess> then does some shifts, rotates and ands on the timestamp and sends it back in the next message. The PCM does the same math on the returned timestamp and keeps things running if a match is found. This probably was intended to replace the VATS 50HZ input as part of anti theft. All this is guessing isn't great so if someone can explain, please do.

--> ID = $F4
This ID is from a connected test set. The code first examines the mode word of the message (first data). In a '97 Z28 the supported modes are: $00, $01, $03, $07, $08 and $09. All others are rejected. Each of the modes is serviced in a different way so the initial thing is to replace the descriptor structure dependent on mode.
(See Mode_F4_Deacriptors.txt)
The descriptor structures are used to point at the service for each of the modes.

Mode $00 does just two things: First it enables the scheduler (details to follow). Second it adjusts flags such that no ALDL command is in progress. This is very similar to Mode $09, not sure why both exist. Guessing as to why, it is probably history of how th ALDL was used in earlier vehicles. Some ALDL implementations had the scheduler in the BCM and this may be the way to set the ALDL to it's default state rather than command the scheduler on/off.

Mode $01 commands the PCM to transmit diagnostic data. A small table is used to direct the code flow based on sub-mode. There are two populated sub-modes which are $00 and $04, all others are ignored by the PCM. Once the receive is complete, the PCM then goes on to transmit the list of info to the tester. Explanation of the transmit will follow this section.

Mode $03 commands the PCM to transmit the content of memory included in data fields of the request.

Mode $07 commands the PCM to transmit a message. These messages are the same as those sent by the scheduler. I think this would only be used if the tester were to disable the scheduler and requst PCM scheduled messages be sent while adding some of it's own. Another use might be to request messages with IDs not sent by the scheduler. It would be great if someone has a list of the GM defined IDs that could be shared.

Mode $08 commands the PCM to disable the scheduler.

Mode $09 commands the PCM to enable the scheduler.

Just a quick note regarding the descriptors...
- $F5E5 Link list of message descriptors that can be requested using ID $F4 MODE $07. These are
sent to the following IDs $0A, $91, $95, $F0, $40, $12, $10, $92 and $A6
---------------------------------
Descriptor definition
*************************************************F 665
* LINK LIST STRUCTURES FOR PARSING RX MESSAGE
*
* 0/1 NEXT STRUCTURE ADDRESS
* 2 REQUESTING MODE
* 3 REPLY MODE/SCHEDULER MODE
* 4 REPLY TYPE
* 5 LENGTH
* 6/7 MESSAGE TRANSMIT DATA DESTINATION ADDRESS
* 8/9 MESSAGE RECEIVE DATA DESTINATION ADDRESS
*************************************************

---------------------------------
Once a message has been received, verified & processed the system will send a reply to some of the messages.

The descriptor is checked to determine the response length. The length field of the descriptor will have bit 7 set if there is to be no reply. The reply may have a data length of zero, in which case the response is ID:Length:Checksum. Cases where a reply is to be sent trigger a change of direction for the ALDL bus. The transmitter is set up, transmit interrupts configured, the bus driver enabled and the ID of the reply sent. At this point the transmit interrupt is enabled. This marks the end of processing for receive messages.


- Transmit service
The transmit interrupt service goes in play only after the ID has been sent and transmit interrupts enabled. Where the message is in response to a receive over ALDL, this is taken care of in the receive interrupt once the message is received and validated. Length of a reply is dependent on a number of things. The descriptor sets the reply length in most cases. That along with reply type set the response. Mode $03 is a small departure, for each two address bytes sent in the request, a single data byte which is the value stored at the request address is returned. Care is taken in the code to ensure that the TPU can not be accessed. This is because access to the TPU depends on a sequence of reads. If the tester were to access at the wrong time, the data returned by the TPU would be unexpected/defined. The port replacement registers $1800 - $180F are also excluded from direct reads.

Reply type in the descriptor sets how the reply is processed. In the PCM I have, only three types are used but I would expect that other years would have others defined.

-Type $00
The descriptor type $00 transmits a reply from a buffer addressed by the descriptor byte 6/7. As always, a checksum is maintained and sent after the message.

-Type $80
The descriptor type $80 transmits a reply data from address pairs that follow descriptor. As always, a checksum is maintained and sent after the message.

-Type $40
Type $40 is only used by mode $03 commands in my module. This code takes pairs of addresses from the request, reads the value and sends them back as part of the message. As described before, certain hardware addresses are excluded to prevent upset.

Once the transmitter is loaded with the last (checksum) byte of the message, the interrupt for transmit empty is turned off. When this is done a separate interrupt for transmit complete is enabled. When the transmit complete interrupt fires, this is the signal to change direction of the ALDL bus. The driver for transmit is turned off and the bus remains "marking". Any time a bus member sees marking for a character time or more it may transmit a message on the bus.

Scheduler
The scheduler is normally the ALDL bus master. It is driven by a 160/SECOND (6.25MS) interrupt driven clock tick. It uses this tick to update a counter. The LSB is not used, which results in a 12.5MS count through a table of values. Each of these values may represent an address of a message structure or $0000 to mark an empty time slot. The table is given in SchedulerMsgs.txt.
When entries in the table of messages are not zero, it indicates that a message is to be sent. Once a message structure is identified, the ALDL bus direction is set to output from the transmitter and the ID byte is sent. The buffer indicated by the structure is filled based on the length indicated by the structure and data from locations found just after the structure in memory. The data comes from the address indicated by pairs of bytes which indicate address H:L.

Once ID is sent, buffer filled, length and structure address saved the transmit interrupt scheme described before takes over. Once sent, the ALDL is toggled back to receive.

I have included a bunch of snips of code to help with the understanding of all this. I hope it is of interest.

-Tom

[Tom H]

I am sure most if not all folks dealing with ALDL have hardware and software they need, however I ran into a bit of a snag with mine.

It has been a while since I used the ALDL for anything. Since then the trusted old lap top bit the dust. It was 32bit win'95 machine and worked well with the cheep-o cables based on prolific parts to drive the interface. Turns out there are on drivers for prolific in win10. I did the whole thing of upgrading the driver and then rolling back and got the cables working again BUT win10 + driver no longer correctly support 8192 baud. You can fiddle with the registry and get the software to accept 8192 BUT the output is 9600. Big thanks to Bill & Microsoft, there is half a day I will never get back.

I turned to the Arduino for a solution. Wrote code for the board that lets me enter messages and send them, while looking at the output. I started by by modifying a software UART that someone wrote before history and has been ported to the Arduino IDE. A few changes and I had an open drain type output, perfect for this app. This software is by it's nature half duplex and it worked great for me. I have two flavours: first is un-buffered. This is great for my bench setup because it uses no parts. Arduino USB to PC and two wires (ground and ALDL) to PCM.
Second flavor is buffered. This requires one transistor, two diodes and 5 resistors. That plus a perf board, an Arduino Nano and some solder and you are good to go.

If anyone would like this design, just ask & I will post it.

IMG_1789.jpg



-Tom