Tag Archives: SSM2

Log Graphs 1

Specification

Car: 2009 Impreza 2.0 Turbo Diesel, 110 kW / 148 hp / 150 PS, European domestic market, Euro 4 spec.

Important: Newer Boxer Diesel generations (Euro 5/6) may show different behaviour!

ECU firmware: patched ROM for unlimited logging, otherwise stock.
Protocol: SSM2 via CAN
More than 120 items had been logged, plenty of RAM variables (*) plus standard SSM2 items at roughly 170 ms interval.

Graphs

I prepared two graph images plotting some interesting parameters, click picture for full resolution:


Image 1/2

loggraphs1_p1


Image 2/2

loggraphs1_p2

Additional details

… at specific time positions:

#1: State before active regeneration

Time @ ~ 33 ½ min
Cruise Control: active
Vehicle Speed*: 110 km/h
Engine Speed: 2300 rpm
Gear: 5
Coolant Temperature: 93 °C
Injections: 2 (pre + main)
Soot Accumulation Ratio: 64 %
DPF Pressure Difference: ~ 5 kPa
Exhaust Gas Temperature (EGT) Catalyst Inlet: 345 °C
EGT DPF Inlet: 370 °C
Intake Air Amount: 430 mg/cyl
Mass Air Flow: 33.8 g/s
Manifold Absolute Pressure (MAP)*: 126 kPa
Inlet Air Temperature: 25 °C
Manifold Air Temperature: 48 °C
Fuel Temperature: 58 °C
Throttle Opening Angle: 79 deg
EGR Valve Opening Angle: 38 deg
Final Oil Dilution Rate*: -1.9 mg/s (evaporation)
Oil Dilution Amount: 282.0 g (4.6 %)

#2: Soot 65%, preparing for DPF regeneration

@ 33 ¾ min
Soot Accumulation Ratio* reaches 65%, this triggers active regeneration preparations. Note: I am referring to the actual RAM value, diagnostic parameter may indicate 65% earlier due to rounding.
Apparently ECU now does 3 injections (pre + main + after) when power demand is high enough, no post injections yet

#3: Active Regen ON

@ 34:04; = 20 seconds after #2, DPF Regeneration Switch turns ON
EGR valve closes instantly, 0 deg
Manifold Air Temperature dropping
Boost Control opens VGT immediately, from 52 to 25%
Manifold Absolute Pressure* dropping
pilot-injection kicks in, 2 injections (pilot C + main)
post-injections begin to fade in but not active yet

#4: Post-Injections

@ 33 seconds after #2, post-injections A + B become operational (injection amount > 0)
oil dilution rising
EGTs climbing
Manifold Absolute Pressure*: 75 kPa (~ 25 below ambient), varying, stays below ambient most of the time during regen at low power demand
EGT Catalyst Inlet: 340 °C
EGT DPF Inlet: 320 °C
injections: 4 (pilot C + main + post A + post B)

#5: Coasting Fuel Cut-Off During Regen

Example @ 35:12
EGR valve opens instantaneously, 70 deg; EGR behaves rather digitally during regen – either fully closed (0 deg, for max EGT) or max opened (70 deg, less fresh air)
Throttle Opening Angle: rising up to 31 deg
injections: 0
Fuel Consumption*: 0 mm³/s
oil dilution going down slowly due to estimated evaporation
EGT Catalyst Inlet: decreases fast, EGT at DPF inlet (> 600 °C) follows with a delay
Engine Speed: gear change from 5th to 6th to reduce engine braking effect

#6: Idling with Active Regen ON

@ 45:30
Engine Speed: 800 rpm
Post A Injection Amount*: 0
Post B Injection Amount*: ~ 8 mm³/st
Apparently while idling the ECU prefers the 2nd post-injection (“B”), otherwise during driving it’s rather mixed
Final Oil Dilution Rate: ~ 20 mg/s (medium)
Boost Control: 25 % (VGT fully open)
Manifold Absolute Pressure*: 74 kPa
Throttle Opening Angle: 5.5 deg
EGR Valve Opening Angle: 0 deg
Intake Air Amount: 370 mg/cyl
Mass Air Flow: 9.8 g/s

#7: DPF Regeneration OFF

@ 46:15, decision is based on elapsed time from #2, achieved soot level does not matter (!)
DPF Regeneration SW had been ON for 12.2 minutes
all post-injections off
Oil Dilution Amount*: 299.6 g (4.9 %) = + 0.3 % during regeneration
EGR back to normal operation
Boost Control: 65 % instantly (max speed, spooling up turbo)
MAP rising
EGT Catalyst Inlet: 270 °C
EGT DPF Inlet: 490 °C

Advertisements

Oil Dilution Reset (K-Line, Euro4)

Applies to

Old Euro 4 models, model years (MY) 2009/2010, fitted with closed-type DPF, (therefore Impreza and Forester only?). This also means using SSM2 via Serial (K-Line) protocol, as SSM2 via CAN will not work for most maintenance operations on such old ECUs due to ROM software limitation.

Description

After changing the engine oil, the ECU needs to be told in order to reset its oil dilution amount and ratio values – the ECU cannot detect the change by itself. By the way, Euro 4 engines do not even have an oil level switch/sensor. Also look at post Oil Dilution Graph describing ECU calculations.

By applying a little communication, dilution will be zeroed, also saved into the ECU’s EEPROM after ignition off. Otherwise this (estimated!) value might rise over time and trigger DPF light flashing having reached 10% ratio.

It seems there are still folks out there interested in this, changing oil by themselves, not at the dealership where mechanics use Subaru Select Monitor (SSM-III or newer SSM-IV) software.
I searched through some of my old notes and found the rather short and easy procedure.

Requirements

Working K-Line connection to ECU. See page SSM2 via Serial.

C-style pseudo code


// only one single SSM2 address is needed
const int address = 0x27D;
byte b = Read(address);

if (b == 0xFF) { print("Probably unmanaged (closed-type) DPF, nothing to do."); exit; }

// set bit 6
Write(address, b | 0x40);

// Wait for some time (500 ms or so is more than enough for the ECU to do its work)
Sleep(500ms);

// clear bit 6
b = Read(address);
Write(address, b & ~0x40);

// verify, make sure bit 6 is zero again...
b = Read(address);

Almost done! Now turn ignition off so that new content gets saved into EEPROM! I also recommend waiting for about 20 seconds, then turn ignition back on in order to query oil dilution ratio [%] and/or oil dilution amount [g] parameter(s) to be sure. These values should be zero now. See post Why and when cycling ignition matters for explanation.

In RomRaider logger definitions (version 310) these parameters are called:

ID EN Unit DE
P193 Oil Dilution Ratio % Öl Verdünnung Verhältniss
P236 Cumulative oil diesel entry g Öl kum Dieseleintrag

SSM2 via K-Line communication example

SND = message from tester to ECU
RCV = received response from ECU


SND: 80 10 F0 05 A8 00 00 02 7D AC
RCV: 80 F0 10 02 E8 00 6A

SND: 80 10 F0 05 B8 00 02 7D 40 FC
RCV: 80 F0 10 00 F8 40 BA

SND: 80 10 F0 05 A8 00 00 02 7D AC
RCV: 80 F0 10 02 E8 40 AA

SND: 80 10 F0 05 B8 00 02 7D 00 BC
RCV: 80 F0 10 00 F8 00 7A

SND: 80 10 F0 05 A8 00 00 02 7D AC
RCV: 80 F0 10 02 E8 00 6A

Update

It has been confirmed to be working, using RomRaider‘s built-in Test tool (menu: Tools → Launch Test App…). Since the sequence of individual commands is not time critical, it can be done by sending SSM2 messages manually one after the other. See this RomRaider Forums thread.

SSM2 Benchmark v2

Ran the old SSM2 benchmark code on a Euro4 diesel ECU again. This time I included 10,400 baud mode as our library already supports this. (We do CAN/ISO15765 high speed mostly so serial stuff is low priority, no continous mode aka “fast poll” support yet.)

Interface device: Tactrix Openport 2.0, drivers installed by EcuFlash 1.43.3252 Beta (2011-04-10).
Same single SSM2 A8 request message as in 2010-Nov test.

Protocol Baudrate [bit/s] Count Samplerate [1/s] P1_MAX [J2534 value] P1_MAX [ms]
SSM2 via Serial 4,800 313 5.22 61 3
313 5.22 40 20
248 4.13 200 100
10,400 338 5.63 81 4
338 5.63 40 20
264 4.40 200 100
SSM2 via CAN 500,000 6001 100.02

1) Tested lowest value to get stable fully correct receive messages.

According to this result, 10,400 baud mode is hardly worth the effort, just 108% speed. Theoretically it should be roughly twice as fast vs. 4,800 baud.

My guess is, the ECU software has not really been designed for higher serial speeds. Not sure why the switch method exists, could be leftover code. It is not uncommon for dead code getting included in software builds. As far as the ECU’s CPU is concerned, serial communication involves more code and overall complexity than CAN. Subroutines responsible for transmitting serial bytes might not be called at a frequent enough interval to cope with higher speeds. I’ve also had to increase P1_MAX (J2534 spec inter-byte timeout) in order to receive correct responses at all times.

There’s a very slight CAN speed improvement compared to 2010-Nov test result. Probably due to J2534 driver improvements.

SSM2 via Serial at 10400 Baud

Standard SSM2 via serial protocol uses 4800 baud = bits/second on “K-Line”, OBD-II Connection pin# 7.

Some (rather recent model year it seems) ECU stock ROM software, both diesel and petrol, support switching to 10400 baud. Btw, 10400 is speed of ISO 14230 (alias KWP 2000) protocol, needed for BIU and several other control units.
It’s relatively easy to do, starting in standard 4800 baud mode, which is the default mode after ignition ON:

Write exact byte 0x5A into SSM2 address 0x000198 in order to switch to 10400 baud (default content is 00 = standard 4800 mode):
W 80 10 F0 05 B8 00 01 98 5A 30
R 80 F0 10 02 F8 5A D4

Ok, above positive response is the last message to receive using 4800 baud. At this point, all further SSM2 commands will fail (no response) because ECU can only understand 10400 baud.
Set interface device to 10400 baud, all other settings as usual, SSM2 is working again, most important commands at least.
Note: In this mode you have to use tester device ID 0xF2 instead of 0xF0! Everything else, including reported data, is the same it seems.

SSM2 Init:
W 80 10 F2 01 BF 42
R 80 F2 10 69 FF A2 10 14 ...

Read single byte, requesting that SSM2 0x000198 byte set above for example:
W 80 10 F2 05 A8 00 00 01 98 C8
R 80 F2 10 02 E8 5A C6
→ 5A, as set before

Read some standard addresses for sampling:
W 80 10 F2 11 A8 00 00 00 08 00 00 0D 00 00 0E 00 00 0F 00 00 10 7D
R 80 F2 10 06 E8 67 62 00 00 00 39
→ coolant temp = 63°C, MAP =98 kPa, engine speed = 0 rpm, vehicle speed = 0 km/h

Block read from address 0xFFB00, length 5. Btw, reflash counter bytes on 1 MiB ROMs live there, word + negated word at 0xFFB00.
W 80 10 F2 06 A0 00 0F FB 00 04 36
R 80 F2 10 06 E0 00 03 FF FC FF 65
→ reflash counter = 3

Write-Single-B8 command does not seem to work, blocked by ROM code! Looks like this mode isn’t gonna meant for maintenance, just faster logging. Don’t know a way to set baudrate back to 4800, except ignition OFF + ON, yet. Also, sending zero byte(s), like turning off continous mode, did not do it for me.
W 80 10 F2 05 B8 00 01 98 00 D8
(no response)

Continous push mode (RomRaider “Fast Poll“) is working, too! Tested working for both read single A8 and read block A0 commands.
So 10400 baud + continous mode should yield even higher sample rates – if someone (RomRaider ?) hacks this stuff into software… Not much fun without proper software support.
Did not do benchmarks yet. Theoretically 10400 vs. 4800 baud might yield factor 2.167 speed improvement.

Still not fast enough and cannot use CAN?
As stock ROMs can be patched, the code that actually does the baudrate settings can be modified. We might test that in the future, e.g. 31250 bits/s or even higher might still work reliably. Thanks to this additional mode, we can try changing that one and leave standard mode intact so any diagnostic software keeps working. Don’t know of any software using SSM2 at 10400 baud. All knowledge about this is derived straight from ROM.

Diesel ECU Patch v1

Finally, now that we are able to reflash diesel ECUs it makes sense to do some changes – or improvements as we think of it.
Couple of things already implemented and working perfectly:

  • Added SSM2 getter function Engine Load, using standard definition 0x000007, x*100/255 [%] – unused in stock diesel ROMs. As engine load value is being calculated internally anyway, also available as OBDII Mode 1 PID 0x04, it makes sense to provide this in SSM2 protocol, too. Very easy to do actually, just a single function pointer change – 4 bytes.
  • Added SSM2 getter function Gear, standard def 0x00004A, x+1 [-], unused in stock ROMs. Tiny function required because of +1 offset.

Btw, as with all SSM2 functions, the physical layer does not matter – any SSM2 function gets called via both serial (Euro4) and CAN connection. Diesel ECUs typically have SSM2 virtual address space 0x000000-0x00034F. That’s 848 function pointers, plus same amount in SSM2-write vector table. You could hook up a lot non-standard things as there are plenty of unused addresses…

  • Modified SSM2 init capability bits accordingly. That way above additional params do show up automatically on ALL SSM2 capable software (RomRaider, FreeSSM, SSM3, DashDAQ ?, …).
  • DPF light active regeneration flashing mode. Applies to closed-type DPF models only. Stock behavior (steady on and error flashing) is untouched, we managed to append own additional code. New code part checks if any stock DPF light mode is currently active. If not, it checks DPF regeneration flag, and only if true it performs this new flashing mode. It’s particularly useful at low engine speed – warning driver that additional turbo lag can occur. Remember, engine management reduces boost and manifold air pressure – sometimes a lot – when active regen is in progress.
    Update: got very positive feedback on this one. Even on a bright sunny day looking through the windshield, that blinking light on dashboard gets noticed immediatly. Whole thing is only a screen page of easy C++. Kudos to GCC, v4.6.x generated code is awesome – highly efficient.

Right now this is all internal, experimental, Linux-centric stuff. Availability of our services to the public will be discussed. It meant many months of full-time work to get this far, call for open source collaboration (less work for everyone) did not work…

Manual Serial Connection Tutorial

Abstract

Describes how to use free open source Drew Tech Tool for J2534 in order to setup a SSM2 via Serial 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: Interface hardware that comes with J2534 driver is required!
Unfortunately, many cheap devices don’t come with J2534 drivers.

I am using Tactrix OpenPort 2.0 in this example.

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

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 ISO9141, ISO14230 would also work, they use the same physical layer (K-Line, OBDII pin 7).
Check baudrate and connect flags. Screenshot shows needed values which are defaults.
We need 4,800 baud which is Subaru SSM2 specific.
Connect Flags, right click for helper dialog.

Setting flag ISO9141_NO_CHECKSUM is important (0x200, bit 9). Since SSM2 is not a standard protocol, we have to turn off automatic checksumming by the device.

ISO9141_K_LINE_ONLY (0x1000, bit 12) can also be set, it’s not required though. I have tested Connect Flags 0x200 and 0x1200 working.

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.
Fasted way is clicking button Create “Pass All” Filter which fills in the needed data automatically.

Mask: 00
Pattern: 00
Filter: Pass

This filter instructs the interface device to let all incoming messages pass through. Without a pass filter, J2534 specs require blocking everything by default.

Don’t forget to click “Apply”, 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

Scratch Pad entry: type message to be sent as hex bytes in here.
IMPORTANT: You must provide valid checksum (last byte) or ECU won’t respond!

Tx flags: None (0)

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

SSM2 via Serial examples

For protocol details see page SSM2 via Serial.
SSM2Init-Request to ECU usually is: 80 10 F0 01 BF 40
SSM2Init-Request to TCU usually is: 80 18 F0 01 BF 48

SSM2-Init response from a diesel ECU:

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.

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.