Manual ISO15765 Connection Tutorial

Abstract

Describes how to use free open source Drew Tech Tool for J2534 in order to setup a ISO 15765-2 / ISO TP connection to the engine control unit (ECU). Diesel or petrol ECU model does not matter. Once set up, one can send and receive messages without any additional software, no programming skills necessary.

IMPORTANT: CAN/ISO15765 capable interface hardware plus J2534 driver is required!

I am using Tactrix OpenPort 2.0 in this example.

ISO15765 is a convenient transport layer on top of raw CAN. Basically it allows larger message data, not limited to 8 bytes of raw CAN. Under the hood it uses raw CAN, multiple of such raw frames if needed. All modern Subaru ECUs seem to support this protocol as it is being used for OBDII, SSM2 via CAN and the new Euro5 (diesel) diagnostic protocol.

Drew Technologies has good infos regarding J2534 on their site: http://www.drewtech.com/support/passthru.html

Unfortunately, some cheap devices don’t come with J2534 drivers although they can handle CAN/ISO15765. Using these requires proprietary commands, meaning special software support.

Content

Drew Tech Tool Software installation

Basically it is a generic tool, uses J2534 API under the hood, supports many protocols.

Visit http://www.drewtech.com/downloads/index.html
In category “SUPPORT APPLICATIONS” look for “J2534-1 Bus Analysis Tool” (not sure why they chose this link text), download and install Windows installer file:
Drew Technologies Tool for J2534-1 API v1.07.msi (9 MB)
License is GPLv2+, besides executable binaries the msi also includes Visual Basic source code.

Step 1: Select Device, Open

Tab “Connect”, top left frame.
Note: If you see text like “No information found in the registry” and buttons are disabled, close the app and use “Run as administrator” method!
Select desired hardware interface, should be recognized if your J2534-device had been installed correctly.
Path to DLL is just for info, lists the J2534 driver DLL location.
Click button “Load DLL”

Top right frame. Click button “Open” (API call PassThruOpen)

After “Open” the tool automatically does a PassThruReadVersion to retrieve version information, displays the results in bottom left frame.

Step 2: Protocol Properties

Bottom right frame.

Select ISO15765.
Check baudrate and connect flags. Screenshot shows needed values which are defaults.
We need 500,000 baud (Subaru uses 500 kbit/s on high speed CAN bus).
For ISO15765 we don’t need special connect flags, therefore hexadecimal 0x0 = zero = all bits are zero.
Click button “Connect” (PassThruConnect).
By the way, the statusbar shows latest command result, should be OK. You can also look into tab “Results” which displays a full log of all commands done so far.

Step 3: Config

Tab “Config”. Entries show current settings, the tool has already requested this info (PassThruIoctl GET_CONFIG).
Not important, but I usually work with LOOPBACK=OFF, don’t want to receive loopback messages from the interface device, I know what data I have sent anyway. Might be useful for debugging in case of troubles though.
LOOPBACK: 0 = OFF, 1 = ON
Click button “Set”
Tool does PassThruIoctl SET_CONFIG, then GET_CONFIG to display actual values.

Step 4: Filters

Tab “Filters”.
Very important – without a filter set up you won’t receive any response, the device would ignore anything received from the control unit.
For ISO15765 a flow control filter is needed which specifies CAN-IDs. Standard CAN-IDs use 4 bytes each.

Mask: FF FF FF FF, means device should check first 4 bytes which make up required CAN-ID. Independent of following CAN-IDs

Pattern: Target CAN-ID. Standard ECU CAN-ID is 0x7E8 → 00 00 07 E8, TCU would be 0x7E9

Flow Control: Tester/interface device CAN-ID. ECU 0x7E8 usually listens to 0x7E0 → 00 00 07 E0.

Filter: set type to “Flow”


For ISO15765 we also need additional message flags (Tx Flags). Put cursor inside Tx Flags entry, right click and click “edit flags” to get helper dialog, see below.
Turn on ISO15765_FRAME_PAD and click button “Set”, resulting in value 0x40 (bit 6 set). You could also just type in 0x40 in the entry. Later when sending messages, this same flag is needed on each message, too.

Don’t forget to click “Apply”, see picture before, to acually set the filter (PassThruStartMsgFilter).

Step 5: Messages

Tab “Messages”. Now that everything has been set up we can try to communicate with the control unit.
Top right button column.
“Rate” entry: Specifies delay time in milliseconds for automatic read-message (PassThruReadMsgs) polling. Since we type and send messages manually, fast polling makes no sense. I recommend 1000 = 1 second or more. Otherwise the log in tab “Results” will grow fast, making it harder to use.
Click “Start” (toggles to “Stop”) button to run or stop the automatic read loop. Must be started in order to display received messages. Can be started later, the interface device will store (a limited amount of) incoming messages anyway.

Message content

IMPORTANT: Tx flags (entry to the left of msg scratch pad): Constant, same as in flow control earlier,0x40 = ISO15765_FRAME_PAD.

Scratch Pad entry: type message to be sent as hex bytes in here.
IMPORTANT: First 4 bytes have to match tester CAN-ID, the one specified in flow control filter. Here: 00 00 07 E0.
After those CAN-ID bytes, the actual message content follows. So 5th byte = 1st payload byte is sort of command byte. ‘AA’ is SSM2Init-Request via CAN, ‘A8’ means read-(SSM2)-address etc.

Once ready, click button “Send” (PassThruWriteMsgs). On OP2.0 device there should be green (send) and red LEDs (receive) flashing shortly.

SSM2 via CAN examples

For protocol details see page SSM2 via CAN.

Example in following screenshot shows SSM2-Init-request, with response received from a diesel ECU.

Success response command byte = request command byte + 0x40 (bit 6). Examples: AA → EA, A8 → E8 etc.

There are additional status messages containing CAN-ID bytes that prepend the actual response data msg (last one). These indicate that the msg had been sent and an incoming (multi-frame) msg transfer had commenced.

Cleared received msg list, doing command ‘A8’, reading SSM2 address 0x000008 = Coolant Temp. (x-40 [°C])

Response data byte is 0x40 = decimal 64, – 40 → 24 °C coolant temperature.

Error response example: Last msg sent was A8 00 00 03 50 meaning read SSM2 address 0x350. Diesel ECUs so far only support SSM2viaCAN addresses 0x000000 ≤ x ≤ 0x00034F. Since 0x350 is already outside allowed range we get an error msg. As seen in screenshot, Negative Response Code (NRC, sort of error code) for this error type is 0x12 obviously.

If you read SSM2 addresses which have no supported effect, depending on car model and ECU ROM, e.g. 0x300, you should get data byte ‘FF’, so no error code.

Step 6: Disconnect protocol

Tab “Connect”
Bottom right frame, click button “Disconnect” (PassThruDisconnect, current channel). You could set up a new/different protocol.

Step 7: Close connection

Tab “Connect”
Inside top right frame, press button “Close” (PassThruClose). PassThruClose also disconnects all open channels in case you did not do this already. Now you can quit the application or select a different J2534-device and start all over.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s