The Bosch EDCxx series (Electronic Diesel Control) ECUs is a widely used system for modern diesel
engines. It is used by BMW, VAG, Opel, SAAB and many others. This document and the described VAG EDC15P suite software will only focus on the Volkwagen Audi Gruppe (VAG) specific implementations in the EDC15P models. These ECUs are used in the PD engines (Pumpe Duse) from Volkswagen, Audi,Skoda and Seat. Other EDCxx ECUs may work in a similar fashion but will differ in certain areas.
The article describes the EDC15P ECU in detail. It will first describe the hardware and proceed with a even more detailed description of the software that is running in the ECU so that we can learn how to tweak and tune the ECU to match the hardware – altered or not – that is on the car better.
Some Useful Information:
Overview of the EDC15P ECU Board:
The ECU contains a multi-layer printed ciruit board (PCB) which holds a lot of SMD components. The main component are – logically: Main CPU, Flash program storage, SRAM memory (working memory),EEPROM (for storing mileage, immo etc) and a lot of input/output (I/O).
Main CPU: Infineon C167
16 bit CPU
Flash eprom: Am29F400
The flash contains the program and maps for the ECU. EDC15P has 512KB (4 Mbit) flash memory in which it can store multiple map segments for different situations (automatic gearbox, manual gearbox,quattro etc). Switching between these segments is generally called “recoding”. Strangly DQ4 is used for boot pin (held low during startup, this will force the ECU in boot mode).
Once we download the data from the ECU with a MPPS, Galletto 1260, BDM or some other means to do a full read we can load the binary file into EDC15P Suite
We can see the most important maps being automatically detected and we can change them to ourlikings. Be careful though, you need to know what you are doing. The software can generate a
differences list between two files as well and if we compare a stock file to a tuned file we can see only a few maps get edited normally.
Software information data
In the software, the identifiers are stored as well about HW revision,SW version,VAG partnumbers etc.This data is stored in ASCII in the binary file and looks something like this:
0281010981 is the hardware ID
1037366273 is the Bosch software ID
038906019FT is the VAG number
Reading the code
To be able to understand the software better we’ll need to dive into the world of assembler language.
This is a sort of intermediate between understandable human language and the operation codes used by the microprocessor. Once we can read the assembler language (assembly for short) we can track all the things the microprocessor is told to to when the program is running. This is very valuable information because we don’t have first hand information from either Bosch or VAG that can tell us in details what the ECU does.
We convert the binary file into assembly language we need to disassemble the file. We can do that by running a disassembler like IDAPro or a seperate disassembler for the specific uC.
Once we disassemble the binary file we have an file containing the assembly listing in which we can
start to explore and understand the internal workings of EDC15P.
Maps and variables
Determining the location and type of maps and variables in the EDC15P binaries is quite a hassle. To be able to detect the available maps we have to do some tricks and make a couple of assumptions in the algorithm used. This chapter will describe – in detail – what the EDC15P Suite software does to fetch the
maplist from the file.
Getting the map addresses
First we need to lookup the addresses for the maps that we can find. The software parses the entire binary file for IDs and length bytes that are *probably* maps and stores this in a collection.
Validating the entries in the collection
Now we have a list of addresses with which we can work. For each address that we found we validate the data found at that address. For example:
The first two marked bytes (0x2E 0xEC) tell us it might be the start of an axis (the software has a list of known ids for this) It then validate the second pair of bytes (0x10 0x00). If this value looks like a valid length it starts to read data from that point on (0x10 byte pairs). Next it evaluates whether there is a second axis after the first one. The ID that is read is 0x36 0xC0 in this case and the length of the second axis is 0x0A 0x00. It now knows that this map is 16 x 10 values in dimensions, it knows the values for both axis (the data after the length indicators) and it knows the starting address and length of the map data. This procedure is done for all addresses found in the collection and the software stores the validated maps in a new collection.
Labelling the maps
This is possibly the part that has the most assumptions in it. Most maps are named by looking at the dimensions and their axis IDs. In some files though, there are multiple maps with the same properties. In that case, the software also looks at (for example) the axis values or the map structure.
This chapter will describe the basic mapping you will need for a simple stage 1. Complicated mappings for altered hardware (airmass sensors, mapsensors, turbo’s, bigger injectors etc) are not described here.
Another article about:Skoda Fabia vRS Bosch EDC15P+ ECU Tuning Guide
It will also give a good overview on what the EDC15P Suite has to offer.
The maps needed for a simple stage 1 are;
ü Driver wish map
ü Torque limiter
ü Smoke limiter
ü Injection duration map
ü EGR map (optionally)
ü Boost target map
ü N75 duty cycle map (e.g. wastegate/VG control)
ü Boost limit map
ü Single value boost limiter
Driver wish map
The driver wish map determines not only the maximum torque/power output of the car but also the driveability of it. It determines the amount of requested fuel for the percentage of accelerator pedal depression and engine speed (e.g. for every throttle position % and engine speed there is a value that tells the amount of requested fuel for that specific point).
As you can see, the maximum (for throttle) request amount of fuel is 70 mg/stroke in this file.
To prevent the transmission and drivetrain components to suffer too much from low end torque the output power is restricted in low engine speeds. It also lets you limit torque when atmospheric pressure is lower then average (e.g. high in the mountains). This is done to prevent the turbo from overrevving.
The smoke limiter is there to prevent excessive smoke to appear when the user depresses the accelerator pedal. Smoke is generated when the air to fuel ratio in a diesel engine are lower than 1:17.
The smoke limiter tells the ECU not to inject more than the calibrated amount of fuel for any given amount of air entering the engine (airmass sensor data). If the driver wish map indicates (requests) 70 mg of air but there is only 1050 mg of air entering the engine the smoke limiter would limit the injected quantity to 55 mg of fuel @2750 rpm.
Injection duration map
The injected amount of fuel determines the amount of power produced (upto a certain limit anyway).
We can roughly estimate the amount of torque to be 1.5 * #cylinders * IQ (Injected Quantity). Injecting 60 mg/stroke in a 4 cylinder engine would then result in roughly 1.5 * 4 * 60 = 360 Nm of torque.Calculating power from torque can be done with this formula: Power (hp) = (Torque (Nm) * rpm)/7121.
Injecting the same 60 mg/stroke at 4000 rpm results in 360 * 4000 / 7121 = 202 hp.
This map tells the ECU how many crankshaft degrees it takes at a given engine speed to injected the requested amount of fuel.
The EGR (Exhaust Gas Recirculation) map determines how much fresh air is allowed to enter the engine for a given injection quantity and engine speed whenever the EGR function is active. The remainder of the amount of air is fed back into the engine by the EGR system. Since this is hot, contaminated air, we don’t want this in our engine from a performance point of view.
Communication with the ECU
There are three methods of communication that can be used with a EDC15P ECU.
· Boot mode communication
To activate KWP1281 communication we need to connect a K-line interface to the ECU on pin 16 and after the 5 baud wake-up procedure communication can commence at 9600 baud.
Wakeup procedure for normal mode
To be able to communicate in normal mode, the ECU needs to be aware of the fact that there is a
diagnostics device connected to pin 16 on the K-line. To let the ECU know we need to send a 0x01 byte to the port at 5 baud (!). After a correct wakeup byte on the 16 pin we will receive a response from the ECU at 9600 baud. This response will be 0x55 0x01 0x8A in which the 0x55 is the acknowledge and the 0x01 and 0x8A are the keywords used to communicate with the ECU. After reception of this sequence we need to send an acknowledge message to the ECU which is the inverted last keyword which will be 0x75.
Appendix I: Building a high speed K-line interface
The following information is sourced from skpang.co.uk.