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

---

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

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

---

Actual source code, written in C/C++:

// Copyright (c) 2011 SubaruDieselCrew

#include "sh.h"
#include "JZ2F401A.h"

enum DPFLightMode { OFF = 0, ONsteady = 1, Flashing = 2 };

// time resolution in ms (= CAN-ID 0x600 interval)
#define Interval 50
#define DpfLightPeriod 800
const unsigned char CounterMax = DpfLightPeriod / Interval;
static bool table[CounterMax] = { 1, 1, 0, 0, 1, 1, 0, 0,
	0, 0, 0, 0, 0, 0, 0, 0 };

// called every 50 ms (CAN-ID 0x600 interval)
void calcDpfLightContinue ()
{
	// standard flashing mode already handled by untouched
	// sub part and this sub won't get called

	// steady ON, needed as original functionality has been
	// overwritten for hook instructions
	if (*DPFLightModeEnum_b == ONsteady)
	{
		*DPFLight_bool = true;
		return;
	}

	if (*DPF_Regeneration_bool_SSM == false)
	{
		*DPFLight_bool = false;
		return;
	}

	// active DPF regeneration is ON -> own flashing mode
	// reusing DPF light counter var is safe
	unsigned char counter = *DPFLightCounter_b;
	if (counter < CounterMax - 1)
		++counter;
	else
		counter = 0;
	*DPFLightCounter_b = counter;
	*DPFLight_bool = table[counter];
}

---

// Copyright (c) 2011 SubaruDieselCrew

/*
	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
#define DPFLight_bool (bool*)(0xFFFF9C1E)
#define DPFLightModeEnum_b (char*)(0xFFFF9C1F)
#define DPFLightCounter_b (char*)(0xFFFF9C53)
#define DPF_Regeneration_bool_SSM (bool*)(0xFFFFB222)
…

---

Disassembly using objdump which is part of GNU binutils. Binary had been generated by GCC. I added quite verbose comments for those who don’t know SH (SuperH) disassembly well enough.

void calcDpfLightContinue()
  c: 91 1b  mov.w   0x46,r1 ! 9c1f   // r1 = &DPFLightModeEnum_b = 0xFFFF9C1F (sign extension of value 0x9c1f)
  e: 60 10  mov.b   @r1,r0           // r0 = DPFLightModeEnum_b
 10: 88 01  cmp/eq  #1,r0            // DPFLightModeEnum_b == ONsteady ?
 12: 8f 02  bf.s    0x1a             // if not --> jump
 14: 71 ff  add     #-1,r1           // r1 = 0xFFFF9C1E = &DPFLight_bool
 16: 00 0b  rts                      // return (after following instruction)
 18: 21 00  mov.b   r0,@r1           // DPFLight_bool = true

 1a: 92 15  mov.w   0x48,r2 ! b222   // r2 = &DPF_Regeneration_bool_SSM = 0xFFFFB222
 1c: 62 20  mov.b   @r2,r2           // r2 = DPF_Regeneration_bool_SSM
 1e: 63 2c  extu.b  r2,r3            // r3 = (uint8)DPF_Regeneration_bool_SSM
 20: 23 38  tst     r3,r3            // DPF_Regeneration_bool_SSM == false ?
 22: 8d 0e  bt.s    0x42             // is false --> DPFLight_bool = false; return
 24: 00 09  nop
 26: 91 10  mov.w   0x4a,r1 ! 9c53   // r1 = &DPFLightCounter_b = 0xFFFF9C53
 28: e2 0e  mov     #14,r2           // r2 = CounterMax - 2 = 14
 2a: 60 10  mov.b   @r1,r0           // r0 = DPFLightCounter_b
 2c: 60 0c  extu.b  r0,r0            // r0 = counter = (uint8)DPFLightCounter_b
 2e: 30 26  cmp/hi  r2,r0            // counter > 14 ?
 30: 8d 02  bt.s    0x38             // if yes --> DPFLightCounter_b = 0
 32: 70 01  add     #1,r0            // ++counter
 34: a0 01  bra     0x3a             // --> DPFLightCounter_b = counter
 36: 60 0c  extu.b  r0,r0
 38: e0 00  mov     #0,r0            // r0 = 0
 3a: 21 00  mov.b   r0,@r1           // DPFLightCounter_b = r0
 3c: d1 04  mov.l   0x50,r1 ! 943c0  // r1 = &table[0]
 3e: 02 1c  mov.b   @(r0,r1),r2      // r2 = table[counter]
 40: 91 04  mov.w   0x4c,r1 ! 9c1e
 42: 00 0b  rts
 44: 21 20  mov.b   r2,@r1           // DPFLight_bool = r2; return
 46: 9c 1f                  // 0x9c1f
 48: b2 22                  // 0xb222
 4a: 9c 53                  // 0x9c53
 4c: 9c 1e                  // 0x9c1e
 4e: 00 09  nop
 50: 00 09                  // 0x943c0 --> blob position 3c0
 52: 43 c0

3c0: 01 01  .word 0x0101    // table[16] = { 1, 1, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
3c2: 00 00  .word 0x0000
3c4: 01 01  .word 0x0101
3c6: 00 00  .word 0x0000
3c8: 00 00  .word 0x0000
3ca: 00 00  .word 0x0000
3cc: 00 00  .word 0x0000
3ce: 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). It is not recommended to use old/obsolete firmware! You’ll have to do your own work to apply this to other ROMs. From investigations on 2010 Euro 5 ROMs I assume that the same code would also work on Euro 5 models.

Compiled binary generated from above source code is 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.

Updates

2016-01-31: added disassembly

Updated Extended OBD-II definitions

Added 7 PIDs (0x10A1, 0x10A3..0x10A7, 0x1137), some are petrol-only, some diesel-only, some mixed.
See Extended OBD-II definitions page.
Downloads (spreadsheet, CSV) as well as ParsePID project are up to date.
Note that some PIDs have not been tested on actual cars yet – feedback is appreciated!

Yet another color map for EcuFlash

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.

Install

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 File Format

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

ScoobyRom v0.8.2 Released

What’s new in v0.8.2:

• Export as TunerPro XDF format.
• Support for ROM type SH72531 (1.25 MiB = 1280 KiB size)
• Display Reflash Count if known/available (Properties-window).

Project homepage: ScoobyRom Software

Properties

Already implemented in previous version is the ability to parse and display ROM Date (year-month-day), diesel as well as petrol type encodings. May not work for all ROM types (yet), though. AFAIK, ScoobyRom is the only software parsing this Denso specific date.

ScoobyRom 0.8.2 – Properties window, CID JZ4A211B

TunerPro (XDF)

Due to my intense work on BMW ECUs in recent years, I got familiar with TunerPro which is a generic ROM editor. It is quite popular in the BMW community, it can handle lots of data format options. Its definition format “XDF” is XML-based as usual. As an exercise to verify XDF knowledge I implemented XDF output in ScoobyRom.

Compared to RomRaider, reading an XDF containing hundreds of tables is very fast, almost instant. TunerPro is Windows-only and closed-source however.

TunerPro 5.00.8853 screenshot, Windows 10 x64, XDF generated by ScoobyRom

New pages: Software

Added new category “Software”. See sub-page Logging for software comparison.

Still incomplete and under construction. As always, do not hesitate to report feedback!

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

Restrictions

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.

Errors

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

Example

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.