1997 F-Body ECM

[Tom H]

Continuing with details of mode commands that are physically addressed:

Mode $20: Return to Normal Operation

Mode $20			
Return to Normal Operation			
			
Sets the communications with external devices back to normal			
Clears test modes if set			
					
			
4C 10 F0 20 62			Request
4C F0 10 60 B7			Positive acknowledgement

[Tom H]

Mode $22: Request Diagnostic Data By PID

This request is composed of header, mode, PID, rate

Mode is $22
PID is one of the supported PIDs
Rate: only a value of $01 is supported (single response)

The example shown requests the value of PID $0005 which is ECT

\B 4C 10 F0 22 00 05 01 F9 \E
\B 4C F0 10 62 00 05 00 D5 \E

[Tom H]

Mode $23: Request Diagnostic Data By Memory Address

This request is composed of header, mode, memory_address, rate

Mode is $23
Memory address is a three byte address. Address can only be in Tside bank 0, thus the first address byte is always $00
Memory address is checked for bounds. EEPROM (with the security password) is out of range, Portions of the FLASH (the calibration area) can be accessed.
Rate: only a value of $01 is supported (single response)

Reply is Mode|0x40, two bytes address only (two lsbytes), four bytes of data incrementing from the addrress selected.


\B 4C 10 F0 23 00 00 00 01 03 \E
\B 4C F0 10 63 00 00 80 63 A0 00 17 \E

[JimCT_9C1]

I wanted to provide some more details on the OBDX Pro DVI mode setup and tests I ran in post 419 above -

The basic DVI configuration was straight from the documentation. I didn't need to set a filter. I just entered DVI mode, verified VPW protocol (was already set), opened the network, and sent the $10 commands. To clean up, I just closed the network and exited DVI mode.

Here is the list of commands I used to set up and run the DVI mode tests in post 419. After powering up the cable adapter and connecting to PC/terminal and vehicle:

Two commands in the default startup ELM mode (ascii input):

ATZ - restart device
DXDP1 - enter DVI mode

Then, the following commands once in DVI mode. Everything that follows is in hex:

31 01 01 CC - display current network protocol
31 02 02 01 C9 - open network

10 05 4C 10 F0 28 00 76 - send network command 4C 10 F0 28 00
10 05 4C 10 F0 27 01 76 - send network command 4C 10 F0 27 01
10 07 4C 10 F0 27 02 91 94 4E - send network command 4C 10 F0 27 02 91 94

31 02 02 00 CA - close network
31 02 06 00 C6 - exit DVI mode


Responses to network commands (from post 419 - spaces and line breaks added):

20 01 00 DE - acknowledge network send command
08 05 4C F0 10 68 00 3E - network response message 4C F0 10 68 00
20 01 00 DE - acknowledge network send command
08 07 4C F0 10 67 01 13 57 D2 - network response message 4C F0 10 67 01 13 57
20 01 00 DE - acknowledge network send command
08 06 4C F0 10 67 02 35 07 - network response message 4C F0 10 67 02 35



I realized that I could have configured the DVI network responses to be more like the ELM example and pared down a bit. So I suppressed the DVI cable acknowledgement of network send commands ($20 response), and enabled display of the PCM generated CRC/checksum in replies. Here are the DVI commands and responses for this case. I have included the responses to the DVI setup commands as well for reference:


DVI Mode commands (hex):

31 01 01 CC - display current network protocol
33 02 08 01 C1 - display CRC in network responses
24 02 01 00 D8 - suppress $20 replies to $10 network send messages
31 02 02 01 C9 - open network

10 05 4C 10 F0 28 00 76 - send network command 4C 10 F0 28 00
10 05 4C 10 F0 27 01 76 - send network command 4C 10 F0 27 01
10 07 4C 10 F0 27 02 91 94 4E - send network command 4C 10 F0 27 02 91 94

31 02 02 00 CA - close network
31 02 06 00 C6 - exit DVI mode


DVI Mode responses (hex with spaces and line breaks added):

41 02 01 01 BA - network protocol is 01 (VPW)
43 02 08 01 B1 - acknowledge CRC display in replies
34 02 01 00 C8 - acknowledge no $20 replies
41 02 02 01 B9 - acknowledge network open

08 06 4C F0 10 68 00 5E DF - network response message 4C F0 10 68 00 5E
08 08 4C F0 10 67 01 13 57 05 CC - network response message 4C F0 10 67 01 13 57 05
08 07 4C F0 10 67 02 35 7E 88 - network response message 4C F0 10 67 02 35 7E

41 02 02 00 BA - acknowledge close network
41 02 06 00 B6 - acknowledge exit DVI mode


Note the $08 network response messages are just the vehicle response with three additional bytes - two leading and one trailing. The two leading bytes identify this is as a network EDIT:response message and its length, and the trailing byte is the DVI checksum.

Hope this helps anyone following along who may want to give it a try.

Jim

[Tom H]

Continuing with details of mode commands that are physically addressed:

Mode $25
Stop Transmitting Requested Data

This request is composed of header, mode
This request causes the PCM to stop sending data requested earlier
Mode is $25


4C 10 F0 25 0B
4C F0 10 65 DE

[Tom H]

Mode $27
Security Access Mode

This request is composed of header, mode and sub mode
Mode $25, sub mode $10 requests the PCM security seed. The return value can then be processed by
a security algorithm. The key resulting from the seed/security algorithm is sent to the PCM using
sub mode $02. This unlocks certain modes and permits download.
Various timers cancel security access if the interface goes quiet for a time.


4C 10 F0 27 01 71 Request for seed
4C F0 10 67 01 58 3D 27

4C 10 F0 27 02 01 23 B9 Send key (incorrect key $0123)
4C F0 10 67 02 35 7E Response code $35 indicates an invalid key ($0123)

4C 10 F0 27 02 91 94 FB Send key(correct)
4C F0 10 67 02 34 63 Response code $34 indicates security access allowed

[Tom H]

Continuing with details of mode commands that are physically addressed:

Mode $28
Disable Normal Message Transmission

This request is composed of header, mode, sub mode
It stops sending and receiving of data from other modules (over ALDL)
Mode is $28
Sub mode is $00


4C 10 F0 28 00 CF
4C F0 10 68 00 5E

[Tom H]

Mode $29
Enable Normal Message Transmission

This request is composed of header, mode
It stops resumes sending and receiving of data from other modules (over ALDL)
Mode is $29


4C 10 F0 29 97 Request
4C F0 10 69 42 Response

[Tom H]

Mode $2A
Request Diagnostic Data Packet/Packets

This request is composed of header, mode, rate, PID1, PID2, PID3,PID4

Mode is $2A
Rate is: $00 Stop sending data
$01 Send single response
$02 Repeat at slow rate: 100ms rep rate
$03 Repeat at medium rate: 50ms rep rate
$04 Repeat at fast rate: 25ms rep rate

PIDn Diagnostic parameter identifier/identifiers: 1, 2, 3 or 4 PIDs can be requested

Note: This command will "time out" if there is no activity on the class II bus.
Often times Mode $3F test device present is used to sustain activity


4C 10 F0 2A 00 57
4C F0 10 6A 00 C6

4C 10 F0 2A 01 F7 D6
4C F0 10 6A F7 00 00 00 00 00 00 A8
4C 10 F0 2A 01 F7 F8 1A
4C F0 10 6A F7 00 00 00 00 00 00 A8
4C F0 10 6A F8 00 00 00 00 00 00 F4
4C 10 F0 2A 01 F7 F8 F9 AE
4C F0 10 6A F7 00 00 00 00 00 00 A8
4C F0 10 6A F8 00 00 00 00 00 00 F4
4C F0 10 6A F9 00 00 00 00 00 00 A9
4C 10 F0 2A 01 F7 F8 F9 FA 91
4C F0 10 6A F7 00 00 00 00 00 00 A8
4C F0 10 6A F8 00 00 00 00 00 00 F4
4C F0 10 6A F9 00 00 00 00 00 00 A9
4C F0 10 6A FA 00 00 00 00 00 00 4E

4C 10 F0 2A 02 F7 F8 F9 FA 2F
4C F0 10 7F 2A 02 F7 F8 F9 FA 23 E2
4C F0 10 6A F7 00 00 00 00 00 00 A8
4C F0 10 6A F8 00 00 00 00 00 00 F4
4C F0 10 6A F9 00 00 00 00 00 00 A9
4C F0 10 6A FA 00 00 00 00 00 00 4E
4C F0 10 6A F7 00 00 00 00 00 00 A8
4C F0 10 6A F8 00 00 00 00 00 00 F4
4C F0 10 6A F9 00 00 00 00 00 00 A9
4C F0 10 6A FA 00 00 00 00 00 00 4E
4C F0 10 6A F7 00 00 00 00 00 00 A8
4C F0 10 6A F8 00 00 00 00 00 00 F4
4C F0 10 6A F9 00 00 00 00 00 00 A9
4C F0 10 6A FA 00 00 00 00 00 00 4E
4C F0 10 6A F7 00 00 00 00 00 00 A8
4C F0 10 6A F8 00 00 00 00 00 00 F4
4C F0 10 6A F9 00 00 00 00 00 00 A9
4C F0 10 6A FA 00 00 00 00 00 00 4E
4C F0 10 6A F7 00 00 00 00 00 00 A8
4C F0 10 6A F8 00 00 00 00 00 00 F4
4C F0 10 6A F9 00 00 00 00 00 00 A9
4C F0 10 6A FA 00 00 00 00 00 00 4E
4C F0 10 6A F7 00 00 00 00 00 00 A8
4C F0 10 6A F8 00 00 00 00 00 00 F4
4C F0 10 6A F9 00 00 00 00 00 00 A9
4C F0 10 6A FA 00 00 00 00 00 00 4E
4C F0 10 6A F7 00 00 00 00 00 00 A8
4C F0 10 6A F8 00 00 00 00 00 00 F4


4C 10 F0 2A 2F 6B
4C F0 10 6A 2F FA

4C 10 F0 2A 21 CD
4C F0 10 6A 21 5C

4C 10 F0 2A 22 EA
4C F0 10 6A 22 7B

4C 10 F0 2A 2F 6B
4C F0 10 6A 2F FA

4C 10 F0 2A 20 D0
4C F0 10 7F 2A 20 12 63
4C 10 F0 2A 21 CD
4C F0 10 6A 21 5C
4C 10 F0 2A 22 EA
4C F0 10 6A 22 7B
4C 10 F0 2A 23 F7
4C F0 10 6A 23 66
4C 10 F0 2A 24 A4
4C F0 10 6A 24 35
4C 10 F0 2A 25 B9
4C F0 10 6A 25 28
4C 10 F0 2A 26 9E
4C F0 10 6A 26 0F
4C 10 F0 2A 27 83
4C F0 10 6A 27 12
4C 10 F0 2A 28 38
4C F0 10 6A 28 A9
4C 10 F0 2A 29 25
4C F0 10 6A 29 B4
4C 10 F0 2A 2A 02
4C F0 10 6A 2A 93
4C 10 F0 2A 2B 1F
4C F0 10 6A 2B 8E
4C 10 F0 2A 2C 4C
4C F0 10 6A 2C DD
4C 10 F0 2A 2D 51
4C F0 10 6A 2D C0
4C 10 F0 2A 2E 76
4C F0 10 6A 2E E7
4C 10 F0 2A 2F 6B
4C F0 10 6A 2F FA
4C 10 F0 2A 30 1D
4C F0 10 7F 2A 30 12 D7

4C 10 F0 2A 01 F7 FF FF FF C7
4C F0 10 6A F7 83 00 00 00 00 00 C2

[Tom H]

Mode $2C
Dynamically Define Diagnostic Data Packet

DPID $FE THRU $F8 can be dynamically defined


The other day I posted a too brief explanation of dynamically defined diagnostic data packet access (mode $2A). This was a bit short sighted because the deeper I get into it, the more complex it becomes. The explanation glossed over what data is sent and how it is requested. Dynamically defined diagnostic data packets are simply a way to group PID and/or address content such that they can be displayed together. Mode $2A permits the parameters to be displayed at intervals for graphing.

In the 1997 LT1 PCM there are seven diagnostic data packets that can be defined. They are numbered $F8 through $FE. Each these Diagnostic Packet IDs (DPID) can be associated with six parameter IDs. The parameter IDs give you access to the analog or digital value you are looking for from one of the defined Parameter IDentifiers (PID). DPIDs can also be associated with memory addresses. Up to six addresses or PIDs can be displayed with a single request or on a repetitive basis.

Taking the display by address case first: A regular physically addressed header is sent, followed by the mode ($2C). The next byte defines if the request frame is display by address or pid. There are two other possible ways to display (display by offset or manufacturer defined) but these are not supported. This byte also sets where in the response frame the requested parameter will be inserted and the number of bytes the parameter has. Since the PCM expects the header (three bytes) plus a frame of seven bytes followed by crc, address displayed frames have a pad just ahead of the crc. This pad is defined as $FF. For example, a frame can be composed as follows:

4C 10 F0 2C F8 ...

Where
4C 10 F0 is the standard low priority header
2C is the mode
F8 is one of seven DPID
xxyy yzzz is the byte that sets the interpretation of bytes that follow
xx = 01 for define by PID
xx = 10 for define by address
yyy = Where in the response frame the data is to appear
zzz = Number of bytes in this response
address_h is the msb of a 3 byte address
address_m is the mid address byte
address_l is the lsb address byte
FF is a pad byte to maintain a request length consistent between address and PID defined

Certain addresses are excluded.
- Code above the calibration area (above $4325)
- Internal ram in the stack area can not be accessed ($03DF-$03FF)
- Register space of the PRU (below $1810)
- The space between the rams including CPU registers, EEPROM, DLC...

Here are a few mode $2C requests to get started:

4C 10 F0 2C F8 89 00 18 9A FF 2E - DPID $F8 displays one byte from address $189A in the first return data byte
4C F0 10 6C F8 89 2E - PCM response to assignment request

4C 10 F0 2C F8 8A 00 18 9A FF 90 - DPID $F8 displays two bytes from address $189A/B in return data bytes 1 & 2
4C F0 10 6C F8 8A 09 - PCM response to assignment request

Note: The same result can be accomplished sending two requests for a single byte but with different place where the
resulting data is to appear as follows

4C 10 F0 2C F8 89 00 18 9A FF 2E - DPID $F8 displays one byte from address $189A in the first return data byte
4C F0 10 6C F8 89 2E - PCM response to assignment request
4C 10 F0 2C F8 91 00 18 9B FF FB - DPID $F8 displays one byte from address $189B in the second return data byte
4C F0 10 6C F8 91 0B - PCM response to assignment request

The Mode $2A request is used to access the DPID you create
4C 10 F0 2A 01 F8 6D
4C F0 10 6A F8 00 00 00 00 00 00 F4 - Hmmm both data happened to be 00, I could have picked a
better address but that's the idea


For PID defined DPID the way to access is similar but there are a few differences. PIDs are defined by two bytes so in all cases, the request defines two PIDs. Each PID has a number of bytes associated with it and the combination of where the data is to appear in the output (yyy) and the number of bytes (zzz) must match the sum of both PID. An example of this is:

PID $03 is the fuel system status. Requesting that PID returns two data bytes.
PID $11 is the throttle position. Requesting it returns one byte.
Where both these PIDs are in a request, three bytes will be returned. Positioning them just after the DPID byte yeilds a request frame as follows:
4C 10 F0 2C F8 4B 00 03 00 11 75

This will request that the PCM will assign PIDs $0003 and $0011 to the first three bytes of DPID $F8. When requested by a mode $2a command, the result is:

4C 10 F0 2A 01 F8 6D Request
4C F0 10 6A F8 01 01 88 00 00 00 71 Response

The request can be modified to repeat on various intervals

The use of DPIDs for tuning an LT1 give considerable power. The result can be graphed as it is time based when the repetitive mode is used.
When I first looked at this, I felt that the same thing could be accomplished in different ways and that it was too complex to be of value. I now see that it offers a much better way to see parameters that are time based.

-Tom

[Tom H]

Since making the download code work, I have struggled a bit
writing the assembly code to implement mode $35. The DLC seems
quite simple, but working/understanding the part caused me a
few problems. I first wrote this code thinking that the DLC
would return only frames from external sources. Should have
done a second read of the doc...
The code I am posting today does work however and I am happy
to share it.

This code is downloaded to the 68HC11 internal ram. It also
uses the external ram (PRU) for stack and variables. Once loaded
the normal operation of the PCM is suspended. The regular
modes are also suspended and the PCM responds/generates only
the following:

SUPPORTED MODES $35 Terminal --> PCM: REQUEST UPLOAD
$75 Terminal <-- PCM: ACKNOWLEDGE UPLOAD REQUEST
$36 Terminal <-- PCM: REQUEST DATA TRANSFER
$76 Terminal --> PCM: ACKNOWLEDGE DATA TRANSFER
$37 Terminal --> PCM: EXIT/RE-BOOT

The sequence to use this code is:
1- Download the executable to internal ram at $0000 and execute at $0000
2- Issue a mode $35 request
3- The PCM will issue a mode $75 response. Check this against the
response code list.
4- The PCM will respond with a data transfer frame (mode $36). Frames
contain 1024 ($0400) bytes or less. For longer requests, another
mode $36 frame will be generated after each transfer acknowledge
frame (mode $76).
5- Issue a mode $76 acknowledgement of the frame. Repeate step last two
steps until the upload is complete. Once complete, the PCM will no
longer send a mode $36 frame after the ack.
6- Exit the upload code using a mode $37 request. This action will
clear all internal ram.


Response codes...
RESP CODE $11: MODE NOT SUPPORTED
RESP CODE $50: UPLOAD NOT ACCEPTED
RESP CODE $51: IMPROPER UPLOAD TYPE
RESP CODE $52: CAN'T UPLOAD FROM SPECIFIED ADDRESS
RESP CODE $53: CAN'T UPLOAD NUMBER OF BYTES REQUESTED
RESP CODE $54: READY FOR UPLOAD

For the commands, I stayed as close to the info Kur4o sent me as I could.
There are some small differences though. The largest difference is the
use of the command's 3rd address byte. I believe that in the download and
all other commands the 3rd address byte MUST be zero. In my case, I need
to address two banks for a total address range of 128K. In order to do that
I extend using the high address as bank. Only banks 0 and 1 are valid. Other
banks will get you an error code $52.

To make things a bit easier, if you want to upload the content of EEPROM,
this command will make it happen:
4C 10 F0 35 00 02 00 00 0E 00 <crc>

Upload bank 0: This results in the PCM sending 56 frames
4C 10 F0 35 00 E0 00 00 20 00 <crc>

Upload bank 1: This results in the PCM sending 32 frames
4C 10 F0 35 00 80 00 01 80 00 <crc>

I have not looked at the ESide yet, but will get there soon. There have been
necessary changes in my homebrew cable software. It is still a work in progress
and if needed I could send it out if there is interest.

I will add the ASM and S19 files for the code to this post.

Enjoy -Tom

[sherlock9c1]

Happy new year! Tom H has done some fabulous work here, and JimCT_9C1 has helped with the XDF. We've been talking offline and I think the next step is to get FlashHack baselined in GitHub so we can start working on integrating this capability. Steveo helped me baseline his latest local copy of FlashHack 1.4 into GitHub as FlashHack 2.0. https://github.com/sherlock9c1/FlashHack

As of this post, there isn't a new executable available here. This is for development. I'll work with steveo on compiling new executables and then making them available.

Steveo has architected FlashHack very modularly with classes for processors and interfaces. That needs to be figured out. I have an OBDXPro and also plan on building Tom's Home Brew Cable ('THBC'?) so I can have more commonality with him as we divy out processor and interface code.

I've got a lot of irons in the fire, and I'll likely be able to commit one day a week to this; GitHub allows others to collaborate. If you're interested in collaborating, send me a PM.

[Tom H]

Hello & happy new year to you all.

It has been suggested that this thread "1997 F-Body ECM" should become separate from posts discussing tools, tool flow and re-flashing. I agree and will start a thread titled " 1997 F-Body Tools". There will be a bit of back and forth on some details such as discussion of mode $34 / $36 but it will streamline both discussions

-Tom

[sherlock9c1]

Should I start a new thread for the reflashing then as well?

[Tom H]

Yes please. -Tom