Flash Protocol

[Hera]

My thoughts..

Whatever you learn from snooping on the VPW end would have to be converted to RS232. Wouldn't it be better to listen in on a RS232 side?

Well in actuallity, you wouldn't learn anything by listening to the RS232 side, because that is just the way your computer communicates with the tech 2 or other device... if we want to have a device that anyone can use and not spend over 2000 dollars to obtain, then we must listen to the VPW side...

When we listen to the VPW side, we get the specific commands that the programming device uses to put the PCM in programming mode. The commands I listed above are the correct for the GM class 2 PCM... In what order or exactly what they mean, I have no idea yet..

Once we find how the tech 2 or other device communicates with the PCM we can write the software for the BB device in order to use it for flash programming...

LS1Edit downloads the flash file from the PCM, but when making changes it only change the memory location for the specific change.. it doesn't not do a complete rewrite... The commands I found above specify the different modes for complete upload and download as well as block mode or something like that...

Kevin

[Keith@HPTuners]

The Tech II doesn’t work through serial though does it.
Also the manner in which you talk to the B&B device is a proprietary protocol so even if you did snoop something else talking over serial to a VPW box it would be different on the B&B.

Tech-2 is straight VPW. If you did snoop such a device though you could obtain security keys that would be needed for the B&B device.

What's confusing me is how a command in RS232 looks like compared to a command in VPW.

[RoboGeek]

ok.. I have a possible way to convert VPW to serial from a sound card input. This would only be for reading but may be adequate for sniffing. I have not tested it.

Also, do you think the VPW side will yield useful info? It would seem that the converter is only creating binary out of the VPW signal. If so then sniffing the serial info should work ok. Would save the trouble of decoding the VPW info...

There may be some stuff we need to look at on the VPW side as far as mode switching or packet request type stuff but I would think that we should try to get the basic communication working the way we want first, and add more advanced stuff as we go along. That will kind of bring everybody along at the same speed and somebody may just get a brainstorm from it.

And lastly.. anybody interested in playing with a PIC device? we could reprogram the interface to do what we want then. I have PIC Basic and a C compiler thing for these critters. And a BASIC stamp is pretty cheap.
Anybody know how many I/O's we need to control? I will check into this area...

[RoboGeek]

here's the spec sheet for a Philips transciever.. it may help explain the conversion to binary.
VPW is used in communications alot. Its similar to FSK and other modulation formats. No big secrets to it. I can make a post on it that explains how it works if you think its needed.

heres a pdf on the chip: http://www.semiconductors.philips.co...s/AU5783_6.pdf

and a description. Sound right for our app? Its an automotive design.. and best news is it cost a whopping $1.38

The AU5783 is a line transceiver being primarily intended for in-vehicle multiplex applications. It provides interfacing between a J1850 link controller and the physical bus wire. The device supports the SAE/J1850 VPWM standard with a nominal bus speed of 10.4 kbit/s. For data upload and download purposes the 4X transmission mode is supported with a nominal bus speed of 41.6 kbit/s. The AU5783 provides protection against loss of ground conditions, thus ensuring the network will be operational in case of an electronic control unit loosing connection to ground potential. Low power operation is supported through provision of a sleep mode with very low power consumption. In addition an external voltage regulator can be turned off via the AU5783 transceiver to further reduce the overall power consumption. The voltage regulator will be activated again upon detection of bus activity or upon a local wake-up event.

[RoboGeek]

i found a chip that uses standard modem commands... its low speed only but cheap and easy to use

http://www.elmelectronics.com/DSheets/ELM322DS.pdf

This is a bit more advanced. I am checking the chip inputs to see if I can figure out what it actually is.. but if the price is right and it works the way we want.. it supports GM and Ford. Also the circuit may be useful.. I have already found some interesting stuff out from it ;D

here's an j1850 pdf ftp://download.intel.com/design/inta...s/j1850_wp.pdf

and heres some sourceforge project related to what we are doing..
http://freediag.sourceforge.net/doc/...Interfaces.htm

hope this gives a little useful info..

oops.. found more goodies. this looks interesting.. check out the vehicle spy s/w. I'm not sure but I think it can sniff the bus...

http://www.intrepidcs.com/neovi/specs.htm

this has programming info for controlling the communications interface.
http://www.intrepidcs.com/neovi/api/apiframesMain.htm

[Dr._Lightspeed]

elm is good but it will not allow big enough data packets
I can tell you the enc seed requires more than elm can handle

[RoboGeek]

yea.. the elm just looked kinda interesting the way the circuit is set up for it. It isn't very versatile at all, which is why its so simple. But it may have a use for something...

[ls1tools]

What's confusing me is how a command in RS232 looks like compared to a command in VPW.

OK, here's an example:

To request a GM VIN from the PCM using the B&B interface:

$01,$01,$41,$05,$6C,$10,$F1,$3C,$01,$F2
$01,$01,$C1,$0B,$6C,$F1,$10,$7C,$01,$00,$31,$47,$31,$59,$59,$13

$01,$01,$41,$05,$6C,$10,$F1,$3C,$02,$F3
$01,$01,$C1,$0B,$6C,$F1,$10,$7C,$02,$33,$32,$47,$33,$33,$35,$00

$01,$01,$41,$05,$6C,$10,$F1,$3C,$03,$F4
$01,$01,$C1,$0B,$6C,$F1,$10,$7C,$03,$31,$30,$33,$36,$32,$39,$EF

The bold text is the SAE-J2190 message that is transmitted bit for bit onto the VPW bus.
The SAE-J2190 message is interpreted like this:
Send:
$6C = priority (bits 7,6 and 5. 0=high 7=low), addresing mode and other flags,
$10 = physical ID of destination, $10 = PCM
$F1 = physical ID of source, $F1 = off-board tool
$3C = mode, $3C=Get data block (up to 6 bytes)
$01,$02,$03 = data block numbers (VIN is stored in blocks 1, 2 and 3)

Recv:
$6C = same as send message,
$F1 = physical ID of destination, $F1 = off-board tool
$10 = physical ID of source, $10 = PCM
$7C = send mode + $40
$01,$02,$03 = data block numbers (VIN is stored in blocks 1, 2 and 3)

Because a VIN is 17 chars and 3 blocks of 6 bytes is 18 chars the first byte of the first block is ignored.

The B&B interface strips of the SAE-J1850 CRC byte.

The non-bold text is the B&B interface's wrapper and is interpreted as follows:
byte 1: $01 - always.
byte 2: number of command bytes to follow
byte 3: command byte, $41 = send physically addressed message.
byte 4: number of data bytes to follow.
byte n: checksum.

Regards
Paul

[Keith@HPTuners]

Paul, your a life saver. I have autotap V1.. When I get the time I'm going to start playing with some of this stuff.

Here's a question. Does the B&B device buffer the data where I need to request a read from it to obtain my requested info or do I have to just listen openly on com port?

Thanks again!

- Keith

[ls1tools]

Here's what the actual wire voltages look like for RS232 v's J1850 VPW.
The image is to scale (+/- 5%).



For SAE J1850 VPW:
The SOF symbol is always active.
A one bit symbol is either long-passive or short-active.
A zero bit symbol is either short-passive or long-active.
The EOD symbol is always passive.
The EOF symbol extends the EOD symbol and is also passive.

The bus will ALWAYS change state between symbols.

Regards
Paul

[ls1tools]

Paul, your a life saver. I have autotap V1.. When I get the time I'm going to start playing with some of this stuff.

Here's a question. Does the B&B device buffer the data where I need to request a read from it to obtain my requested info or do I have to just listen openly on com port?

Thanks again!

- Keith

The info I posted was for the AutoTap V2 interfaces - the V1 interface is a little different.
Briefly - here's the same VIN command using the V1 interface:

$01,$6C,$10,$F1,$3C,$01,$00,$00,$00,$00,$00,$05,$0F,$00,$04
$01,$6C,$F1,$10,$7C,$01,$00,$31,$47,$31,$59,$0B,$59,$00,$04

$01,$6C,$10,$F1,$3C,$02,$00,$00,$00,$00,$00,$05,$0F,$00,$04
$01,$6C,$F1,$10,$7C,$02,$33,$32,$47,$33,$33,$0B,$35,$00,$04

$01,$6C,$10,$F1,$3C,$03,$00,$00,$00,$00,$00,$05,$0F,$00,$04
$01,$6C,$F1,$10,$7C,$03,$31,$30,$33,$36,$32,$0B,$39,$00,$04

Send:
First byte is always $01.
Next 10 bytes is data to be sent to vehicle.
11th byte is number of data bytes to send.
12-14 are V1 interface flags.

Recv:
First byte is always $01.
Next 10 bytes is data received from vehicle.
11th byte is number of data bytes received.
12th byte is data received from vehicle. (11 bytes in total)
13-14 are V1 interface flags.

The V1 interface strips the J1850 CRC byte.
There is no checksum byte for the V1 interface.

The SAE specs say that on-board modules may return multiple responses. This means that after you send a request you need to "listen" on the com port until ALL responses have been received. If 100ms elapse with no data reeceived then no more data should be expected.

It also filters out responses so only responses to your command will be received. It uses the Mode byte - in the example above the mode byte is $3C - only repsonses that have $7C (mode+$40) will be passed through.

Regards
Paul

[Keith@HPTuners]

Once again great info Paul.

I'm not to interested in the V1 device as it does not support 4x data transfer mode..

JPatrick of autotap stated that the only difference between the LDVXXXP1 and the Autotap V2 device is the model # they report... which means if I do not check for model #, any software I come up with should work on both equally.

I believe it was you who stated the autotap device was only capable of so many frames per second and may not be fast enough for flash read/write. Do you know anything more in regards to the VIA device being flash capable? If I do decide to pick up a device and start programming, I'd like the device I chose to be able to support our goal.

Just out of curiosity, anyone know if carputing modifies an existing device or uses one custom built for their needs?

- Keith

[texanmutt]

Just out of curiosity, anyone know if carputing modifies an existing device or uses one custom built for their needs?

Andrew from akmcables.com makes the cable for carputing. Here is some info on his web page about obdII..

http://akmcables.com/obdii.htm

[ls1tools]

Once again great info Paul.

I'm not to interested in the V1 device as it does not support 4x data transfer mode..

JPatrick of autotap stated that the only difference between the LDVXXXP1 and the Autotap V2 device is the model # they report... which means if I do not check for model #, any software I come up with should work on both equally.

I believe it was you who stated the autotap device was only capable of so many frames per second and may not be fast enough for flash read/write. Do you know anything more in regards to the VIA device being flash capable? If I do decide to pick up a device and start programming, I'd like the device I chose to be able to support our goal.

- Keith

I do not believe 4x mode is a pre-requisite for reflashing. I believe the Tech2 does it just for speed/convenience.

There is no issue with the frame rate of the B&B interface. The only problem I can see is that it only allows 32 bytes per message. The PCM loader program *may* require larger chunks of data to be sent/receieved per message.

I have tried (not very seriously yet) to see if I could get the B&B interface to dump out the flash - but no success yet.

Paul

[ls1tools]

Tech-2 is straight VPW. If you did snoop such a device though you could obtain security keys that would be needed for the B&B device.

You can snoop the VPW bus using the AT V1 interface like this:

Snooping ignition on sequence....
You can send any command as long as the bold byte is $07. $07 = no filtering.

14:54:35.988: Send: $01,$6C,$10,$F1,$22,$00,$00,$01,$00,$00,$00,$07,$07,$00,$04
14:54:36.008: Recv: $01,$6C,$10,$F1,$22,$00,$00,$01,$00,$00,$00,$07,$0 0,$00,$04
14:54:36.018: Recv: $01,$6C,$F1,$10,$7F,$22,$00,$00,$01,$31,$00,$09,$0 0,$00,$04
14:54:36.118: Recv: $01,$49,$92,$10,$01,$00,$00,$00,$00,$00,$00,$04,$0 0,$00,$04
14:54:36.128: Recv: $01,$E9,$2A,$10,$3C,$00,$00,$00,$00,$00,$00,$04,$0 0,$00,$04
14:54:36.419: Recv: $01,$8A,$EA,$10,$A0,$82,$00,$00,$00,$00,$00,$06,$0 0,$00,$04

Regards
Paul

[Keith@HPTuners]

All the pieces are starting to fall into place. I now understand the difference between an RS232 signal and VPW. I am also understanding more about how the actual communications take place.

Ok.. hypothetically speaking here...

Some person could flash a pcm with a tech-2... and tap into the class-2 wire at the same time with a V1 interface and just send that command to the V1 interface and the data will just flow back indefinately? Anything that flows over the VPW bus as long as its at 1x rate?


Regarding the V2 cable and 32 byte max message. If one were to "borrow" GM's loader programs chances are this person would need a different cable setup. GM probably uses larger data chunks.

Paul, I'm going to break down your snoop line just for clarification on my part. Please let me know how I'm doing.

$01,$6C,$10,$F1,$22,$00,$00,$01,$00,$00,$00,$07,$0 7,$00,$04

$01 First byte is always $01
$6C Send Message
$10 To PCM
$F1 From Scantool

Then going by what Hera posted, $22 is request diagnostic data by PID.
We getting PID $01??
$07 because we sent 7 bytes.
$07 no filtering
Then the last 2 bytes are autotap V1 interface flags.

- Keith

[ls1tools]

Yes, but start the snooper software before doing anything with tech2 or the "command" that you send may interfere.

It won't snoop 4x mode.

The V1 cable will not support flashing - I'm 99.999% sure of that.

The full breakdown:
(By the way, the command I sent was not a valid command, PID $00,$00 is invalid for mode $22)

The scan tool sent this data
14:54:35.988: Send: $01,$6C,$10,$F1,$22,$00,$00,$01,$00,$00,$00,$07,$07,$00,$04

The AT V1 received it's own echo and returned it. This would be used by the interface for bit arbitration. If any of the echoed bits differ from the orginal message that means another node has priority and the interface must cease transmitting before the next bit.
14:54:36.008: Recv: $01,$6C,$10,$F1,$22,$00,$00,$01,$00,$00,$00,$07,$00,$00,$04

The PCM responded with mode $7F (Error), response code $31=Request out of range.
14:54:36.018: Recv: $01,$6C,$F1,$10,$7F,$22,$00,$00,$01,$31,$00,$09,$00,$00,$04

The $6C is a bit mapped field:
Bits 7,6 and 5 are priority 0=low, 7=high
Bit 4 is header style (0=3 byte header-GM, 1=1 byte header-??)
Bit 3 is In Frame Response (0=Required-Ford, 1=Not allowed-GM)
Bit 2 is addressing mode (0=Physical, 1=Functional)
Bit 1,0 is message type: (depending on bit 2 and 3 see below)

Bit 3 2 1 0
-----------
Functional
1 0 0 0 Function
1 0 0 1 Broadcast
1 0 1 0 Query
1 0 1 1 Read
Physical
1 1 0 0 Node to Node
1 1 0 1 Reserved
1 1 1 0 Reserved
1 1 1 1 Reserved

The $10 and $F1 are node addresses as explained before.

The $22 is get data by PID
The PID is two bytes $00,$00 (Which is not valid for mode $22)
The $01 is requests that the PID data be sent just once.

The $07 for 7 bytes
The other $07 is only for the interface - it tells the interface to allow ALL messages to be passed back to the scan tool. Use $0F to filter messages properly.

The last two bytes are always $00 and $04. (for AT1)

I won't go into all the other messages but they are mostly initialisation data between the PCM and other nodes on the bus.
For example the instrument cluster needs to know the ECT and fuel remaining so they can be displayed on the dash.

Regards
Paul

[RoboGeek]

are packet sizes the problem? If so I'll research different chips to use to make sure we can pass as large as we want. Right now I'm looking at using the cable interface as a straight vpw/binary converter with no buffering or protocols. That would allow the laptop to be the master of all that stuff, rather than having to have a cable with communications protocols built into it. Just seems more logical that way.. and easier to modify.

Am I on the wrong track here? Or are you guys more comfortable using a pre-built cable?

[Keith@HPTuners]

From what I'm told, flash programming blocks can be as large as 8192 according to the standard.

Using GM loaders with off-shelf cables will most likely result in buffer overflows.

[Hera]

Okay, now that the holidays are over, let's hit this up..

I am currently building a pass thru for my programmer, so I can dump out the data sent. I do need to order the BBLVD, but that is gonna have to wait til after christmas.

The programmer I have is the Ease Diagonistics GM aftermarket Programmer. It uses a db25 connector to the OBDII port on the car.. So I just have to figure out which connectors in the db25 connector goes to which pin in the OBDII connector.. not very hard...

Anyway, that is where I am at.. I have an ELMSCAN from scantool.net, and I have alex peppers scan tool...

I am gonna experiment with alex peppers scan tool to see if I can use it for sniffing.. I guess I should email him and see if I can use a simple terminal program to access the device for sniffing.

OKay, wish me luck

Kevin