I have added lots of Euro 6 ROMs and checked them for changed oil dilution behaviour. These are tagged with #OD15, ROM creation date 2017-04 or 2017-05. Predecessor versions, the row(s) above them and without the tag, all dated 2016-10 and earlier, still contain the old 10% threshold behaviour.
Link to page: ECU Software Versions (Stock)
Through comparing a few ROMs recently I have noticed some significant changes regarding oil dilution.
So far it seems, this is about newer Euro 6 diesel ECU firmware only, meaning MY 2015+. Apparently, firmware containing modifications were created in May 2017, probably published since 2017-07.
The oil dilution ratio threshold to trigger DTC P1468 Oil Dilution is now 15 % instead of 10 %.
A couple of tables have been adjusted, for example “oil dilution evaporation” is now defined up to 15 % and a few DPF regeneration behaviour tweaks.
Also, the relationship between log items “Distance To Oil Change [km]” and “Oil Dilution Ratio [%]” is not linear anymore, rather nonlinear in fact.
Both graphs were created out of 2015/2016/2017 Outback Diesel CVT ROM data:
CID JB4K104B, ROM date 2017-05:
Older Euro 6 CID JB4K102B, ROM date 2016-10, and probably still applicable to all Euro 4/5 models:
I will update related pages in the near future.
For now, if you are affected, don’t use my custom “Oil Dilution 2” log item anymore.
If you like, you can use this simple formula instead, but it is only valid between 0 % and 8 %:
OilDilutionRatio3[%](DistanceToOilChange[km]) = 60-DistanceToOilChange/250
Example values:
| DistanceToOilChange [km] |
OilDilutionRatio3 [%] |
|---|---|
| 13500 | 6.0 |
| 13400 | 6.4 |
| 13300 | 6.8 |
| 13200 | 7.2 |
Since diagnostic item “Distance to Oil Change” is scaled in [100 km], above formula provides oil dilution in 0.4 % steps. Accuracy has become worse but is still better than standard log item “Oil Dilution Ratio” which only provides integer resolution. Not sure if logging apps such as Torque can handle table lookup or piece-wise functions.
Posted in Boxer Diesel, ECU Analysis, Euro6, Graph, Maintenance, Table
Tagged BoxerDiesel, Diesel, dilution, DPF, Euro6, maintenance, oil, plot
Added Euro 6, now covering all model generations; improved result plots
Link to post: “Fuel Level”
Posted in Uncategorized
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:
… at specific time positions:
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 %)
@ 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
@ 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
@ 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)
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
@ 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
@ 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
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.
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); …
Disassembly made by objdump:
c: 91 26 mov.w 0x5c,r1 ! 9c1f e: 61 10 mov.b @r1,r1 10: 60 1c extu.b r1,r0 12: 88 01 cmp/eq #1,r0 14: 89 14 bt 0x40 16: 91 22 mov.w 0x5e,r1 ! b222 18: 61 10 mov.b @r1,r1 1a: 62 1c extu.b r1,r2 1c: 22 28 tst r2,r2 1e: 8d 0f bt.s 0x40 20: e2 0f mov #15,r2 22: 91 1d mov.w 0x60,r1 ! 9c53 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: 8d 0c bt.s 0x48 2e: 60 13 mov r1,r0 30: 92 16 mov.w 0x60,r2 ! 9c53 32: 22 10 mov.b r1,@r2 34: d1 0b mov.l 0x64,r1 ! 945a8 36: 02 1c mov.b @(r0,r1),r2 38: 91 13 mov.w 0x62,r1 ! 9c1e 3a: 21 20 mov.b r2,@r1 3c: 00 0b rts 3e: 00 09 nop 40: 92 0f mov.w 0x62,r2 ! 9c1e 42: 22 10 mov.b r1,@r2 44: 00 0b rts 46: 00 09 nop 48: 92 0a mov.w 0x60,r2 ! 9c53 4a: e1 00 mov #0,r1 4c: e0 00 mov #0,r0 4e: 22 10 mov.b r1,@r2 50: d1 04 mov.l 0x64,r1 ! 945a8 52: 02 1c mov.b @(r0,r1),r2 54: 91 05 mov.w 0x62,r1 ! 9c1e 56: 21 20 mov.b r2,@r1 58: 00 0b rts 5a: 00 09 nop 5c: 9c 1f mov.w 0x9e,r12 ! 600c 5e: b2 22 bsr 0x4a6 60: 9c 53 mov.w 0x10a,r12 ! e000 62: 9c 1e mov.w 0xa2,r12 ! e0ff 64: 00 09 nop 66: 45 a8 .word 0x45a8 5a8: 01 01 .word 0x0101 5aa: 00 00 .word 0x0000 5ac: 01 01 .word 0x0101 5ae: 00 00 .word 0x0000 5b0: 00 00 .word 0x0000 5b2: 00 00 .word 0x0000 5b4: 00 00 .word 0x0000 5b6: 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.
Posted in Boxer Diesel, Development, ECU Analysis, Euro4, Impreza Diesel
Tagged BoxerDiesel, C#, disassembly, DPF, ECU, embedded, Euro4, Euro5, Euro6, gcc, light, make, objdump, Patch, reflash, Renesas, ROM, Subaru, SuperH
Perhaps another color map for EcuFlash might be interesting? I wrote a little SageMath python script to generate a ScoobyRom-like color map file.
EcuFlash using ScoobyRom color map
Note: Although generated color map matches ScoobyRom’s precisely, EcuFlash applies colors based on “min” and “max” specified in XML definitions.
Excerpt from EcuFlash definition file: 32BITDIESELBASE.xml
<scaling name="ChargeAirPressure" units="kPa" toexpr="x" frexpr="x" format="%.0f" min="0" max="255" inc="1" storagetype="uint8" endian="big"/>
Whereas ScoobyRom scales colors ranging from a map’s actually used mininum and maximum. For example, if you would change min="0" to min="100" in above scaling definition, low value colors would appear bluish like in ScoobyRom, effectively making map graphics cover more/most of available color range.
1) Download file scoobyrom-map.odt
2) Rename downloaded file to ScoobyRom.map, since normal file extension is not allowed on wordpress.com.
3) Move file into EcuFlash’s color maps folder, i.e.
C:\Program Files (x86)\OpenECU\EcuFlash\colormaps\
4) Launch or restart EcuFlash.
5) Via EcuFlash menu: File → Options → Appearance → Default Color Map
Select “ScoobyRom.map”
(Btw., default color map directory can also be defined in Options)
Color map format is plain text ASCII file, usually 256 lines as in this case, specifying RGB values which will be applied to maps, from low to high:
153 153 255 153 154 255 153 156 255 152 157 255 ... 255 110 103 255 107 102 255 105 102 255 102 102
Posted in ECU Analysis, EcuFlash, Graph, Software
