Category Archives: Euro4

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

DPF Light Patch

This is meant for programmers or at least folks who understand coding in general. Here I am going to show how I implemented the DPF light patch, part of Diesel ECU Patch v1, on my former (Euro 4) car.
DPF Light Patch - Active Regeneration In Progress


Actual source code, updated to C++14:


// Copyright SubaruDieselCrew (2011-2017)   https://subdiesel.wordpress.com

#include <array>
#include <chrono>
//#include <bitset>
#include "sh.h"
#include "JZ2F401A.h"

using namespace std::chrono_literals;

/**
 * @brief DPF light flashing modes (stock)
 *
 */
enum class DPFLightMode {
    off = 0,
    /**
     * @brief soot-high warning aka vehicle speed request
     *
     */
    on_steady = 1,
    /**
     * @brief error
     *
     * (multiple causes: compulsory regeneration required, oil dilution critical, ash overfill, DPF limp-home mode;
     * see https://subdiesel.wordpress.com/2011/03/21/dpf-light/ )
     */
    flashing = 2,
};

/**
 * @brief time resolution (= CAN frame ID 0x600 interval)
 *
 */
const constexpr auto interval {50ms};
/**
 * @brief stock period for flashing mode is 800 ms,
 *        does not have to match stock here
 *
 */
const constexpr auto dpfLightPeriod {800ms};
/**
 * @brief defines DPF light output over time when active regeneration is on
 *
 */
const constexpr std::array<bool, dpfLightPeriod / interval> dpfLightCustomPattern
{
    1, 1, 0, 0,  1, 1, 0, 0,
    0, 0, 0, 0,  0, 0, 0, 0
};
// tested alternative: bitset; storage-efficient but much more lookup code
// const std::bitset<dpfLightPeriod / interval> bits {"1100110000000000"};

/**
 * @brief Implement custom flashing mode.
 *
 * Called every 50 ms (CAN-ID 0x600 interval)
 * from patched stock function "calcDpfLight".
 * Standard error flashing mode already handled by untouched
 * stock subroutine portion and this case this function won't get called.
 */
void calc_DPFLight_continue()
{
    // needed as original functionality has been overwritten for hook instructions
    if (DPFLightMode(*DPFLightModeEnum_b) == DPFLightMode::on_steady)
    {
        *DPFLight_bool = true;
        return;
    }

    // at this point DPFLightMode == DPFLightMode::off
    if (!*DPF_Regeneration_bool_SSM)
    {
        *DPFLight_bool = false;
        return;
    }

    // at this point active DPF regeneration is ON, do custom flashing
    // reusing DPF light counter var is safe
    auto counter = *DPFLightCounter_b;
    if (++counter >= dpfLightCustomPattern.size())
        counter = 0;
    *DPFLightCounter_b = counter;
    *DPFLight_bool = dpfLightCustomPattern.at(counter);
}



// Copyright SubaruDieselCrew (2011-2017)   https://subdiesel.wordpress.com
/*
	For stock ROM:
	Model	2009/2010 Impreza Turbo Diesel 2.0 6MT EDM 110 kW / 150 PS
	ROMID	6644D87207
	CID		JZ2F401A
	CVN		F5AD7142 FB841734
	PAK		22611AP283
*/

#ifndef JZ2F401A_H
#define JZ2F401A_H

#include "diesel_rom.h"

// RAM vars
static auto const DPFLight_bool = reinterpret_cast<volatile bool*>(0xFFFF9C1E);
static auto const DPFLightModeEnum_b = reinterpret_cast<volatile int8_t*>(0xFFFF9C1F);
static auto const DPFLightCounter_b = reinterpret_cast<volatile uint8_t*>(0xFFFF9C53);
static auto const DPF_Regeneration_bool_SSM = reinterpret_cast<volatile bool*>(0xFFFFB222);
…


SuperH disassembly using objdump which is part of GNU binutils. Binary had been generated by GCC.


void calc_DPFLight_continue()
c:  91 1d   mov.w   0x4a,r1 ! 9c1f
e:  60 10   mov.b   @r1,r0
10:  88 01   cmp/eq  #1,r0
12:  8d 17   bt.s    0x44
14:  71 ff   add     #-1,r1
16:  91 19   mov.w   0x4c,r1 ! b222
18:  61 10   mov.b   @r1,r1
1a:  21 18   tst     r1,r1
1c:  8d 0e   bt.s    0x3c
1e:  62 13   mov     r1,r2
20:  91 15   mov.w   0x4e,r1 ! 9c53
22:  e2 0f   mov     #15,r2
24:  61 10   mov.b   @r1,r1
26:  71 01   add     #1,r1
28:  61 1c   extu.b  r1,r1
2a:  31 26   cmp/hi  r2,r1
2c:  8f 02   bf.s    0x34
2e:  60 13   mov     r1,r0
30:  e0 00   mov     #0,r0
32:  e1 00   mov     #0,r1
34:  92 0b   mov.w   0x4e,r2 ! 9c53
36:  22 10   mov.b   r1,@r2
38:  d1 06   mov.l   0x54,r1 ! 945c0
3a:  02 1c   mov.b   @(r0,r1),r2
3c:  91 08   mov.w   0x50,r1 ! 9c1e
3e:  21 20   mov.b   r2,@r1
40:  00 0b   rts
42:  00 09   nop
44:  21 00   mov.b   r0,@r1
46:  00 0b   rts
48:  00 09   nop
4a:  9c 1f
4c:  b2 22
4e:  9c 53
50:  9c 1e
54:  00 09
56:  45 c0

5c0:  01 01   .word 0x0101
5c2:  00 00   .word 0x0000
5c4:  01 01   .word 0x0101
5c6:  00 00   .word 0x0000
5c8:  00 00   .word 0x0000
5ca:  00 00   .word 0x0000
5cc:  00 00   .word 0x0000
5ce:  00 00   .word 0x0000


As you can tell there is not much code required. Much more work, orders of magnitude (!), is necessary to reverse-engineer the related stock ROM portions in the first place, defining functions, disassembling machine instructions, naming local and global variables etc.

Usually, ROM and RAM addresses depend on the actual ROM version used. Above definitions work for outdated CID JZ2F401A (dated 2009-Sep). Apart from ROM specific variable addresses the same code will work for all known Euro 4/5/6 models.

Resultant binary data is meant to be inserted into a free unused ROM region. On Renesas SH microprocessors (i.e. SH7058S) free ROM space is rather easy to find – just look for big chunks of continuous FF-bytes. This is because those chips erase bytes to value 0xFF. Others, e.g. Infineon TriCore series, erase their internal flash ROM to zeroes instead.

To actually make use of the added logic, I had to modify (patch) a few bytes in the original calc_DPF_light subroutine, so that after doing some of its work it will call my own function, knowing its start address (0x9400C). Usually there is no free space in between stock functions, therefore we have to apply clever patching tricks to make room for a few new instructions and/or divert execution flow.

Finally, after carefully verifying the changes applied to the stock ROM, you have to correct checksums. Flashing software usually does this anyway, perhaps asking first. Checksum correction and verification is actually very easy to do for such Denso firmware.

Providing SDC-modified ROMs is possible, however will not be free due to amount of labour involved. Contact us if you’re interested.

Updates

  • 2017-04: minor update, actual disassembly
  • 2016-11: updated source to C++14
  • 2016-10: updated source to C++11 with Doxygen documentation
  • 2016-01: added disassembly

Injector Codes

Denso Injector DCRI107890 (Denso part# 095000-7890, Subaru part# 16613-AA020) for Euro 4 Subaru Diesel

Introduction

Quote from a DENSO document incl. picture below:

Replacing a Diesel Common Rail Injector:
When replacing a DENSO Diesel Common Rail Injector, marked with a compensation code, it is necessary to register the ID code, printed on the upper part of the injector, with a genuine OEM – or DENSO diagnostic tool, into the electronic control unit (ECU). The injector compensation (ID) code is used to compensate injector production tolerances.
Some vehicles also require Small Injection Quantity Learning.

Denso Injector ID graphic

Subaru’s term for injector compensation or ID code is “injector code“. Dealership diagnostic software (SSM-III, SSM4) has menu items like “Injector Code Display” and “Injector Code New Registration (SSM to ECM)

First off, the engine control unit has no way of measuring actual injected fuel amount, such technology would be expensive for these kind of small fluid quantities. Due to high common rail pressure, even tiny production tolerances result in unwanted injection quantity variations. Obviously, each injector must be registered using its correct cylinder number so the ECU can apply individual adjustments when it is calculating injections. Basically, the ECU accomplishes desired (target) injection quantity by adjusting the duration of injector drive signal.

Since programmed injector codes as well as any other important data is being saved into an extra EEPROM chip, there is no risk of data loss having the car battery disconnected.

Consequences of Wrong or Missing Injector Codes

According to DENSO:

  • Knocking noise
  • Unstable idle
  • Wiggling during driving
  • MIL (Check Engine Lamp) on

Cylinder numbers – Quick Reference

As for a quick reminder, looking at the front of the car into engine bay, cylinder numbers are:

towards back
transmission
  3        4
  1        2
car front (radiator etc.)

Getting Injector Codes via QR Code

Although normally this should not be necessary, injector codes can be read from the actual injector parts even when mounted on the engine and inside the engine bay, therefore not easily accessible. Taking a picture using a mirror tool is relatively easy, no need to disassemble any parts:

Injector QR Cyl2 small

While the injector code label itself is hidden by the (white) electrical connector, its QR code is visible by default.
Make sure the QR code on the photo is as sharp as possible and has sufficient resolution. At the car I usually just try to get high quality pictures. Later on my computer I simply select the best pic, then scan QR info straight off the computer screen using a smartphone.

Using an image manipulation program (i.e. GIMP, PhotoShop) in order to improve the QR code area can result in much better QR detection. In my case, this was not needed as the app can also detect inverted QR (light code on dark background).
Android app tested: “Barcode Scanner” from F-Droid repository. Check settings → Invert scan.

As an example, the following pic is the extracted and improved QR code portion from above picture. I used these steps in GIMP: crop, perspective correction, grayscale, invert, brightness & contrast . You should be able to scan this:

Injector QR Cyl2 processedScanning captured QR code results in a line of text containing 49 characters:

7890AA0200809118736B30000000000E9EBEBECF300000045

First 19 chars:

7890AA0200809118736
  • First four chars 7890 match Denso basic part number.
  • AA020 is also found in Subaru part# 16613-AA020
  • Possibly contains production date 2008-09-11 ?
  • Serial# ?

Injector Code Format

Remaining 30 chars is the exact injector code needed for ECU. These chars must be in hexadecimal [0-9, A-F] form as they are transmitted as 15 bytes to and from the ECU:

B30000000000E9EBEBECF300000045
Byte index [0..14] Content
0 const, sort of generation ID, verified by ECU:

  • Euro 4: B3
  • Euro 5: B2
  • Euro 6: B6
1..12 12 payload bytes containing correction data, type int8, for up to 12 pre-defined correction points. Each signed byte must be within range [-125, 125]. In other words, the following five bytes are not allowed: 7E, 7F, 80, 81, 82.
13 const 00
14 simple XOR checksum

Resultant properly formatted injector code (left to right, 4 chars per block):

B300    0000
0000    E9EB
EBEC    F300
0000    45

Notes

Invalid codes will be rejected! Euro 5+ will return NRC 0x31 (request out of range).
Injector code data is not compatible between common rail system generations due to differing correction points! Euro 4 uses fewer points (10) than E5+ (12). Therefore, for example, programming a Euro 5 injector code into Euro 4 ECU will not work and vice versa.

Software

AFAIK, Denso’s own PC diagnostic software has the ability to read from a QR scanner device, Subaru OEM application SSM-III does not – need to type in codes manually.

Protocols needed for injector code display & registration:

  • Euro 4: SSM2 via Serial
  • Euro 5/6: Extended OBD-II

As far as we know, there is no free/open-source software for this yet.

EcuTek tool probably supports injector coding (up to Euro 5 ?).

Other Brands

Many other car brands are based on Denso diesel software. These often use similar 15 byte injector codes as well. However, injectors and pre-defined correction points usually differ!

Mazda CX-5 (SkyActiv-D 2.2)

Piezo injectors! 15 bytes; first byte: 3C; pressure levels and corrections points differ vs. Subaru.

Mazda terminology: fuel injector code programming, injector correction factors

Updates

  • 2017-05: additional notes and details
  • 2016-04-03: Euro 6

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);

// 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(500);

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

Fuel Consumption

Consumption Display Correction

It is the ECU software that estimates fuel consumption as it calculates all individual injections (multiple per stroke) anyway. Based on injection quantity demand it will calculate injector drive time, taking conditions like rail pressure and fuel temperature into account. It cannot measure fuel flow directly as this would require expensive equipment – tracking fuel flow + return flow accurately, all temperature compensated.
In reality most drivers notice some trip computer offset vs. actual consumption calculated at gas station fill-up. Usually the displayed value is too optimistic. The offset may depend on driving conditions and fuel quality. Often enough it is roughly constant for an individual driver so it is still useful information.

We offer fuel consumption display correction by patching ECU software.
Simple solution is to derive a constant factor.

E.g. indicated 6.6 litre/100km vs. 7.0 actual → correction factor = 7.0 / 6.6 = 106.1 %.
After modifying and reprogramming ECU ROM, fuel consumption CAN value (ECU output, [mm³/s]) will be adjusted accordingly, to be picked up by combination meter computer. This one calculates all trip values, finally sends display control commands to center display over serial connection.

Injecting complex ECU subroutine f(torque, temp, rpm, …) and/or table data is also possible, requires measurement data in the first place, though.

DPF Active Regeneration

As you may have noticed, active DPF regeneration has a big impact on instant fuel consumption. All injection parts are included in CAN consumption value, therefore post-injections are noticeable in center display when it is set to current consumption mode.
Collected CAN data showed ~300 % actual fuel consumption at idle when active regeneration is in progress, mainly due to post-injections and intake air throttling in order to heat up the DPF, compared to normal idling with regeneration off.

Idling at 800 rpm, coolant temperature ~90°C both times:

Item Unit Normal Active Regeneration
Injection Amount mm³/st 3.3 12 1
Fuel Consumption mm³/s 88 319
cm³/s 0.088 0.319
litre/h 0.32 1.15

1) Calculated from CAN value, SSM2 item “Final Injection Amount” would indicate 4.0 mm³/st (!). Logged data suggests this SSM2 parameter matches CAN consumption value as long as post-injections are not occurring (DPF active regeneration). To get fuel consumption, best way is to parse the CAN fuel flow value instead.

Formulas

Other Brands

Mazda CX-5 (SkyActiv-D 2.2)

Fuel consumption algorithm and correction works similarly.

Top Speed Limiter

Euro5

Fully implemented limiter subroutine decreases internal accelerator position value, speed ↑ results in accelerator pos ↓, overriding driver demand.
This way there’s no precise vmax threshold, it rather depends on overall resistance, meaning higher vmax going downhill. Max limited vehicle speed seems to match manufacturer specified top speed, ~205 km/h for Impreza on flat road.
Of course, this limiter functionality allows for adjustments, by modifying the logic it can also be disabled entirely.

Euro4

In all Euro4 ROMs seen so far, above limiter logic is preparatory and inactive.
We could insert necessary microcontroller instructions, making it work like Euro5 if someone really needs this.

DPF Management

Some parts of Denso’s complex Diesel Particulate Filter (DPF) algorithms are somewhat known by now. Will update with new results from time to time.
Link to page