1997 F-Body ECM

[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.

[Tom H]

I have worked through a number of issues and finally have my Srecord download in working reliably. If it's going to be of use to others, you will need to build my interface (cable) or use a commercially available cable. The one that folks seem to have is the OBDX Pro VT. If you have one of these, answers to a few questions would be a help to me.

- The OBDX Pro VT Command Set Reference Guide has no info about serial port setup. It would be a help to know the baud rate, parity, stop bit requirements.

- I would like to transmit, receive and check my own CRC. This is what my homebrew interface supports. Is this cable capable?

- Can I suppress the cable's generation of header and just send the hex.


-Tom

[In-Tech]

Hi Tom,
I have an ObdX pro if it will help with your development. I also have a GM MDI and an AVT852 and old school AVT 838 serial amongst many other things. I don't remember reading of your interface, I apologize. If you can point, I will build one.
I don't have the answer about cable generation of header but the same concept has bothered me for quite some time.
Let me know what I can do to help :)
-Carl

[Tom H]

Hi Tom,
I have an ObdX pro if it will help with your development. I also have a GM MDI and an AVT852 and old school AVT 838 serial amongst many other things. I don't remember reading of your interface, I apologize. If you can point, I will build one.
I don't have the answer about cable generation of header but the same concept has bothered me for quite some time.
Let me know what I can do to help :)
-Carl

Hi Carl,
I have not written the interface up yet. At the moment it seems to detect break at random times when there is no break. Works 95% but as always fixing the last bit takes some time. I hope to have it to you soon. Regarding the cable, I might take you up on it just so I can test. The interface is a little different. On mine, what the PC sends is what goes out on the link. My PC generates the header in bytes THIS is different from the ELM327 which forces the user to configure a header and sends it before each frame. I also check CRC in PC software to ensure correct reception. These are the main differences control of header, CRC generation/checking and communications. Doesn't seem like too much, so I figure a conditional compile. It would get complicated if there are several more interfaces.

It would be an assist if you plugged the cable into your PC, set up a terminal and confirmed the rate is same as ELM (that is 38,400 8N1). All you need to do is send it "ATZ" and the reply should let us know if you are connected.

IF that works and you feel like trying just a bit more, it would be interesting to hook it to an LT1 and send the following:
ATSH 4C 10 F0
ATH1
28 00

And see if it replies 4C F0 10 68 00 5E Or if the cable swallows the 5E

The interface should be posted soon. It uses the Arduino Nano (which I now seem to use for everything) three transistors a handful of resistors and an 8.2V Zener diode. Just need to get the bugs out.

-Tom

[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.

[Tom H]

Some experimentation:

...

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.

Your command to get the security seed assumes that the header is pre-pended with the commands above. The mode $27 and submode $01 are all that is needed. The "7F" general error is because there are the wrong number of parameters sent. in my case the transcript runs as follows:

Frame: 4C 10 F0 27 01 71
Frame: 4C F0 10 67 01 58 3D 27


The request header 4C 10 F0, mode/submode 27 01 CRC 71

I believe your mode $29 has a similar problem, the command is only the mode. Try sending header, $29, crc. That should work.

-Tom

[JimCT_9C1]

Thank you Sherlock and Tom -

My understanding of DVI is that it is separate and independent of the ELM protocol. Therefore the ATSH has no effect and the header must be included in the DVI message data block (See Section 3.5 and Tom's post above). The DVI command to send a message to the vehicle is $10. There are no $27 or $29 DVI commands, hence the invalid command error. Sherlock, if you get a chance give the $10 command a try with the full request in the data block. I will try some off-car tests myself - I suspect I will get different bus-type errors with no vehicle present.

Regarding the ELM ATSH command - yes it's nice to not have to type/send the header each time. However, since it's the only way to change the header in the basic ELM instruction set, it can be something of a burden if you are changing headers in a string of requests and need to issue a new ATSH each time. For such cases, using the DXSD command' with its embedded header can be beneficial.

Thanks too for sharing the Realterm setup info - that eases the learning curve. I believe I saw the later versions have a direct hex option on the Send tab so you don't need the 0x or $ prefix. I downloaded an updated version, but haven't installed to verify.

Hope the above is helpful,

Jim

[sherlock9c1]

Jim - I'm using RealTerm 2.0.0.70; the chatter on SourceForge looks like 3.0.0.27+ has an option to send as hex. EDIT - I found a 3.0.0.30 beta download site and will try it after work.

Tom - the DVI errors as listed in the OBDXPro VT user's manual are:

The configuration errors possible include:
const uint8_t Error_InvalidCommand = 1;
const uint8_t Error_RecvTooLong = 2;
const uint8_t Error_ByteWaitTimeout = 3;
const uint8_t Error_InvalidSerialChksum = 4;
const uint8_t Error_SubCommandIncorrectSize = 5;
const uint8_t Error_InvalidSubCommand = 6;
const uint8_t Error_SubCommandInvalidData = 7;

Ah, so that's why kur4o listed 10 as the first byte in the DVI messages! OK, I'll update them and try again tonight.

Joel

[sherlock9c1]

With DX PT1:

>AT SP2                                                                   
OK                                                                        
>AT H1                                                                    
OK                                                                        
>AT S1                                                                    
OK                                                                        
>DX PT1                                                                   
OK                                                                        
>DX SD 4C 10 F0 28 00                                                     
4C F0 10 68 00 5E                                                         
>DX SD 4C 10 F0 27 01                                                     
4C F0 10 67 01 7B 38 EF                                                   
>DX SD 4C 10 F0 27 02 91 94                                               
4C F0 10 67 02 35 7E                                                      
>

Without DX PT1 (close RealTerm, unplug cable from car and laptop, reconnect cable on both ends, reopen Realterm):

AT SP2                                                                
OK                                                                    
>AT H1                                                                
OK                                                                    
>AT S1                                                                
OK                                                                    
>DX SD 4C 10 F0 28 00                                                 
4C F0 10 68 00 5E                                                     
>DX SD 4C 10 F0 27 01                                                 
4C F0 10 67 01 7B 38 EF                                               
>DX SD 4C 10 F0 27 02 91 94                                           
4C F0 10 67 02 36 59                                                  
>