1997 F-Body ECM

[kur4o]

I can say an avt-852 cable[expensive] will work for sure. Some extra bytes need to be sent.
obdXpro[moderatelly priced]
https://obdxpro.com/
should also work. It also supports elm shit.

obdlink cable might not work due to limited upload buffer.

I am sure your home brew cable will yield great interest too, and there will be some guys testing for sure.

[NomakeWan]

obdXpro[moderatelly priced]
https://obdxpro.com/
should also work. It also supports elm shit.

And as a reminder, I have one of these cables and would be willing to loan it out to anyone doing development on the 96-97 LT1/LT4 PCMs. I do not have access to a '96 Corvette at present so I cannot help directly, but I can at least help that way. :)

[Tom H]

I can't find any reference to modes $35 or $37 anywhere other than the SAE J2190. That only give me the generic details of the mode. If we can't find the detail of these modes, I plan to use:

MM $35 MODE
LH LENGTH HIGH: $00
LL LENGTH LOW (LENGTH NOT TO EXCEED 64 --> $40)
AH ADDRESS HIGH: $00 AND $01 VALID ($01 YIELDS BANK 1 RESULT)
AM ADDRESS MIDDLE 8BITS
AL ADDRESS LOW 8BITS
CRC CYCLIC REDUNDANCY CHECK

SAE J2190: MODE $37 REQUEST
H0 H1 H2 D0 CRC
4C 18 F0 $37 CRC

H0 NO IFR
3 BYTE HEADER
PHYSICAL ADDRESSING
NODE-TO-NODE
H1 $18 LOAD SERVICE PORT
H2 $F0 TESTER
MM $35 MODE
CRC CYCLIC REDUNDANCY CHECK

-Tom

[Tom H]

Cut/paste error...

SAE J2190: MODE $35 REQUEST
H0 H1 H2 MM D1 D2 D3 D4 D5 CRC
4C 18 F0 $35 LH LL AH AM AL CRC

H0 NO IFR
3 BYTE HEADER
PHYSICAL ADDRESSING
NODE-TO-NODE
H1 $18 LOAD SERVICE PORT
H2 $F0 TESTER
MM $35 MODE
LH LENGTH HIGH: $00
LL LENGTH LOW (LENGTH NOT TO EXCEED 64 --> $40)
AH ADDRESS HIGH: $00 AND $01 VALID ($01 YEILDS BANK 1 RESULT)
AM ADDRESS MIDDLE 8BITS
AL ADDRESS LOW 8BITS
CRC CYCLIC REDUNDANCY CHECK

SAE J2190: MODE $37 REQUEST
H0 H1 H2 D0 CRC
4C 18 F0 $37 CRC

H0 NO IFR
3 BYTE HEADER
PHYSICAL ADDRESSING
NODE-TO-NODE
H1 $18 LOAD SERVICE PORT
H2 $F0 TESTER
MM $35 MODE
CRC CYCLIC REDUNDANCY CHECK

[kur4o]

I think mode 35 was used for reading bin from early vpw PCMs. It was removed later but upto blackboxes it was built in the code. Not sure if it is present in ee but might be there.


Here is some typical usage of mode 35

[27:968] - Written data

6c 10 f0 [35] [00] [08 00] [00 10 00] .l.ð5......
35 mode
00 submode
0800 size of dump
00 10 00 address of dump
[01:09:796] - Read data

response1
6c f0 10 75 00 54
response2
6d f0 .10 36 00 08 00 00 10 00
c9 9c 00 01 c9 a0 00 01 .6......Éœ..É*..
c9 b8 00 01 c9 bc 00 01 c9 c0 00 01 c9 c4 00 01 ɸ..ɼ..ÉÀ..ÉÄ..
c9 c8 00 01 ca 0c 00 01 ca 10 00 01 ca 14 00 01 ÉÈ..Ê...Ê...Ê...
ca 18 00 01 ca 1c 00 01 cf 8e 00 01 cf 92 00 01 Ê...Ê...ÏŽ..Ï’..
cf 96 00 01 cf 9a 00 01 cf 9e 00 01 cf b6 00 01 ϖ..Ϛ..Ϟ..϶..
cf ba 00 01 cf be 00 01 cf c2 00 01 cf c6 00 01 Ϻ..Ͼ..ÏÂ..ÏÆ..
d0 0a 00 01 d0 0e 00 01 d0 12 00 01 d0 16 00 01 Ð...Ð...Ð...Ð...
d0 1a 00 01 eb 4c 00 01 eb 50 00 01 eb 54 00 01 Ð...ëL..ëP..ëT..
eb 58 00 01 eb 5c 00 01 ec 18 00 01 ec 1c 00 01 ëX..ë\..ì...ì...
ec 20 00 01 ec 24 00 01 ec 28 00 01 ec 3e 00 01 ì ..ì$..ì(..ì>..
ec 42 00 01 ec 46 00 01 ec 4a 00 01 ec 4e 00 00 ìB..ìF..ìJ..ìN..
3e c6 00 00 3e d6 00 00 3e fc 00 00 3f 22 00
.............................
41 f9 00 03 b1 54 30 38 a9 1c 32 2e ff fc 60 0e Aù..±T08©.2.ÿü`.
41 f9 00 03 b0 14 30 38 a9 1c 32 38 a9 34 74 14 Aù..°.08©.28©4t.
4e b9 00 03 50 4c 02 40 [74 fb]

[74 fb] block checksum

[01:10:000] - Written data

06 6c 10 f0 76 00 54 .l.ðv.T

Small pause

6c 10 f0 [35] [00] [08 00] [00 18 00] .l.ð5......

And so on

This is with built in reading from 97 blackbox pcm.

[Tom H]

Thank you kur40

Brings more questions though: The '97 has no mode 35, that's why I am doing it first. What is a blackbox pcm? Do you describe the '97 as ee? I have never understood the way ecms are described/broadcast codes and so on. This would make a great post for me if the situation could be explained.

-Tom

[kur4o]

ee=lt1
blackbox= 96-99 vortec trucks pcm. It have the same casing and similar connectors as lt1 pcm, but uses more powerfull processor motorola 68332.96-97 have 2 128kb intel memory chips. 98-99 have a single larger 512kb memory.

Look for some left over subroutine that can response as mode 35. The example is the standart communication but you can upload some code and dump the bin in many other ways. Or read it byte by byte if there is mode 23.

[sherlock9c1]

Some experimentation:
After the required:
ATSP2 and
AT SH 4C 10 F0 <-- this allows you to skip writing "DX SD 4C 10 F0" where 'DX SD' is the ELM command to send data, and '4C 10 F0' is the header.

Then you can simply send a command and get the response in ELM mode.

Switching to DVI was successful using the command: DX DP 1, which returns "OK"

Then in Realterm you need to make some changes:
Display Tab:
- Select 'Display as' Hex[space].
- Activate 'Half Duplex'

Send Tab:
- All numbers must have the 0x prefix. This may be obvious to you but it stumped me for a bit.
- \n after should be activated

After that I confirmed that you don't need to send the header, just the message, as kur4o indicated.

Here's where I got stuck: Say I want to send a $27 command; following the format listed in the manual and by kur4o, I send:
27 01 01 D6, then I receive an error code: 7F 02 27 01 56
Which seems to indicate received $27 was an error $01 invalid command.

Same with 29 00 D6; I got 7F 02 29 01 54

I tried several different commands and got nothing but 7F error code messages, all 01 invalid.

[sherlock9c1]

JimCT_9C1, I can only get to the car once or twice a day to test things; so if you can access it faster, fantastic.

Tom says the next steps are:

1. Establish how to get rid of needing DX SD every command. Or test out what's written in section 2.35 of the manual so that we only need to send the command? Alternatively, switch to DVI mode and follow the formats and examples listed in section 3.2.
2. Perhaps use DVI to eliminate the ">" which would make the API a lot simpler.

Tom asked to run several requests and then capture the output so he can see what's returned between commands, which will make parsing easier. Example commands:

• 4C 10 F0 12 00 FF FF (Request Diagnostic Freeze Frame Data)
• 4C 10 F0 17 01 00 (Request Status of Diagnostic Trouble Codes)
• 4C 10 F0 20 (Return to Normal Operation)

[kur4o]

I say switch to dvi protocol. This DX SD is some kind of extended elm commands set implemented.
I think dvi is much closer to avt type of protocol in pure hex. No need to convert anything in ascii.

[kur4o]

3.11.7.
Set/Get Validate CRC on Network Frames
This ON by default
, thus
CRC’s are validated on read.
Request to set: 
33 02 0
7
XX 
YY
Where XX is:  00= CRC OFF, 01 = CRC ON 
YY is normal checksum
Response: 
43 02 0
7
XX YY
Request to Get: 
33 01 0
7
YY
YY is normal checksum
Response: 
43 02 0
7
XX YY
3.11.8.
Set/Get Display CRC in Received Frame
This is 
OFF by default
, thus d
oes not display CRC 
in received frames to PC
.
Request to set: 
33 02 0
8
XX YY
Where XX is:  00= CRC OFF, 01 = Display CRC in returned frame
YY is normal checksum
Response: 
43 02 0
8
XX YY
Request to Get: 
33 01 0
8
YY
YY is normal checksum
Response: 
43 02 0
8
XX YY

How to set crc in dvi mode

o enable using the DVI protocol, you must first send the ELM string command DX DP 1 which will
change from ELM to DVI protocol

[kur4o]

To send in dvi mode use

10 [xx] message [yy]

xx= length of message
yy= is some sort of frame checksum used by the tool.[it is not the crc byte]

edit:
YY = Checksum (Sum of bytes and inversed)

ff-(a+b+c+D+...)

[JimCT_9C1]

Sherlock - glad you're up and running with the OBDX Pro and making progress. I have Realterm as well so that's a common foundation to work from.

Glad to help with testing, but unfortunately I will be away from the car for the next few days so won't be able to do more in-car testing this week.
In the meantime, I will start looking into the DVI protocol.

Jim

[Tom H]

Sherlock - glad you're up and running with the OBDX Pro and making progress. I have Realterm as well so that's a common foundation to work from.

Glad to help with testing, but unfortunately I will be away from the car for the next few days so won't be able to do more in-car testing this week.
In the meantime, I will start looking into the DVI protocol.

Jim

Thank you Jim. Testing should start soon. -Tom