SAE J2534 Pass-Thru API

Connects to the OBDII J1962 DLC and supports the following protocols.

1 CAN2 Single Wire
2 J1850PWM+ , J1850VPW
3 CAN2+
6 CAN+ (CAN-C only), SCI A Engine, 5v-20v out
7 ISO-9141 K-line, SCI A Engine, SCI A Trans, SCI B Engine
9 SCI B Trans, 5v-20v out or short-to-ground
10 J1850PWM-
11 CAN2- 5v-20v out
12 SCI B Engine 5v-20v out or short-to-ground
14 CAN- (CAN-C only), SCI A Trans 5v-20v out
15 ISO L Line, SCI B Trans, Short-to-ground

The PassThru device manufacturer supplies the hardware appliance and cable that connects to and communicates with the vehicle network.

The physical interface to the vehicle network is the SAE J1962 connector, which supports the various vehicle serial data protocols.

The following network layer protocols are supported:

ISO 9141
ISO 14230-4(KWP2000, Keyword Protocol)
SAE J1850 41.6 KBPS PWM(Pulse Width Modulation)
SAE J1850 10.4 KBPS VPW(Variable Pulse Width)
CAN(Controller Area Network, ISO 11898)
ISO 15765-4(CAN)
SAE J2610 DaimlerChrysler SCI(Serial Communications Interface)

J2534-1: Recommended Practice for Pass-Thru Vehicle Programming Last published version 12/2004

J2534-2: Optional Pass-Thru Features Last published version 04/2010

J2534-3: Conformance Test Cases for an SAE J2534-1 Device No published document

SAE J2534-1

defines an Application Program Interface (API) that can be used by Vehicle Manufacturers for reprogramming emission related modules.
This interface also includes some capabilities that may not be required for reprogramming,
but allows the interface to be used for other purposes without placing a significant burden on the interface manufacturers.

SAE J2534-2

defines optional features that takes advantage of the J2534-1 framework.
It allows the interface (J2534) to be used for other purposes and includes features that are above and beyond emission related reprogramming needs.
Many OEM’s wanted a standard for reprogramming other modules not “Emission Related”.
Those instructions were added into -2. It also expands the scope of what a J2534 device can do. (ie: Diagnostics)

SAE J2534-3

defines a set of conformance test cases, which can be used to check an interface’s compliance with SAE J2534-1 Conformance test cases are planned for J2534-2 features
also Some preliminary work has been done on the J2534-1 conformance test cases.
No work has been initiated for the J2534-2 conformance test cases.
There is no published standard yet.

J2534 framework includes application interfaces for the following functionality:

Network Initialization
Basic Send and Receive
Periodic Transmission Capability
Message Filters
Generic IO Control
Protocol Specific IO Control
Programming Voltage Supply
Other Utility Functions

Protocols Supported by a fully compliant SAE J2534-1 Device

J1850 VPW (GM Class2, Chrysler OBD)
J1850 PWM (Ford SCP)
High Speed CAN ISO 15765-4 (Diag. On CAN)
ISO 14230 (KWP)
ISO 9141-2
Chrysler SCI

Additional Protocols Currently Supported by the SAE J2534-2 Specifications

SAE J1939
SAE J1708
Single Wire CAN
GM UART
UART Echo Byte
Ford MS-CAN
Honda Diag-H
TP 2.0
Fault Tolerant CAN

6.5.1 ISO 9141

The following specifications clarify and, if in conflict with ISO 9141, override any related specifications in ISO 9141:

a. The maximum sink current to be supported by the interface is 100 mA. 
b. The range for all tests performed relative to ISO 7637-1 is –1.0 to +40.0 V. 
c. The default bus idle period before the interface shall transmit an address, shall be 300 ms. 
d. Support following baud rate with ±0.5% tolerance: 10400. 
e. Support following baud rate with ±1% tolerance: 10000. 
f. Support following baud rates with ±2% tolerance: 4800, 9600, 9615, 9800, 10870, 11905, 12500, 13158, 13889, 14706, 15625, and 19200. 
g. Support other baud rates if the interface is capable of supporting the requested value within ±2%. 
h. The baud rate shall be set by the application, not determined by the SAE J2534 interface. The interface is not required to support baud rate detection based on the synchronization byte. 
i. Support odd and even parity in addition to the default of no parity, with seven or eight data bits. Always one start bit and one stop bit.

j. Support for timer values that are less than or greater than those specified in ISO 9141 (see Figure 30 in Section 7.3.2). 
k. Support ability to disable automatic ISO 9141-2 / ISO 14230 checksum verification by the interface to allow vehicle manufacturer specific error detection. 
l. If the ISO 9141 checksum is verified by the interface, and the checksum is incorrect, the message will be discarded. 
m. Support both ISO 9141 5-baud initialization and ISO 14230 fast initialization. 
n. Interface shall not adjust timer parameters based on keyword values.

6.5.2 ISO 14230-4 (KWP2000)

The ISO 14230 protocol has the same specifications as the ISO 9141 protocol as outlined in the previous section. 
In addition, the following specifications clarify and, if in conflict with ISO 14230, override any related specifications in ISO 14230:

a. The pass-thru interface will not automatically handle tester present messages. The application needs to handle tester present messages when required. 
b. The pass-thru interface will not perform any special handling for the $78 response code. 
Any message received with a $78 response code will be passed from the interface to the application. 
The application is required to handle any special timing requirements based on receipt of this response code, including stopping any periodic messages.

6.5.3 SAE J1850 41.6 KBPS PWM (PULSE WIDTH MODULATION)

The following additional features of SAE J1850 must be supported by the pass-thru device:

a. Capable of 41.6 kbps and high speed mode of 83.3 kbps. 
b. Recommend Ford approved SAE J1850PWM (SCP) physical layer

6.5.4 SAE J1850 10.4 KBPS VPW (VARIABLE PULSE WIDTH)

The following additional features of SAE J1850 must be supported by the pass-thru device:

a. Capable of 10.4 kbps and high speed mode of 41.6 kbps 
b. 4128 byte block transfer 
c. Return to normal speed after a break indication

6.5.5 CAN

The following features of ISO 11898 (CAN) must be supported by the pass-thru device:

a. 125, 250, and 500 kbps 
b. 11 and 29 bit identifiers 
c. Support for 80% ± 2% and 68.5% ± 2% bit sample point 
d. Allow raw CAN messages. This protocol can be used to handle any custom CAN messaging protocol, including custom flow control mechanisms.

6.5.6 ISO 15765-4 (CAN)

The following features of ISO 15765-4 must be supported by the pass-thru device:

a. 125, 250, and 500 kbps 
b. 11 and 29 bit identifiers 
c. Support for 80% ± 2% bit sample point 
d. To maintain acceptable programming times, the transport layer flow control function, as defined in ISO 15765-2, must be incorporated in the pass-thru device (see Appendix A). 
If the application does not use the ISO 15765-2 transport layer flow control functionality, the CAN protocol will allow for any custom transport layer. 
e. Receive a multi-frame message with an ISO15765_BS of 0 and an ISO15765_STMIN of 0, as defined in ISO 15765-2. 
f. No single frame or multi-frame messages can be received without matching a flow control filter. 
No multi-frame messages can be transmitted without matching a flow control filter. 
g. Periodic messages will not be suspended during transmission or reception of a multi-frame segmented message.

6.5.7 SAE J2610 DAIMLERCHRYSLER SCI

Reference the SAE J2610 Information Report for a description of the SCI protocol.

When in the half-duplex mode (when SCI_MODE of TxFlags is set to {1} Half-Duplex), every data byte sent is expected to be "echoed" by the controller. 
The next data byte shall not be sent until the echo byte has been received and verified. 
If the echoed byte received doesn't match the transmitted byte, or if after a period of T1 no response was received, the transmission will be terminated. 
Matching echoed bytes will not be placed in the receive message queue.

What is an API?

An API (Application Programming Interface) is a 'rendezvous point' between two pieces of software.

For example, any Windows application (such as MS Word and Photoshop) can print to any printer.

How is this possible? The application and the printer driver communicate via an API. Even though each printer has different hardware,

all printer drivers 'look the same' to Windows applications.

You are free pick any printer based on your preferences (color, size, durability, cost, speed) without worrying about software incompatibilities.

In a similar vein, the J2534 API makes all "car communications" hardware look the same.

The Software

The EPA is forcing car manufacturers to release software that updates the firmware on their cars.

The application must run on Windows and use the J2534 API to talk to the car.

Anyone can buy this software, even individual car enthusiasts.

The software must be sold 'for a reasonable price', which will probably be a few hundred dollars.

The Hardware

A J2534 device plugs into a cars' OBD connector on one side, and a computer on the other side.

These devices are not made by car manufacturers, but by any company that sees an opportunity.

Under the hood, the device must speak a myriad of different vehicle protocols (ISO9141, J1850VPW/PWM, CAN, etc.)

used by the different manufacturers. Each protocol has different voltage and timing requirements,

so this is no trivial task. Fortunately, each device comes with a software driver that implements the J2534 API.

Since the driver invisibly handles communication to the device, application software

writers don't have to worry about the connection details or low-level car protocols.

http://www.drewtech.com/support/J2534/errorcodes.html

All the error codes returned by J2534 API are listed below:

Value	Name	Description
0x00	STATUS_NOERROR	Function completed successfully.
0x01	ERR_NOT_SUPPORTED	Function option is not supported.
0x02	ERR_INVALID_CHANNEL_ID	Channel Identifier or handle is not recognized.
0x03	ERR_INVALID_PROTOCOL_ID	Protocol Identifier is not recognized.
0x04	ERR_NULL_PARAMETER	NULL pointer presented as a function parameter, NULL is an invalid address.
0x05	ERR_INVALID_IOCTL_VALUE	Ioctl GET_CONFIG/SET_CONFIG parameter value is not recognized.
0x06	ERR_INVALID_FLAGS	Flags bit field(s) contain(s) an invalid value.
0x07	ERR_FAILED	Unspecified error, use PassThruGetLastError for obtaining error text string.
0x08	ERR_DEVICE_NOT_CONNECTED	PassThru device is not connected to the PC.
0x09	ERR_TIMEOUT	Timeout violation. PassThru device is unable to read specified number of messages from the vehicle network. The actual number of messages returned is in NumMsgs.
0x0A	ERR_INVALID_MSG	Message contained a min/max length, ExtraData support or J1850PWM specific source address conflict violation.
0x0B	ERR_INVALID_TIME_INTERVAL	The time interval value is outside the specified range.
0x0C	ERR_EXCEEDED_LIMIT	The limit (ten) of filter/periodic messages has been exceeded for the protocol associated the communications channel.
0x0D	ERR_INVALID_MSG_ID	The message identifier or handle is not recognized.
0x0E	ERR_DEVICE_IN_USE	The specified PassThru device is already in use.
0x0F	ERR_INVALID_IOCTL_ID	Ioctl identifier is not recognized.
0x10	ERR_BUFFER_EMPTY	PassThru device could not read any messages from the vehicle network.
0x11	ERR_BUFFER_FULL	PassThru device could not queue any more transmit messages destined for the vehicle network.
0x12	ERR_BUFFER_OVERFLOW	PassThru device experienced a buffer overflow and receive messages were lost.
0x13	ERR_PIN_INVALID	Unknown pin number specified for the J1962 connector, or resource is already in use.
0x14	ERR_CHANNEL_IN_USE	An existing communications channel is currently using the specified network protocol.
0x15	ERR_MSG_PROTOCOL_ID	The specified protocol type within the message structure is different from the protocol associated with the communications channel when it was opened.
0x16	ERR_INVALID_FILTER_ID	Filter identifier is not recognized.
0x17	ERR_NO_FLOW_CONTROL	No ISO15765 flow control filter is set, or no filter matches the header of an outgoing message.
0x18	ERR_NOT_UNIQUE	An existing filter already matches this header or node identifier.
0x19	ERR_INVALID_BAUDRATE	Unable to honor requested Baud rate within required tolerances.
0x1A	ERR_INVALID_DEVICE_ID	PassThru device identifier is not recognized.

 

API Functions
PassThruOpen
PassThruClose
PassThruConnect
PassThruDisconnect
PassThruReadMsgs
PassThruWriteMsgs
PassThruStartPeriodicMsg
PassThruStopPeriodicMsg
PassThruStartMsgFilter
PassThruStopMsgFilter
PassThruSetProgrammingVoltage
PassThruReadVersion
PassThruGetLasError
PassThruIoctl

PassThruScanForDevices 
  PassThruGetNextDevice 
  PassThruGetDeviceContent 
  PassThruLogicalConnect
  PassThruLogicalDisconnect
  PassThruQueueMsgs

IOCTLS
GET_CONFIG
SET_CONFIG
READ_VBATT
FIVE_BAUD_INIT
FAST_INIT
CLEAR_TX_BUFFER
CLEAR_RX_BUFFER
CLEAR_PERIODIC_MSGS
CLEAR_MSG_FILTERS
CLEAR_FUNCT_MSG_LOOKUP_TABLE
DELETE_FROM_FUNCT_MSG_LOOKUP_TABLE
READ_PROG_VOLTAGE

http://www.drewtech.com/support/J2534/index.html

The following pages explain DrewTech's implementation, and should be useful to end-users who want to program with our DLL:

Category	Name	Description
Setup	PassThruOpen	Initialize and connect to a CarDAQ
	PassThruClose	Disconnect from a CarDAQ
	PassThruConnect	Connect to a vehicle network
	PassThruDisconnect	Disconnect from vehicle network
	PassThruIoctl	Fast init sequence (ISO 9141)
	PassThruIoctl	Five baud init sequence (ISO 9141)
	PassThruIoctl	Report configuration parameter
	PassThruIoctl	Set configuration parameter
	PassThruIoctl	Add functional address (J1850PWM)
	PassThruIoctl	Delete functional address (J1850PWM)
	PassThruIoctl	Clear functional address table (J1850PWM)
Status	PassThruReadVersion	Report version information
	PassThruGetLastError	Describe most recent error
	PassThruIoctl	Read vehicle battery voltage
Reading	PassThruReadMsgs	Receive network message(s)
	PassThruStartMsgFilter	Apply a network message filter
	PassThruStopMsgFilter	Stop a network message filter
	PassThruIoctl	Halt all network message filters
	PassThruIoctl	Clear receive buffer
Writing	PassThruWriteMsgs	Transmit network message(s)
	PassThruStartPeriodicMsg	Continuously transmit message(s)
	PassThruStopPeriodicMsg	Stop transmitting a message continuously
	PassThruIoctl	Halt all continuous messages
	PassThruIoctl	Clear transmit queue
Reflashing	PassThruSetProgrammingVoltage	Apply voltage on J1962 pin
	PassThruIoctl	Report programming voltage
Analog	PassThruIoctl	Read most recent analog sample
	PassThruIoctl	Read stored analog sample(s)

https://github.com/hackingvolvo/SardineCAN-Win32/tree/master/Sardine

https://github.com/hackingvolvo/SardineCAN-Win32/blob/master/Sardine/j2534_v0404.h

https://code.google.com/p/j2534-logger/

 

https://code.google.com/p/j2534-logger/source/browse/trunk/ptshim32/j2534_v0404.h

 

 

 

8. Message Structure
The following message structure will be used for all messages (Transmit, Receive, Filters, and Periodics)
and indications. The total message size (in bytes) is the DataSize, and includes header bytes, ID bytes,
and data bytes. For consistency, all interfaces should detect only the errors listed for each protocol in the
following sections when returning ERR_INVALID_MSG.
8.1 C / C++ Definition

typedef struct {
  unsigned long ProtocolID;
  unsigned long RxStatus;
  unsigned long TxFlags;
  unsigned long Timestamp;
  unsigned long DataSize;
  unsigned long ExtraDataIndex;
  unsigned char Data[];
} PASSTHRU_MSG;

SAE J2534-2

SAE J2534-1 defines a standard vehicle network interface that can be used to reprogram emissionrelated control modules.

However, there is a need to support vehicles prior to the 2004 model year as well as non-emission related control modules.

The SAE J2534-2 document meets these needs by detailing extensions to an SAE J2534-1 interface.

Together, these extensions provide the framework for a common interface to protect the software investment of the Vehicle OEMs and Scan Tool manufacturers.

Only the optional features will be described by this document. Unless otherwise noted it is expected that these features are added

to a fully compliant interface adhering to the December 2004 publication of SAE J2534-1.

Only the optional features will be described by this document. Unless otherwise noted it is expected that these features

are added to a fully compliant interface adhering to the December 2004 publication of SAE J2534-1.

Extending the protocols supported by SAE J2534-1 this document adds two new types of ProtocolIDs.

1. ProtocolIDs with the suffix ‘_PS’ for connecting to a vehicle, via the SAE J1962 connector using the technique outlined in the section titled ‘SAE J1962 Pin Selection’.
2. Generic ProtocolIDs, with the suffixes ‘_CH1’ through ‘_CH128’ for protocols that terminate at a vendor specific connector on the device. See the section titled ‘Access to Additional Channels’.

5. SAE J1962 Pin Selection

5.1 Scope of the SAE J1962 Pin Selection Optional Feature

This section identifies the pin selection mechanism for ProtocolIDs that have the ‘_PS’ suffix.

The API extensions detailed here describe the method of specifying the SAE J1962 pin(s) to which the selected protocol should be connected.

While the API allows for all combinations of protocol / pin assignments, the actual combinations implemented are vendor specific.

5.2 Pass-Thru System Requirements

5.2.1 PIN USAGE

The set of pins that can be switched is dependant on the set of optional protocols supported by the interface.

A new SET_CONFIG parameter is defined for the application to specify the pins to be switched.

5.3 Win32 Application Programming Interface

5.3.1 API FUNCTIONS – OVERVIEW

The new ProtocolIDs with ‘_PS’ suffix indicates that the protocol physical layer is not connected to the SAE J1962 pins on PassThruConnect.

A new Ioctl configuration parameter is also added, that allows connection of a physical layer to specific SAE J1962 pins.

For support of SAE J2534-1 protocols on different pins than those defined in SAE J2534-1, new ProtocolIDs are assigned to enable the pin-switching feature as defined in Figure 1:

As an example, in order to utilize a CAN channel connected to Pins 3 and 11 (often used for Medium Speed CAN network), the new CAN_PS ProtocolID is used in PassThruOpen.
Note that the SAE J2610 (DaimlerChrysler SCI) protocols are consolidated into a single new ProtocolID, J2610_PS.
However the SAE J2534-1 SCI protocols shall continue to be supported as defined in SAE J2534-1.
New SAE J2534-2 optional feature protocols use the ProtocolIDs defined in Figure 2: