1997 F-Body ECM

[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

[Terminal_Crazy]

It's all interesting mate.

I have the ABS manual for 1995 Z28 so I'll have a look. I wrote software to pull ABS codes years ago.
Anyone attempted to control the Retard function through the PCM pin. Would it respond to messages from a PC ?

Mitch