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

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

 

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[4128];
} 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.

SAE J2534 Pass-Thru API,布布扣,bubuko.com

SAE J2534 Pass-Thru API