Tag Archives: CAN

Log Graphs 1


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.


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

Image 1/2


Image 2/2


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

Mode 23 – Read Memory

According to some of my notes, Euro 5 diesel models, or cars that support Extended/Enhanced OBD-II in general, might support mode/service 23 for dumping ROM or RAM blocks:

Format is similar or same as ReadMemoryByAddress (23 hex) service specified UDS (Unified Diagnostic Services, ISO 14229) protocol:

"23 <Format> <Address[]> <Length[]>"

Several $23 formats can be supported, Euro 5 diesel:

  1. "23 14 A1 A2 A3 A4 L1"
  2. "23 24 A1 A2 A3 A4 L1 L2"

As you can guess, format byte e.g. 0x14 means:

  • 4 address bytes → uint32 big endian, encoded in low nibble of format byte
  • 1 length byte → uint8, encoded in high nibble of format


Stock firmware usually restrict available address ranges, allowing only partial dumps. ROM calibration data and RAM regions might work. Knowing how to reflash and reverse-engineer the logic, such restrictions can be patched and therefore eliminated.


Depends on actual implementation, (early) Euro 5 diesel ROM logic:

  • 0 < length ≤ 0x400 (dec 1024) bytes otherwise NRC 31
  • other formats or request message lengths yield NRC 13
NRC (hex) Description
13 Incorrect message length or invalid format
31 Request out of range


Euro 5 diesel (1.5 MiB ROM, SH7059 chip) example – dump beginning at ROM calibration data:

Start address = 0xC0000
Length (per request) = 0x40 = 64 bytes

"23 14 00 0C 00 00 40"
Positive response: "63 <XX XX XX ... total 64 payload bytes ... XX XX>"

"23 14 00 0C 00 40 40"

"23 14 00 0C 00 80 40"

"23 14 00 0C 00 C0 40"

"23 14 00 0C 01 00 40"

Anyone able to confirm that these mode 23 commands and formats are working?

Personal experience on many different control units: Maximizing length per request yields max transfer speed, however application algorithm must be able to handle NRC codes and react properly.

Diesel ECU Patch v2

Patched the CAN-handler responsible for the SSM2-Read-Addresses (A8) command. Now we’ve got high-speed full RAM access.
Euro4 stock ROMs prevent RAM access (0xFF**** addresses) via CAN (ISO15765 actually). Previously we had to resort to slow SSM2 via Serial protocol.

The static screenshot does not really tell the difference though. This Linux application can do both modes. Speed in comparison is like this: logging roughly 120 items using SSM2 via CAN updates all values fluently – no noticable delay. In serial mode, it takes multiple seconds for a single refresh – really major difference!

Planned: Implementing CAN block read command for even more performance e.g. quick RAM snapshots. Either command “A0” like SSM2 via Serial or Extended OBD-II mode 0x23 (stock Euro5 diesels have this), or both.

Electrical Power Steering

Normally power steering control unit only activates steering assist when engine is running.
Now we have found a way to activate this while keeping the diesel engine off, used method needs CAN software though.
This way one can listen to any steering noises that would otherwise be drowned out by the engine, useful for diagnostics. The electrical motor is pretty quiet but noticable at engine off.
Update: There’s also a harsh method – just stall the engine deliberately – power steering keeps ON till ignition off.

Coolant Temperature

Like all or most engine related sensors, coolant temperature is being digitised by ECU. There’s a 2-dimensional table to convert measured sensor voltage to temperature result inside ROM:

Calibration curve is typical for a NTC (Negative Temperature Coefficient) thermistor.
Moving on to combination meter, coolant temperature lights are driven by ECU CAN output, precisely CAN-ID 0x600 byte 3. That byte contains coolant temperature, conversion formula is “x-40 [°C]“.
There are no additional flags for the dashboard lights. Meaning combination meter computer parses coolant temperature from CAN frame and decides on its own.

EXACT conditions, confirmed by testing: 1

Light Coolant
Boxer Diesel combination meter light when coolant is cold. < 50 °C (122 °F)
≥ 112 °C (234 °F)

A possible way to change stock thresholds is to modify ECU ROM resulting in faked 0x600 coolant temperature value output. This has already been tested working. However, other control units then read wrong temperature, too, resulting in possible side effects – especially if the offset is significant.

Coolant temperature certainly has effect on:

  • A/C (can hear actuator move depending on temperature)
  • BIU (copies data onto low speed bus)
  • Combination Meter

Didn’t have time to investigate low-speed CAN bus and BIU (Body Integrated Unit) yet. In theory, BIU could transform data from high-speed (ECU, VDC/ABS etc.) to low-speed bus instead of just copying it. Anyone knows? BIU is the gateway, the only control unit connected to both CAN busses. Combination meter is on low speed bus for sure.

1) No hardware has been harmed, we’ve used CAN injection/simulation.

New Diagnostic Protocol

Started documentation on page Extended OBD-II.
So far only Euro5 Boxer Diesel models support/need this.

Manual ISO15765 Connection Tutorial


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.


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.
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.