Simos Wiki - User contributions [en]

Reverse Engineering Information

2022-02-24T20:14:11Z

Joedubs: /* Memory address lookup */

= Purpose of this section =

=Helpful links=
https://www.infineon.com/dgdl/tc_v131_instructionset_v138.pdf?fileId=db3a304412b407950112b409b6dd0352

https://www.infineon.com/dgdl/Infineon-SAK-TC1796-256F150E%20BE-DS-v01_00-EN.pdf?fileId=5546d46249a28d750149a34e1f28045d

https://www.infineon.com/dgdl/TriCore_EABI_v2_3.pdf?fileId=db3a304412b407950112b40f8d7a142b

=Quick Reference=
==Memory address lookup==
Registers a0, a1, a8, and a9 are used as offsets when the code needs to reference different memory locations.
There's a table in the ECU that sets up those offsets at boot:

<pre>
0000:808835CC movh.a a0, #0xD002
0000:808835D0 lea a0, [a0]-0x8000
0000:808835D4 movh.a a1, #0xA081
0000:808835D8 lea a1, [a1]-0x8000
0000:808835DC movh.a a8, #0x8005
0000:808835E0 lea a8, [a8]-0x7800
0000:808835E4 movh.a a9, #0xD001
0000:808835E8 lea a9, [a9]-0x4000
</pre>

What that means, is that at any point in the code, these registers always have the following values:
<pre>
a0: 0xD0018000
a1: 0xA0808000
a8: 0x80048800
a9: 0xD000C000
</pre>

18.10:
<pre>
a0: 0xD0018000
a1: 0x80828000
a8: 0x80028800
a9: 0xD000C000
</pre>

A quick example of how this is implemented in code:
<pre>
8019044a c9 00 de c9 ld.h d0,[a0]-0x60e2
</pre>

This takes the value of a0 (0xD0018000), subtracts 0x60e2 (=0xD0011F1E), and pulls the value of that memory address into d0. In the case of one common software version, that's:

<pre>
/begin MEASUREMENT tia_cha_up
"Air Temperature upstream the Charger"
SWORD
_CNV_A_R_CHRG_LINEA_171_CM
1
100.
-48.
335.994140625
DISPLAY_IDENTIFIER TIA_CHA_UP
ECU_ADDRESS 0xd0011f1e
FORMAT "%7.3"
/begin IF_DATA ETK
KP_BLOB
0xd0011f1e
INTERN
2
RASTER 30
/end IF_DATA
/end MEASUREMENT
</pre>

== Table address lookup ==
Table lookup in the calibration isn't as straightforward.
Occasionally you'll see reference in code to something like "0x8083DF8C". 0x8------- is the same as 0xA-------. So "0x8083DF8C" in the ASM is actually reference to 0xA083DF8C

Getting Started

2021-12-02T18:11:06Z

Joedubs: /* Commercial DIY Tuning */

= Where to begin =
So you've decided that you want to tune your 2015+ Audi A3, S3, VW GTI, Golf, Golf R, Sportwagen, or Alltrack....

Where do you start?

If you want the 'opensource' path, consider ordering a Tactrix cable and/or a Macchina A0.

== Tuning Options ==
Tuning options below are broken down into broad categories. Each option has it's pros and cons, and this list is not exhaustive. They're in no particular order (though opensource is listed first because it's why we're here.)

As noted around on other pages, tuning revolves around 3 main activities. They are:

#Editing
#Flashing
#Logging

As with anything, there's the possibility of going with a hybrid approach. If you want to use some company's flasher while using free tools to edit and/or log... have at it.

=== Open source ===
Strictly speaking, open source means the source code is freely available. For our purposes we'll use it a little more broadly to also cover freely available software (freeware) that may not be open sourced.

====Editing====

====Flashing====

====Logging====

=== Commercial DIY Tuning ===
From a DIY tuning standpoint there's really only 2 options available as of right now.
#Eurodyne Maestro
#HPTuners

====Editing====
=====Eurodyne=====

=====HPTuners=====

====Flashing/Logging====
Use their tools. You'll need to buy their cable and credits.
You may also be able to use other tools for logging as you become more familiar with the process

Getting Started

2021-12-02T18:09:16Z

Joedubs: /* Commercial Flashing */

Getting Started

2021-12-02T18:09:03Z

Joedubs: /* Commercial Tunes */

= Where to begin =
So you've decided that you want to tune your 2015+ Audi A3, S3, VW GTI, Golf, Golf R, Sportwagen, or Alltrack....

Where do you start?

If you want the 'opensource' path, consider ordering a Tactrix cable and/or a Macchina A0.

== Tuning Options ==
Tuning options below are broken down into broad categories. Each option has it's pros and cons, and this list is not exhaustive. They're in no particular order (though opensource is listed first because it's why we're here.)

As noted around on other pages, tuning revolves around 3 main activities. They are:

#Editing
#Flashing
#Logging

As with anything, there's the possibility of going with a hybrid approach. If you want to use some company's flasher while using free tools to edit and/or log... have at it.

=== Open source ===
Strictly speaking, open source means the source code is freely available. For our purposes we'll use it a little more broadly to also cover freely available software (freeware) that may not be open sourced.

====Editing====

====Flashing====

====Logging====

=== Commercial DIY Tuning ===
====Editing====
====Flashing====
====Logging====

=== Commercial Flashing ===
====Editing====
====Flashing====
====Logging====

Getting Started

2021-12-02T18:08:48Z

Joedubs: /* Where to begin */

= Where to begin =
So you've decided that you want to tune your 2015+ Audi A3, S3, VW GTI, Golf, Golf R, Sportwagen, or Alltrack....

Where do you start?

If you want the 'opensource' path, consider ordering a Tactrix cable and/or a Macchina A0.

== Tuning Options ==
Tuning options below are broken down into broad categories. Each option has it's pros and cons, and this list is not exhaustive. They're in no particular order (though opensource is listed first because it's why we're here.)

As noted around on other pages, tuning revolves around 3 main activities. They are:

#Editing
#Flashing
#Logging

As with anything, there's the possibility of going with a hybrid approach. If you want to use some company's flasher while using free tools to edit and/or log... have at it.

=== Open source ===
Strictly speaking, open source means the source code is freely available. For our purposes we'll use it a little more broadly to also cover freely available software (freeware) that may not be open sourced.

====Editing====

====Flashing====

====Logging====

=== Commercial Tunes ===
====Editing====
====Flashing====
====Logging====

=== Commercial DIY Tuning ===
====Editing====
====Flashing====
====Logging====

=== Commercial Flashing ===
====Editing====
====Flashing====
====Logging====

Getting Started

2021-12-02T18:06:39Z

Joedubs: /* Open source */

= Where to begin =
So you've decided that you want to tune your 2015+ Audi A3, S3, VW GTI, Golf, Golf R, Sportwagen, or Alltrack....

Where do you start?

== Tuning Options ==
Tuning options below are broken down into broad categories. Each option has it's pros and cons, and this list is not exhaustive. They're in no particular order (though opensource is listed first because it's why we're here.)

As noted around on other pages, tuning revolves around 3 main activities. They are:

#Editing
#Flashing
#Logging

As with anything, there's the possibility of going with a hybrid approach. If you want to use some company's flasher while using free tools to edit and/or log... have at it.

=== Open source ===
Strictly speaking, open source means the source code is freely available. For our purposes we'll use it a little more broadly to also cover freely available software (freeware) that may not be open sourced.

====Editing====

====Flashing====

====Logging====

=== Commercial Tunes ===
====Editing====
====Flashing====
====Logging====

=== Commercial DIY Tuning ===
====Editing====
====Flashing====
====Logging====

=== Commercial Flashing ===
====Editing====
====Flashing====
====Logging====

Getting Started

2021-12-02T18:05:21Z

Joedubs: /* Where to begin */

= Where to begin =
So you've decided that you want to tune your 2015+ Audi A3, S3, VW GTI, Golf, Golf R, Sportwagen, or Alltrack....

Where do you start?

== Tuning Options ==
Tuning options below are broken down into broad categories. Each option has it's pros and cons, and this list is not exhaustive. They're in no particular order (though opensource is listed first because it's why we're here.)

As noted around on other pages, tuning revolves around 3 main activities. They are:

#Editing
#Flashing
#Logging

As with anything, there's the possibility of going with a hybrid approach. If you want to use some company's flasher while using free tools to edit and/or log... have at it.

=== Open source ===
====Editing====
====Flashing====
====Logging====

=== Commercial Tunes ===
====Editing====
====Flashing====
====Logging====

=== Commercial DIY Tuning ===
====Editing====
====Flashing====
====Logging====

=== Commercial Flashing ===
====Editing====
====Flashing====
====Logging====

Getting Started

2021-12-02T17:58:39Z

Joedubs: /* Options */

= Where to begin =

== Tuning Options ==

=== Open source ===

=== Commercial Tunes ===

=== Commercial Tuning ===

=== Commercial Flashing ===

Getting Started

2021-12-02T17:58:07Z

Joedubs: /* Options */

= Options =

== Open source ==

== Commercial Tunes ==

== Commercial Tuning ==

== Commercial Flashing ==

Getting Started

2021-12-02T17:57:06Z

Joedubs: Created page with "= Options ="

= Options =

Open Source Tuning

2021-09-17T13:17:22Z

Joedubs: /* Getting started with a Stage X tune */

= What is it =
Open source tuning is, generally, the use of openly available tools to tune a car. Some would argue that you can even consider it open source tuning if you're using commercial tools since we're all relying on openly shared information.

= Who is it for =
[[File:Stage3.png|frameless]]

= How does it work =
The process follows along with the overview provided in other pages on here. To recap:
#Flash an application software to your ECU that allows for modified blocks
#Edit the calibration
#Flash the modified calibration
#Log the modifications and see what changed
##Logging with ED based ASW can be done by using the python based logger available here [[https://github.com/joeFischetti/SimosHighSpeedLogger SimosHighSpeedLogger]]

In the case of open source tuning we really need to rely on two things:
#The ability to flash files to the ECU
##Using some commercially provided solution
##Using some open source solution like @bri3d's [[https://github.com/bri3d/VW_Flash VW_FLASH]]
#The ability to edit the calibration
##Using software like RomRaider or TunerPro AND
##definitions files for the calibration (which point to where tables/maps/values are located in the raw bin) [[https://github.com/joeFischetti/SimosDefinitions Simos Definitions]]

Definitions by and large are built by other enthusiasts that have taken the time to locate the maps. There are *factory* definitions files (called A2L) that provide everything, but those will only be used with other commercial software. They're also not openly available.

= Why should I open source tune? =
Nobody can tell you why you should or shouldn't.... but in general:
#You'll learn more about your car/engine and how things work
#You'll feel better about the changes that you've made because you can learn how to optimize them
#You won't have anybody to point a finger at when something breaks
#You can make the community better by learning and sharing

= What are the risks? =
Total ECU brick and or broken hardware.
Nobody guarantees anything.

= How can I contribute =
If you want to help contribute to the open source project, start by getting acquainted with the process. Check out the github repos for the flasher tool and the definitions. And reach out to webmaster@simoswiki.com

= Thats cool - but how =
== Using Brian Ledbetters VW_FLASH Tool ==
Steps
#Build your tune(cal) in tunerpro
#Copy the cal to your raspberry pi
#Pre-reqs
#Checksum the cal
#Encrypt and compress the cal to prepare it for flashing
#Flash it

Directions below will assume you have a directory on your pi for the flash tool (/home/pi/VW_Flash) and for your tunes (/home/pi/flashfiles/tunes)

=== Copy the cal to your raspberry pi ===
A suggestion is to create a directory on your pi (within your home directory) that can hold all your tunes.
Something like /home/pi/flashfiles/tunes

Using something like winscp (or scp if you're on a mac, or any number of other methods to transfer files to your pi), transfer your tune file to this directory:

<pre>
pscp C:\somedirectory\thisismytune.bin pi@raspberrypi.local:/home/pi/flashfiles/tunes/thisismytune.bin
</pre>

=== Pre-reqs ===
<pre>
git clone https://github.com/bri3d/VW_Flash.git
cd /home/pi/VW_Flash
python3 -m pip install -r requirements.txt
cd ~/VW_Flash/lzss
make
</pre>

=== Checksum the cal ===
We won't re-explain everything... Just know that your file needs to be checksummed

Assuming you put the cal in /home/pi/flashfiles/tunes/thisismytune.bin
<pre>
cd /home/pi/VW_Flash
python3 checksumsimos18.py -i /home/pi/flashfiles/tunes/thisismytune.bin -o /home/pi/flashfiles/tunes/thisismytune.bin.checksummed --block 5
</pre>

The above commands will use the -i input file to create a -o output file that's been checksummed as a --block 5 (cal block) file.

=== Encrypt and compress the cal to prepare it for flashing ===
Thanks to Brian and David, we can then encrypt and prepare the CHECKSUMMED file for flashing by:
<pre>
cd /home/pi/VW_Flash
./prepareblock.sh /home/pi/flashfiles/tunes/thisismytune.bin.checksummed 5
</pre>

This is a bash script that will re-run the checksum checker and (if it's valid), compress the file using VW's keys, and then encrypt the file and append .flashable to it.
You'll now have a few extra files in your /home/pi/flashfiles/tunes directory. A worked example:
<pre>
pi@raspberrypi:~/VW_Flash $ ls -l /home/pi/flashfiles/tunes/
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin.checksummed
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin.checksummed.compressed
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin.checksummed.flashable
</pre>

The .compressed file is an intermediate file that we don't really need anymore. And the original .bin file is identical to the .checksummed file (except that the checksum doesn't match). You can continue to build your tune off of EITHER the .bin or the .bin.checksummed file since next time you make revisions - the file will be re-checksummed anyway.

=== Flash it ===
The fun part:
<pre>
cd /home/pi/VW_Flash
python3 flashsimos18.py --file /home/pi/flashfiles/tunes/thisismytune.bin.checksummed.flashable --block CAL
</pre>

This command will use the "flashable" file to flash it to the "CAL" block on the ECU. You can also use --block by number.

= Getting started with a Stage X tune =

== Limiters ==

== Fueling ==

== Torque Request ==

Open Source Tuning

2021-09-17T13:16:50Z

Joedubs: /* Thats cool - but how */

Open Source Tuning

2021-01-27T21:28:37Z

Joedubs: /* That's cool, but how */

= What is it =
Open source tuning is, generally, the use of openly available tools to tune a car. Some would argue that you can even consider it open source tuning if you're using commercial tools since we're all relying on openly shared information.

= Who is it for =

= How does it work =
The process follows along with the overview provided in other pages on here. To recap:
#Flash an application software to your ECU that allows for modified blocks
#Edit the calibration
#Flash the modified calibration
#Log the modifications and see what changed
##Logging with ED based ASW can be done by using the python based logger available here [[https://github.com/joeFischetti/SimosHighSpeedLogger SimosHighSpeedLogger]]

In the case of open source tuning we really need to rely on two things:
#The ability to flash files to the ECU
##Using some commercially provided solution
##Using some open source solution like @bri3d's [[https://github.com/bri3d/VW_Flash VW_FLASH]]
#The ability to edit the calibration
##Using software like RomRaider or TunerPro AND
##definitions files for the calibration (which point to where tables/maps/values are located in the raw bin) [[https://github.com/joeFischetti/SimosDefinitions Simos Definitions]]

Definitions by and large are built by other enthusiasts that have taken the time to locate the maps. There are *factory* definitions files (called A2L) that provide everything, but those will only be used with other commercial software. They're also not openly available.

= Why should I open source tune? =
Nobody can tell you why you should or shouldn't.... but in general:
#You'll learn more about your car/engine and how things work
#You'll feel better about the changes that you've made because you can learn how to optimize them
#You won't have anybody to point a finger at when something breaks
#You can make the community better by learning and sharing

= What are the risks? =
Total ECU brick and or broken hardware.
Nobody guarantees anything.

= How can I contribute =
If you want to help contribute to the open source project, start by getting acquainted with the process. Check out the github repos for the flasher tool and the definitions. And reach out to webmaster@simoswiki.com

= Thats cool - but how =
== Using Brian Ledbetters VW_FLASH Tool ==
Steps
#Build your tune(cal) in tunerpro
#Copy the cal to your raspberry pi
#Checksum the cal
#Encrypt and compress the cal to prepare it for flashing
#Flash it

Directions below will assume you have a directory on your pi for the flash tool (/home/pi/VW_FLASH) and for your tunes (/home/pi/flashfiles/tunes)

=== Copy the cal to your raspberry pi ===
A suggestion is to create a directory on your pi (within your home directory) that can hold all your tunes.
Something like /home/pi/flashfiles/tunes

Using something like winscp (or scp if you're on a mac, or any number of other methods to transfer files to your pi), transfer your tune file to this directory:

<pre>
pscp C:\somedirectory\thisismytune.bin pi@raspberrypi.local:/home/pi/flashfiles/tunes/thisismytune.bin
</pre>

=== Checksum the cal ===
We won't re-explain everything... Just know that your file needs to be checksummed

Assuming you put the cal in /home/pi/flashfiles/tunes/thisismytune.bin
<pre>
cd /home/pi/VW_FLASH
python3 checksumsimos.py -i /home/pi/flashfiles/tunes/thisismytune.bin -o /home/pi/flashfiles/tunes/thisismytune.bin.checksummed --block 5
</pre>

The above commands will use the -i input file to create a -o output file that's been checksummed as a --block 5 (cal block) file.

=== Encrypt and compress the cal to prepare it for flashing ===
Thanks to Brian and David, we can then encrypt and prepare the CHECKSUMMED file for flashing by:
<pre>
cd /home/pi/VW_FLASH
./prepareblock.sh /home/pi/flashfiles/tunes/thisismytune.bin.checksummed 5
</pre>

This is a bash script that will re-run the checksum checker and (if it's valid), compress the file using VW's keys, and then encrypt the file and append .flashable to it.
You'll now have a few extra files in your /home/pi/flashfiles/tunes directory. A worked example:
<pre>
pi@raspberrypi:~/VW_Flash $ ls -l /home/pi/flashfiles/tunes/
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin.checksummed
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin.checksummed.compressed
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin.checksummed.flashable
</pre>

The .compressed file is an intermediate file that we don't really need anymore. And the original .bin file is identical to the .checksummed file (except that the checksum doesn't match). You can continue to build your tune off of EITHER the .bin or the .bin.checksummed file since next time you make revisions - the file will be re-checksummed anyway.

=== Flash it ===
The fun part:
<pre>
cd /home/pi/VW_FLASH
python3 flashsimos18.py --file /home/pi/flashfiles/tunes/thisismytune.checksummed.flashable --block CAL
</pre>

This command will use the "flashable" file to flash it to the "CAL" block on the ECU. You can also use --block by number.

Open Source Tuning

2021-01-27T21:27:58Z

Joedubs: /* Encrypt and compress the cal to prepare it for flashing */

= What is it =
Open source tuning is, generally, the use of openly available tools to tune a car. Some would argue that you can even consider it open source tuning if you're using commercial tools since we're all relying on openly shared information.

= Who is it for =

= How does it work =
The process follows along with the overview provided in other pages on here. To recap:
#Flash an application software to your ECU that allows for modified blocks
#Edit the calibration
#Flash the modified calibration
#Log the modifications and see what changed
##Logging with ED based ASW can be done by using the python based logger available here [[https://github.com/joeFischetti/SimosHighSpeedLogger SimosHighSpeedLogger]]

In the case of open source tuning we really need to rely on two things:
#The ability to flash files to the ECU
##Using some commercially provided solution
##Using some open source solution like @bri3d's [[https://github.com/bri3d/VW_Flash VW_FLASH]]
#The ability to edit the calibration
##Using software like RomRaider or TunerPro AND
##definitions files for the calibration (which point to where tables/maps/values are located in the raw bin) [[https://github.com/joeFischetti/SimosDefinitions Simos Definitions]]

Definitions by and large are built by other enthusiasts that have taken the time to locate the maps. There are *factory* definitions files (called A2L) that provide everything, but those will only be used with other commercial software. They're also not openly available.

= Why should I open source tune? =
Nobody can tell you why you should or shouldn't.... but in general:
#You'll learn more about your car/engine and how things work
#You'll feel better about the changes that you've made because you can learn how to optimize them
#You won't have anybody to point a finger at when something breaks
#You can make the community better by learning and sharing

= What are the risks? =
Total ECU brick and or broken hardware.
Nobody guarantees anything.

= How can I contribute =
If you want to help contribute to the open source project, start by getting acquainted with the process. Check out the github repos for the flasher tool and the definitions. And reach out to webmaster@simoswiki.com

= That's cool, but how =
== Using Brian Ledbetters VW_FLASH Tool ==
Steps
#Build your tune(cal) in tunerpro
#Copy the cal to your raspberry pi
#Checksum the cal
#Encrypt and compress the cal to prepare it for flashing
#Flash it

Directions below will assume you have a directory on your pi for the flash tool (/home/pi/VW_FLASH) and for your tunes (/home/pi/flashfiles/tunes)

=== Copy the cal to your raspberry pi ===
A suggestion is to create a directory on your pi (within your home directory) that can hold all your tunes.
Something like /home/pi/flashfiles/tunes

Using something like winscp (or scp if you're on a mac, or any number of other methods to transfer files to your pi), transfer your tune file to this directory:

<pre>
pscp C:\somedirectory\thisismytune.bin pi@raspberrypi.local:/home/pi/flashfiles/tunes/thisismytune.bin
</pre>

=== Checksum the cal ===
We won't re-explain everything... Just know that your file needs to be checksummed

Assuming you put the cal in /home/pi/flashfiles/tunes/thisismytune.bin
<pre>
cd /home/pi/VW_FLASH
python3 checksumsimos.py -i /home/pi/flashfiles/tunes/thisismytune.bin -o /home/pi/flashfiles/tunes/thisismytune.bin.checksummed --block 5
</pre>

The above commands will use the -i input file to create a -o output file that's been checksummed as a --block 5 (cal block) file.

=== Encrypt and compress the cal to prepare it for flashing ===
Thanks to Brian and David, we can then encrypt and prepare the CHECKSUMMED file for flashing by:
<pre>
cd /home/pi/VW_FLASH
./prepareblock.sh /home/pi/flashfiles/tunes/thisismytune.bin.checksummed 5
</pre>

This is a bash script that will re-run the checksum checker and (if it's valid), compress the file using VW's keys, and then encrypt the file and append .flashable to it.
You'll now have a few extra files in your /home/pi/flashfiles/tunes directory. A worked example:
<pre>
pi@raspberrypi:~/VW_Flash $ ls -l /home/pi/flashfiles/tunes/
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin.checksummed
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin.checksummed.compressed
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin.checksummed.flashable
</pre>

The .compressed file is an intermediate file that we don't really need anymore. And the original .bin file is identical to the .checksummed file (except that the checksum doesn't match). You can continue to build your tune off of EITHER the .bin or the .bin.checksummed file since next time you make revisions - the file will be re-checksummed anyway.

=== Flash it ===
The fun part:
<pre>
cd /home/pi/VW_FLASH
python3 flashsimos18.py --file /home/pi/flashfiles/tunes/thisismytune.checksummed.flashable --block CAL
</pre>

This command will use the "flashable" file to flash it to the "CAL" block on the ECU. You can also use --block by number.

Open Source Tuning

2021-01-27T21:26:16Z

Joedubs: /* Copy the cal to your raspberry pi */

= What is it =
Open source tuning is, generally, the use of openly available tools to tune a car. Some would argue that you can even consider it open source tuning if you're using commercial tools since we're all relying on openly shared information.

= Who is it for =

= How does it work =
The process follows along with the overview provided in other pages on here. To recap:
#Flash an application software to your ECU that allows for modified blocks
#Edit the calibration
#Flash the modified calibration
#Log the modifications and see what changed
##Logging with ED based ASW can be done by using the python based logger available here [[https://github.com/joeFischetti/SimosHighSpeedLogger SimosHighSpeedLogger]]

In the case of open source tuning we really need to rely on two things:
#The ability to flash files to the ECU
##Using some commercially provided solution
##Using some open source solution like @bri3d's [[https://github.com/bri3d/VW_Flash VW_FLASH]]
#The ability to edit the calibration
##Using software like RomRaider or TunerPro AND
##definitions files for the calibration (which point to where tables/maps/values are located in the raw bin) [[https://github.com/joeFischetti/SimosDefinitions Simos Definitions]]

Definitions by and large are built by other enthusiasts that have taken the time to locate the maps. There are *factory* definitions files (called A2L) that provide everything, but those will only be used with other commercial software. They're also not openly available.

= Why should I open source tune? =
Nobody can tell you why you should or shouldn't.... but in general:
#You'll learn more about your car/engine and how things work
#You'll feel better about the changes that you've made because you can learn how to optimize them
#You won't have anybody to point a finger at when something breaks
#You can make the community better by learning and sharing

= What are the risks? =
Total ECU brick and or broken hardware.
Nobody guarantees anything.

= How can I contribute =
If you want to help contribute to the open source project, start by getting acquainted with the process. Check out the github repos for the flasher tool and the definitions. And reach out to webmaster@simoswiki.com

= That's cool, but how =
== Using Brian Ledbetters VW_FLASH Tool ==
Steps
#Build your tune(cal) in tunerpro
#Copy the cal to your raspberry pi
#Checksum the cal
#Encrypt and compress the cal to prepare it for flashing
#Flash it

Directions below will assume you have a directory on your pi for the flash tool (/home/pi/VW_FLASH) and for your tunes (/home/pi/flashfiles/tunes)

=== Copy the cal to your raspberry pi ===
A suggestion is to create a directory on your pi (within your home directory) that can hold all your tunes.
Something like /home/pi/flashfiles/tunes

Using something like winscp (or scp if you're on a mac, or any number of other methods to transfer files to your pi), transfer your tune file to this directory:

<pre>
pscp C:\somedirectory\thisismytune.bin pi@raspberrypi.local:/home/pi/flashfiles/tunes/thisismytune.bin
</pre>

=== Checksum the cal ===
We won't re-explain everything... Just know that your file needs to be checksummed

Assuming you put the cal in /home/pi/flashfiles/tunes/thisismytune.bin
<pre>
cd /home/pi/VW_FLASH
python3 checksumsimos.py -i /home/pi/flashfiles/tunes/thisismytune.bin -o /home/pi/flashfiles/tunes/thisismytune.bin.checksummed --block 5
</pre>

The above commands will use the -i input file to create a -o output file that's been checksummed as a --block 5 (cal block) file.

=== Encrypt and compress the cal to prepare it for flashing ===
Thanks to Brian and David, we can then encrypt and prepare the CHECKSUMMED file for flashing by:
<pre>
cd /home/pi/VW_FLASH
./prepareblock.sh /home/pi/flashfiles/tunes/thisismytune.bin.checksummed 5
</pre>

This is a bash script that will re-run the checksum checker and (if it's valid), encrypt the file using VW's keys, and then compress the file and append .flashable to it.
You'll now have a few extra files in your /home/pi/flashfiles/tunes directory. A worked example:
<pre>
pi@raspberrypi:~/VW_Flash $ ls -l /home/pi/flashfiles/tunes/
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin.checksummed
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin.checksummed.compressed
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin.checksummed.flashable
</pre>

The .compressed file is an intermediate file that we don't really need anymore. And the original .bin file is identical to the .checksummed file (except that it can't be flashed)

=== Flash it ===
The fun part:
<pre>
cd /home/pi/VW_FLASH
python3 flashsimos18.py --file /home/pi/flashfiles/tunes/thisismytune.checksummed.flashable --block CAL
</pre>

This command will use the "flashable" file to flash it to the "CAL" block on the ECU. You can also use --block by number.

Open Source Tuning

2021-01-27T21:23:09Z

Joedubs:

= What is it =
Open source tuning is, generally, the use of openly available tools to tune a car. Some would argue that you can even consider it open source tuning if you're using commercial tools since we're all relying on openly shared information.

= Who is it for =

= How does it work =
The process follows along with the overview provided in other pages on here. To recap:
#Flash an application software to your ECU that allows for modified blocks
#Edit the calibration
#Flash the modified calibration
#Log the modifications and see what changed
##Logging with ED based ASW can be done by using the python based logger available here [[https://github.com/joeFischetti/SimosHighSpeedLogger SimosHighSpeedLogger]]

In the case of open source tuning we really need to rely on two things:
#The ability to flash files to the ECU
##Using some commercially provided solution
##Using some open source solution like @bri3d's [[https://github.com/bri3d/VW_Flash VW_FLASH]]
#The ability to edit the calibration
##Using software like RomRaider or TunerPro AND
##definitions files for the calibration (which point to where tables/maps/values are located in the raw bin) [[https://github.com/joeFischetti/SimosDefinitions Simos Definitions]]

Definitions by and large are built by other enthusiasts that have taken the time to locate the maps. There are *factory* definitions files (called A2L) that provide everything, but those will only be used with other commercial software. They're also not openly available.

= Why should I open source tune? =
Nobody can tell you why you should or shouldn't.... but in general:
#You'll learn more about your car/engine and how things work
#You'll feel better about the changes that you've made because you can learn how to optimize them
#You won't have anybody to point a finger at when something breaks
#You can make the community better by learning and sharing

= What are the risks? =
Total ECU brick and or broken hardware.
Nobody guarantees anything.

= How can I contribute =
If you want to help contribute to the open source project, start by getting acquainted with the process. Check out the github repos for the flasher tool and the definitions. And reach out to webmaster@simoswiki.com

= That's cool, but how =
== Using Brian Ledbetters VW_FLASH Tool ==
Steps
#Build your tune(cal) in tunerpro
#Copy the cal to your raspberry pi
#Checksum the cal
#Encrypt and compress the cal to prepare it for flashing
#Flash it

Directions below will assume you have a directory on your pi for the flash tool (/home/pi/VW_FLASH) and for your tunes (/home/pi/flashfiles/tunes)

=== Copy the cal to your raspberry pi ===

=== Checksum the cal ===
We won't re-explain everything... Just know that your file needs to be checksummed

Assuming you put the cal in /home/pi/flashfiles/tunes/thisismytune.bin
<pre>
cd /home/pi/VW_FLASH
python3 checksumsimos.py -i /home/pi/flashfiles/tunes/thisismytune.bin -o /home/pi/flashfiles/tunes/thisismytune.bin.checksummed --block 5
</pre>

The above commands will use the -i input file to create a -o output file that's been checksummed as a --block 5 (cal block) file.

=== Encrypt and compress the cal to prepare it for flashing ===
Thanks to Brian and David, we can then encrypt and prepare the CHECKSUMMED file for flashing by:
<pre>
cd /home/pi/VW_FLASH
./prepareblock.sh /home/pi/flashfiles/tunes/thisismytune.bin.checksummed 5
</pre>

This is a bash script that will re-run the checksum checker and (if it's valid), encrypt the file using VW's keys, and then compress the file and append .flashable to it.
You'll now have a few extra files in your /home/pi/flashfiles/tunes directory. A worked example:
<pre>
pi@raspberrypi:~/VW_Flash $ ls -l /home/pi/flashfiles/tunes/
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin.checksummed
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin.checksummed.compressed
18tsi_MPI_IS38hybrid_FlexTiming_3000rpmscav_1.9bar_500nm.bin.checksummed.flashable
</pre>

The .compressed file is an intermediate file that we don't really need anymore. And the original .bin file is identical to the .checksummed file (except that it can't be flashed)

=== Flash it ===
The fun part:
<pre>
cd /home/pi/VW_FLASH
python3 flashsimos18.py --file /home/pi/flashfiles/tunes/thisismytune.checksummed.flashable --block CAL
</pre>

This command will use the "flashable" file to flash it to the "CAL" block on the ECU. You can also use --block by number.

Eurodyne Tables

2021-01-12T15:14:53Z

Joedubs: /* Factory ASW */

= Calibration tables =
== Limiters ==
=== Maximum Clutch Torque ===
The Maximum Clutch Torque tables are used to define the maximum available torque based on RPM and gear. The two tables represent MANUAL and DSG transmissions.
The ECU will look at the current Driver requested torque percentage (input from the pedal), along with the current RPM to arrive at the target torque value.

The Max torque tables can be used to limit torque delivery in certain gears.

[[File:boss_maxclutchtorque.png|500px]]

== Fueling ==
=== Basic Lambda vs Airmass DI ===
This table is the ''part throttle'' fueling map. The ECU will target the entered lambda values during part throttle (not pedal position). At full throttle, the ECU will switch to the "Full Load Lambda" fueling table. 

'''Note:''' "Full Throttle" can happen even if the accelerator pedal is not pushed completely down.

=== Full Load Lambda ===
This table is referenced when the ECU is in a full throttle situation. The X-Axis represents time elapsed in full load in seconds.

=== Lambda EGT Protection ===
This table determines the lambda target when the ECU determines EGT (exhaust gas temperature) is too high. You may consider using targets which are not as rich if you have an aftermarket DP.

=== Minimum Lambda Target ===
This is the absolute lowest lambda value that the ECU will target. The ECU will ignore any lower values in other fueling tables.

== Boost ==
=== Maximum Turbo Pressure Ratio ===
This table is used to define the maximum turbo boost at a given RPM range. The ECU will not attempt to overshoot this boost value. Measurements are relative boost pressure *not* absolute pressure.

[[File:maxturbopressureratio.png|500px]]

=== Map for boost pressure actuator setpoint ===
More commonly known as... wastegate duty cycle.

==== Factory ASW ====
FIRST PASS, NEED MORE DATA TO CONFIRM:

The way the wastegate duty cycle works is based on modeled turbocharger tables that calculate the turbine intake and exhaust flow factors. It's *impossible* to tune the wgdc on an ED tune without additional logging capability.

One possible way to tune the wgdc is to measure the following 4 variables:

<pre>
fac_1_put_ad - first parameter for precontrol and adaptation
fac_2_put_ad - second parameter for precontrol and adaptation
fac_pow_put_ctl_opl - Open loop value of PUT control
fac_pow_put_ctl_rgl - Regular value for PUT control
</pre>

In maestro, the axes are labeled incorrectly.
The X value is *actually* <code>fac_2_put_ad</code>, and the Y value is *actually* <code>fac_1_put_ad</code>.

Calculating the difference between <code>fac_pow_put_ctl_opl</code> and <code>fac_pow_put_ctl_rgl</code> will tell you how far off your wgdc table is from your actual wastegate control.

[[File:is20_wgdc.png|500px]]

==== Boss/Big turbo version ====

The Boss file uses a different strategy that's much more straightforward. To maintain X Boost at Y RPM open the gate Z percentage.

[[File:boss_wgdc.png|500px]]

== Timing ==

Ignition timing is determined by two look-up tables (Ignition timing, low octane and Ignition timing, high octane) and two settings tables (Min octane for adjustable features and Max octane for adjustable features). Within the Simos18 ECU there are additional lookup tables that will impact timing that Maestro does not access. Intake Air Temperature (IAT) as recorded by the MAP sensor is one such variable that will impact your timing advance. High IATs will retard timing to reduce the likelihood of pre-ignition due to high combustion temperatures within the cylinder. The ECU will override the two Maestro timing tables to ensure engine longevity in the face of extreme environmental conditions.

'''Min and Max octane for adjustable features'''

The two adjustable tables appear to represent timing for 80(low) and 100(high) octane. Setting the octane slider to some number will cause the ECU to perform a lookup against a (hidden to the user) table which defines the interpolation factor used to determine basic ignition angle. The min and max octane for adjustable features calibration settings are merely used to adjust the window that the slider will operate in. These two settings will not impact the timing interpolation.

'''Ignition timing, low and high octane'''

The tables have 3 axis:

* X axis is Air Mass per stroke
* Y Axis is Engine speed (RPM)
* Z axis (the field of cells) is ignition timing

As with any table within Maestro, the X and Y values can be modified to suit the users needs, however the Air Mass and RPM values as set on the base files should satisfy 99.99% of users and are not recommended to be modified.

'''Setting a Timing Curve'''

WARNING...DO NOT ADJUST ANY OF THE TIMING VALUES IN THE COLUMNS BELOW 1000MG/STROKE. Why? Daily driving around town from stoplight to stoplight the engine uses ignition timing fairly aggressively due to the lack of airmass (which is due to the lack of exhaust volume spinning the turbine) to power the vehicle. If you lower these values the car will feel sluggish at part throttle. If you increase these values the engine will knock. Only make changes to the last few columns of the tables. Once you get comfortable with tuning and are looking to move to more advanced manipulation (i.e bigger turbo, E85 blend timing, etc..) you may feel the need to increase or decrease values in some of the air mass columns in the 600-900 range. For larger framed/slow spooling turbos you may need to increase timing at low air mass to remove the off/on feeling. Winter gas blends often have less knock resistance that can often lead to excess low air mass/spool knock that one may seek to reduce without also reducing overall timing by adjusting the slider. Use your datalogs to make adjustments as needed. If you are consistently seeing knock in a few cylinders at a specific RPM range then adjust the timing down at that RPM and air mass area. It's best to make timing adjustments to both tables equally (or as equal as possible). If you are going to pull 1 degree of timing out at 6000 rpm in the 1299 air mass column then pull 0.375 from one and 0.75 from the other. If you feel like you need further reductions then pull more from the table that got the 0.375 reduction.

'''How much KR is too much KR?'''

This question comes up quite often. The answer is whatever you are most comfortable with. Some people don't want to see any KR. Some people say anything up to -3 degrees in 2 cylinders or less at the same time is ok. Most would agree that -4 or more is not a great idea and one should remedy that. Some cars seem more prone to KR, some have KR at specific RPM ranges that can't be removed with meth or even full E85. You might see one cylinder in particular that has more KR events than the others. Every motor is different. Use your own comfort level when setting timing.

'''~*~*~*~* Flame 'n' Bang ~*~*~*~*'''

You bang, bang, bang, bang, bang

Then flame, flame, flame

You bang, bang, bang, bang, bang

It's not my thing, so let it go

-Diggs

= Unofficial changelog =
Lol

Eurodyne Tables

2021-01-12T15:13:54Z

Joedubs: /* Factory file */

= Calibration tables =
== Limiters ==
=== Maximum Clutch Torque ===
The Maximum Clutch Torque tables are used to define the maximum available torque based on RPM and gear. The two tables represent MANUAL and DSG transmissions.
The ECU will look at the current Driver requested torque percentage (input from the pedal), along with the current RPM to arrive at the target torque value.

The Max torque tables can be used to limit torque delivery in certain gears.

[[File:boss_maxclutchtorque.png|500px]]

== Fueling ==
=== Basic Lambda vs Airmass DI ===
This table is the ''part throttle'' fueling map. The ECU will target the entered lambda values during part throttle (not pedal position). At full throttle, the ECU will switch to the "Full Load Lambda" fueling table. 

'''Note:''' "Full Throttle" can happen even if the accelerator pedal is not pushed completely down.

=== Full Load Lambda ===
This table is referenced when the ECU is in a full throttle situation. The X-Axis represents time elapsed in full load in seconds.

=== Lambda EGT Protection ===
This table determines the lambda target when the ECU determines EGT (exhaust gas temperature) is too high. You may consider using targets which are not as rich if you have an aftermarket DP.

=== Minimum Lambda Target ===
This is the absolute lowest lambda value that the ECU will target. The ECU will ignore any lower values in other fueling tables.

== Boost ==
=== Maximum Turbo Pressure Ratio ===
This table is used to define the maximum turbo boost at a given RPM range. The ECU will not attempt to overshoot this boost value. Measurements are relative boost pressure *not* absolute pressure.

[[File:maxturbopressureratio.png|500px]]

=== Map for boost pressure actuator setpoint ===
More commonly known as... wastegate duty cycle.

==== Factory ASW ====
FIRST PASS, NEED MORE DATA TO CONFIRM:

The way the wastegate duty cycle works is based on modeled turbocharger tables that calculate the turbine intake and exhaust flow factors. It's *impossible* to tune the wgdc on an ED tune without additional logging capability.

One possible way to tune the wgdc is to measure the following 4 variables:

<pre>
fac_1_put_ad - first parameter for precontrol and adaptation
fac_2_put_ad - second parameter for precontrol and adaptation
fac_pow_put_ctl_opl - Open loop value of PUT control
fac_pow_put_ctl_rgl - Regular value for PUT control
</pre>

In maestro, the axes are labeled incorrectly.
The X value is *actually* `fac_2_put_ad`, and the Y value is *actually* `fac_1_put_ad`.

Calculating the difference between `fac_pow_put_ctl_opl` and `fac_pow_put_ctl_rgl` will tell you how far off your wgdc table is from your actual wastegate control.

[[File:is20_wgdc.png|500px]]

==== Boss/Big turbo version ====

The Boss file uses a different strategy that's much more straightforward. To maintain X Boost at Y RPM open the gate Z percentage.

[[File:boss_wgdc.png|500px]]

== Timing ==

Ignition timing is determined by two look-up tables (Ignition timing, low octane and Ignition timing, high octane) and two settings tables (Min octane for adjustable features and Max octane for adjustable features). Within the Simos18 ECU there are additional lookup tables that will impact timing that Maestro does not access. Intake Air Temperature (IAT) as recorded by the MAP sensor is one such variable that will impact your timing advance. High IATs will retard timing to reduce the likelihood of pre-ignition due to high combustion temperatures within the cylinder. The ECU will override the two Maestro timing tables to ensure engine longevity in the face of extreme environmental conditions.

'''Min and Max octane for adjustable features'''

The two adjustable tables appear to represent timing for 80(low) and 100(high) octane. Setting the octane slider to some number will cause the ECU to perform a lookup against a (hidden to the user) table which defines the interpolation factor used to determine basic ignition angle. The min and max octane for adjustable features calibration settings are merely used to adjust the window that the slider will operate in. These two settings will not impact the timing interpolation.

'''Ignition timing, low and high octane'''

The tables have 3 axis:

* X axis is Air Mass per stroke
* Y Axis is Engine speed (RPM)
* Z axis (the field of cells) is ignition timing

As with any table within Maestro, the X and Y values can be modified to suit the users needs, however the Air Mass and RPM values as set on the base files should satisfy 99.99% of users and are not recommended to be modified.

'''Setting a Timing Curve'''

WARNING...DO NOT ADJUST ANY OF THE TIMING VALUES IN THE COLUMNS BELOW 1000MG/STROKE. Why? Daily driving around town from stoplight to stoplight the engine uses ignition timing fairly aggressively due to the lack of airmass (which is due to the lack of exhaust volume spinning the turbine) to power the vehicle. If you lower these values the car will feel sluggish at part throttle. If you increase these values the engine will knock. Only make changes to the last few columns of the tables. Once you get comfortable with tuning and are looking to move to more advanced manipulation (i.e bigger turbo, E85 blend timing, etc..) you may feel the need to increase or decrease values in some of the air mass columns in the 600-900 range. For larger framed/slow spooling turbos you may need to increase timing at low air mass to remove the off/on feeling. Winter gas blends often have less knock resistance that can often lead to excess low air mass/spool knock that one may seek to reduce without also reducing overall timing by adjusting the slider. Use your datalogs to make adjustments as needed. If you are consistently seeing knock in a few cylinders at a specific RPM range then adjust the timing down at that RPM and air mass area. It's best to make timing adjustments to both tables equally (or as equal as possible). If you are going to pull 1 degree of timing out at 6000 rpm in the 1299 air mass column then pull 0.375 from one and 0.75 from the other. If you feel like you need further reductions then pull more from the table that got the 0.375 reduction.

'''How much KR is too much KR?'''

This question comes up quite often. The answer is whatever you are most comfortable with. Some people don't want to see any KR. Some people say anything up to -3 degrees in 2 cylinders or less at the same time is ok. Most would agree that -4 or more is not a great idea and one should remedy that. Some cars seem more prone to KR, some have KR at specific RPM ranges that can't be removed with meth or even full E85. You might see one cylinder in particular that has more KR events than the others. Every motor is different. Use your own comfort level when setting timing.

'''~*~*~*~* Flame 'n' Bang ~*~*~*~*'''

You bang, bang, bang, bang, bang

Then flame, flame, flame

You bang, bang, bang, bang, bang

It's not my thing, so let it go

-Diggs

= Unofficial changelog =
Lol

Eurodyne Tables

2021-01-12T15:13:18Z

Joedubs: /* Map for boost pressure actuator setpoint */

= Calibration tables =
== Limiters ==
=== Maximum Clutch Torque ===
The Maximum Clutch Torque tables are used to define the maximum available torque based on RPM and gear. The two tables represent MANUAL and DSG transmissions.
The ECU will look at the current Driver requested torque percentage (input from the pedal), along with the current RPM to arrive at the target torque value.

The Max torque tables can be used to limit torque delivery in certain gears.

[[File:boss_maxclutchtorque.png|500px]]

== Fueling ==
=== Basic Lambda vs Airmass DI ===
This table is the ''part throttle'' fueling map. The ECU will target the entered lambda values during part throttle (not pedal position). At full throttle, the ECU will switch to the "Full Load Lambda" fueling table. 

'''Note:''' "Full Throttle" can happen even if the accelerator pedal is not pushed completely down.

=== Full Load Lambda ===
This table is referenced when the ECU is in a full throttle situation. The X-Axis represents time elapsed in full load in seconds.

=== Lambda EGT Protection ===
This table determines the lambda target when the ECU determines EGT (exhaust gas temperature) is too high. You may consider using targets which are not as rich if you have an aftermarket DP.

=== Minimum Lambda Target ===
This is the absolute lowest lambda value that the ECU will target. The ECU will ignore any lower values in other fueling tables.

== Boost ==
=== Maximum Turbo Pressure Ratio ===
This table is used to define the maximum turbo boost at a given RPM range. The ECU will not attempt to overshoot this boost value. Measurements are relative boost pressure *not* absolute pressure.

[[File:maxturbopressureratio.png|500px]]

=== Map for boost pressure actuator setpoint ===
More commonly known as... wastegate duty cycle.

==== Factory file ====
FIRST PASS, NEED MORE DATA TO CONFIRM:

The way the wastegate duty cycle works is based on modeled turbocharger tables that calculate the turbine intake and exhaust flow factors. It's *impossible* to tune the wgdc on an ED tune without additional logging capability.

One possible way to tune the wgdc is to measure the following 4 variables:
```
fac_1_put_ad - first parameter for precontrol and adaptation
fac_2_put_ad - second parameter for precontrol and adaptation
fac_pow_put_ctl_opl - Open loop value of PUT control
fac_pow_put_ctl_rgl - Regular value for PUT control
```
In maestro, the axes are labeled incorrectly.
The X value is *actually* `fac_2_put_ad`, and the Y value is *actually* `fac_1_put_ad`.

Calculating the difference between `fac_pow_put_ctl_opl` and `fac_pow_put_ctl_rgl` will tell you how far off your wgdc table is from your actual wastegate control.

[[File:is20_wgdc.png|500px]]

==== Boss/Big turbo version ====

The Boss file uses a different strategy that's much more straightforward. To maintain X Boost at Y RPM open the gate Z percentage.

[[File:boss_wgdc.png|500px]]

== Timing ==

Ignition timing is determined by two look-up tables (Ignition timing, low octane and Ignition timing, high octane) and two settings tables (Min octane for adjustable features and Max octane for adjustable features). Within the Simos18 ECU there are additional lookup tables that will impact timing that Maestro does not access. Intake Air Temperature (IAT) as recorded by the MAP sensor is one such variable that will impact your timing advance. High IATs will retard timing to reduce the likelihood of pre-ignition due to high combustion temperatures within the cylinder. The ECU will override the two Maestro timing tables to ensure engine longevity in the face of extreme environmental conditions.

'''Min and Max octane for adjustable features'''

The two adjustable tables appear to represent timing for 80(low) and 100(high) octane. Setting the octane slider to some number will cause the ECU to perform a lookup against a (hidden to the user) table which defines the interpolation factor used to determine basic ignition angle. The min and max octane for adjustable features calibration settings are merely used to adjust the window that the slider will operate in. These two settings will not impact the timing interpolation.

'''Ignition timing, low and high octane'''

The tables have 3 axis:

* X axis is Air Mass per stroke
* Y Axis is Engine speed (RPM)
* Z axis (the field of cells) is ignition timing

As with any table within Maestro, the X and Y values can be modified to suit the users needs, however the Air Mass and RPM values as set on the base files should satisfy 99.99% of users and are not recommended to be modified.

'''Setting a Timing Curve'''

WARNING...DO NOT ADJUST ANY OF THE TIMING VALUES IN THE COLUMNS BELOW 1000MG/STROKE. Why? Daily driving around town from stoplight to stoplight the engine uses ignition timing fairly aggressively due to the lack of airmass (which is due to the lack of exhaust volume spinning the turbine) to power the vehicle. If you lower these values the car will feel sluggish at part throttle. If you increase these values the engine will knock. Only make changes to the last few columns of the tables. Once you get comfortable with tuning and are looking to move to more advanced manipulation (i.e bigger turbo, E85 blend timing, etc..) you may feel the need to increase or decrease values in some of the air mass columns in the 600-900 range. For larger framed/slow spooling turbos you may need to increase timing at low air mass to remove the off/on feeling. Winter gas blends often have less knock resistance that can often lead to excess low air mass/spool knock that one may seek to reduce without also reducing overall timing by adjusting the slider. Use your datalogs to make adjustments as needed. If you are consistently seeing knock in a few cylinders at a specific RPM range then adjust the timing down at that RPM and air mass area. It's best to make timing adjustments to both tables equally (or as equal as possible). If you are going to pull 1 degree of timing out at 6000 rpm in the 1299 air mass column then pull 0.375 from one and 0.75 from the other. If you feel like you need further reductions then pull more from the table that got the 0.375 reduction.

'''How much KR is too much KR?'''

This question comes up quite often. The answer is whatever you are most comfortable with. Some people don't want to see any KR. Some people say anything up to -3 degrees in 2 cylinders or less at the same time is ok. Most would agree that -4 or more is not a great idea and one should remedy that. Some cars seem more prone to KR, some have KR at specific RPM ranges that can't be removed with meth or even full E85. You might see one cylinder in particular that has more KR events than the others. Every motor is different. Use your own comfort level when setting timing.

'''~*~*~*~* Flame 'n' Bang ~*~*~*~*'''

You bang, bang, bang, bang, bang

Then flame, flame, flame

You bang, bang, bang, bang, bang

It's not my thing, so let it go

-Diggs

= Unofficial changelog =
Lol

Fuel Management

2021-01-03T22:41:18Z

Joedubs: /* Port Injection */

= Fuel system basics =
THE best outline about the fuel system can be found in the following
[https://www.golfmk7.com/forums/index.php?threads/does-the-mqb-fuel-system-defy-physics-aka-why-do-i-need-a-huge-fuel-pump.367016/ thread].

== Flexfuel ==

The ECU will do automatic mass fuel flow (mff) compensation based on ethanol content. It can do this both with a sensor or sensorless.

By default, the calibration is set up to leverage a "manual" ethanol setting (which is what the ED code short circuits for the slider). When configured in automatic mode, the ECU will use algorithmic based flex fuel adaptation. By enabling a sensor (pinned to pin 71 [need to verify]), the ecu will instead use the sensor unless the sensor fails.

<pre>
Switch to use manual alternative fuel ratio
lc_fac_afu_ratio_man_act - set to [00] to disable

Logical value to indicate AFU sensor configuration
lc_fac_afu_ratio_conf - set to [00] to enable the sensor (not a typo)
</pre>

It also might be helpful to enable the PID output for e-content (PID 52)
Details start on page 23709 of the FR.
c_state_srv_1_pid[n][10] is the bit field that includes pid 52.

== Port Injection ==
In some markets, the EA888.3 series of engines are equipped with port direct injection (DI) and multiport injection (MPI). NA cars only include DI. In order to run larger turbos or increase the capability of the fuel system to run alternative fuels (e85) in a performance scenario, the MPI system can be added.

Continental didn't intend to use the MPI system in the way we use it (under full load, at high RPM, with big injectors) so when enabling the native MPI we also must change the logic that controls it. MPI, DI, and the way they work together are dictated through the use of [[#Combustion_Modes]] (along with other things).

== Combustion Modes ==
The combustion mode manager receives combustion mode requests from other engine operating managers. In the case of MPI at full load, we'll use the torque manager to define the window(s) where we want MPI to be active.

The torque manager has 6 combustion mode indices that can be controlled and triggered. Each of those combustion mode indices will have min and max RPM, as well as min and max torque tables that will define when that index is targeted. Changing which combustion mode a particular torque index references (and then tuning the max and min tables appropriately) will change whether we're targeting a standard combustion mode or a DI + MPI combustion mode.

Fuel Management

2021-01-03T22:41:07Z

Joedubs: /* Port Injection */

= Fuel system basics =
THE best outline about the fuel system can be found in the following
[https://www.golfmk7.com/forums/index.php?threads/does-the-mqb-fuel-system-defy-physics-aka-why-do-i-need-a-huge-fuel-pump.367016/ thread].

== Flexfuel ==

The ECU will do automatic mass fuel flow (mff) compensation based on ethanol content. It can do this both with a sensor or sensorless.

By default, the calibration is set up to leverage a "manual" ethanol setting (which is what the ED code short circuits for the slider). When configured in automatic mode, the ECU will use algorithmic based flex fuel adaptation. By enabling a sensor (pinned to pin 71 [need to verify]), the ecu will instead use the sensor unless the sensor fails.

<pre>
Switch to use manual alternative fuel ratio
lc_fac_afu_ratio_man_act - set to [00] to disable

Logical value to indicate AFU sensor configuration
lc_fac_afu_ratio_conf - set to [00] to enable the sensor (not a typo)
</pre>

It also might be helpful to enable the PID output for e-content (PID 52)
Details start on page 23709 of the FR.
c_state_srv_1_pid[n][10] is the bit field that includes pid 52.

== Port Injection ==
In some markets, the EA888.3 series of engines are equipped with port direct injection (DI) and multiport injection (MPI). NA cars only include DI. In order to run larger turbos or increase the capability of the fuel system to run alternative fuels (e85) in a performance scenario, the MPI system can be added.

Continental didn't intend to use the MPI system in the way we use it (under full load, at high RPM, with big injectors) so when enabling the native MPI we also must change the logic that controls it. MPI, DI, and the way they work together are dictated through the use of [[Combustion_Modes]] (along with other things).

== Combustion Modes ==
The combustion mode manager receives combustion mode requests from other engine operating managers. In the case of MPI at full load, we'll use the torque manager to define the window(s) where we want MPI to be active.

The torque manager has 6 combustion mode indices that can be controlled and triggered. Each of those combustion mode indices will have min and max RPM, as well as min and max torque tables that will define when that index is targeted. Changing which combustion mode a particular torque index references (and then tuning the max and min tables appropriately) will change whether we're targeting a standard combustion mode or a DI + MPI combustion mode.

Fuel Management

2021-01-03T22:40:44Z

Joedubs:

= Fuel system basics =
THE best outline about the fuel system can be found in the following
[https://www.golfmk7.com/forums/index.php?threads/does-the-mqb-fuel-system-defy-physics-aka-why-do-i-need-a-huge-fuel-pump.367016/ thread].

== Flexfuel ==

The ECU will do automatic mass fuel flow (mff) compensation based on ethanol content. It can do this both with a sensor or sensorless.

By default, the calibration is set up to leverage a "manual" ethanol setting (which is what the ED code short circuits for the slider). When configured in automatic mode, the ECU will use algorithmic based flex fuel adaptation. By enabling a sensor (pinned to pin 71 [need to verify]), the ecu will instead use the sensor unless the sensor fails.

<pre>
Switch to use manual alternative fuel ratio
lc_fac_afu_ratio_man_act - set to [00] to disable

Logical value to indicate AFU sensor configuration
lc_fac_afu_ratio_conf - set to [00] to enable the sensor (not a typo)
</pre>

It also might be helpful to enable the PID output for e-content (PID 52)
Details start on page 23709 of the FR.
c_state_srv_1_pid[n][10] is the bit field that includes pid 52.

== Port Injection ==
In some markets, the EA888.3 series of engines are equipped with port direct injection (DI) and multiport injection (MPI). NA cars only include DI. In order to run larger turbos or increase the capability of the fuel system to run alternative fuels (e85) in a performance scenario, the MPI system can be added.

Continental didn't intend to use the MPI system in the way we use it (under full load, at high RPM, with big injectors) so when enabling the native MPI we also must change the logic that controls it. MPI, DI, and the way they work together are dictated through the use of [Combustion_Modes] (along with other things).

== Combustion Modes ==
The combustion mode manager receives combustion mode requests from other engine operating managers. In the case of MPI at full load, we'll use the torque manager to define the window(s) where we want MPI to be active.

The torque manager has 6 combustion mode indices that can be controlled and triggered. Each of those combustion mode indices will have min and max RPM, as well as min and max torque tables that will define when that index is targeted. Changing which combustion mode a particular torque index references (and then tuning the max and min tables appropriately) will change whether we're targeting a standard combustion mode or a DI + MPI combustion mode.

Open Source Tuning

2021-01-03T22:39:11Z

Joedubs: /* How does it work */

Open Source Tuning

2021-01-03T22:37:53Z

Joedubs: /* How does it work */

Open Source Tuning

2021-01-03T22:37:19Z

Joedubs: Created page with "= What is it = Open source tuning is, generally, the use of openly available tools to tune a car. Some would argue that you can even consider it open source tuning if you're..."

Main Page

2021-01-03T22:24:07Z

Joedubs:

__NOTOC__
The SimosWiki

This site is dedicated to tuning the Simos(18) family of ECUs commonly found in the MQB platform of VW/Audi cars.

Much of the information here revolves around the use of Eurodyne Maestro since it was the first end user tuning software available. Eurodyne does change some maps and axis names, but the vast majority of ecu strategies are kept consistent with the way Continental designed it. An example of where there's a change in the software is the Boss file wastegate duty tables. The factory uses a complex scheme to calculate the exhaust flow vs Boost, while Eurodyne changes this to use a simple RPM vs. Boost level. Examples of the two different tables are on the [[Eurodyne_Tables|Eurodyne Maestro Tables]] page.

THIS WIKI IS A WORK IN PROGRESS. We went live with it on 9/21/2020, and we're working on getting info in place.

=== Select a topic from the left nav bar or the links below ===
[[High_Level_Overview|High level overview of ECU operation]]

[[Boost_Management|Boost Management]]

[[Fuel_Management|Fueling Management]]

[[Reverse_Engineering_Information|Reverse Engineering]]

[[Open_Source_Tuning|Open Source Tuning]]

=== Editing Software ===
Eurodyne Maestro (and HPTuners as of late 2020) are the only software suites that allow for end user modifications to the calibration tables

[[Eurodyne_Tables|Eurodyne Maestro Tables]] is an overview of the tables available in Eurodyne Maestro

[[HP_Tuners_Tables|HPTuners Tables]] is an overview of HPTuners software

=== Helpful Links ===
Note: External links will attempt to open in a new tab 
[https://cobbtuning.atlassian.net/wiki/spaces/PRS/pages/143753246/Volkswagen+MQB+Tuning+Guide Cobb Tuning Volkswagen MQB Tuning Guide] 
[https://ecutek.atlassian.net/wiki/spaces/SUPPORT/pages/21430325/VW+EA888+Engine+Tuning Ecutek EA888 Tuning Guide] 
[https://cobbtuning.atlassian.net/wiki/spaces/PRS/pages/619872308/Volkswagen+MQB+6+Speed+DSG+Tuning+Guide Cobb Tuning 6-Speed DSG Tuning Guide] 
[https://cobbtuning.atlassian.net/wiki/spaces/PRS/pages/1052606501/Volkswagen+MQB+7+Speed+DSG+Tuning+Guide Cobb Tuning 7-Speed DSG Tuning Guide] 
[https://www.youtube.com/watch?v=5wQ9lQq2vDQ Maestro MK7 GTI MQB, Basic overview (YouTube video)] 
[https://www.youtube.com/watch?v=0Yglshxokv4 Understanding AFR and Lambda] 
[http://www.nefariousmotorsports.com/forum/ Nefmoto] (Not a whole lot that's simos specific) 
[https://s4wiki.com/wiki/Tuning S4 Tuning Wiki] (Not Simos - but still can be helpful) 
[https://docs.google.com/spreadsheets/d/17nKlgeqHBmVnqw4OKaAGOJwZtXGkLNJo1yFMqe5oHck/edit?usp=sharing PID List (work in progress)]

=== Just saying ===
As with anything, you make modifications at your own risk. Nobody else is responsible for anything that happens while you're tuning your car.

If the information here has been helpful, consider donating. Domain names and web hosting aren't free.
*Paypal: webmaster@simoswiki.com
*Bitcoin: 34JVVe9pE7gZJ5Pu1B3rhWCPiV5SWavQL2

SIMOS is a registered trademark of CONTINENTAL AUTOMOTIVE GMBH. This site has no affiliation.

Fuel Management

2021-01-03T22:19:09Z

Joedubs:

= Fuel system basics =
THE best outline about the fuel system can be found in the following
[https://www.golfmk7.com/forums/index.php?threads/does-the-mqb-fuel-system-defy-physics-aka-why-do-i-need-a-huge-fuel-pump.367016/ thread].

== Flexfuel ==

The ECU will do automatic mass fuel flow (mff) compensation based on ethanol content. It can do this both with a sensor or sensorless.

By default, the calibration is set up to leverage a "manual" ethanol setting (which is what the ED code short circuits for the slider). When configured in automatic mode, the ECU will use algorithmic based flex fuel adaptation. By enabling a sensor (pinned to pin 71 [need to verify]), the ecu will instead use the sensor unless the sensor fails.

<pre>
Switch to use manual alternative fuel ratio
lc_fac_afu_ratio_man_act - set to [00] to disable

Logical value to indicate AFU sensor configuration
lc_fac_afu_ratio_conf - set to [00] to enable the sensor (not a typo)
</pre>

It also might be helpful to enable the PID output for e-content (PID 52)
Details start on page 23709 of the FR.
c_state_srv_1_pid[n][10] is the bit field that includes pid 52.

== Port Injection ==
In some markets, the EA888.3 series of engines are equipped with port direct injection (DI) and multiport injection (MPI). NA cars only include DI. In order to run larger turbos or increase the capability of the fuel system to run alternative fuels (e85) in a performance scenario, the MPI system can be added.

Continental didn't intend to use the MPI system in the way we use it (under full load, at high RPM, with big injectors) so when enabling the native MPI we also must change the logic that controls it. MPI, DI, and the way they work together are dictated through the use of combustion modes (along with other things).

The combustion mode manager receives combustion mode requests from other engine operating managers. In the case of MPI at full load, we'll use the torque manager to define the window(s) where we want MPI to be active.

The torque manager has 6 combustion mode indices that can be controlled and triggered. Each of those combustion mode indices will have min and max RPM, as well as min and max torque tables that will define when that index is targeted. Changing which combustion mode a particular torque index references (and then tuning the max and min tables appropriately) will change whether we're targeting a standard combustion mode or a DI + MPI combustion mode.

Fuel Management

2020-12-22T13:38:28Z

Joedubs:

Custom Features

2020-12-15T21:45:03Z

Joedubs: /* Performance flex fuel */

= Custom Features =

== Existing custom features ==
=== Eurodyne ===
==== Octane Slider ====
Eurodyne software includes custom features for an adjustable Octane slider. The way the adjustable octane slider works is this:

#There's a function call within the existing ignition angle calculation.
#There's custom code that checks to see if the slider is enabled
#No:
##use the "low octane" timing map (which has been repurposed from one of the existing timing maps)
#Yes:
##get the value from the slider (memory), and the minimum and maximum adjustable octane settings (cal)
##calculate an interpolation factor
##perform a map lookup against the low timing map
##perform a map lookup against the high timing map
##apply the interpolation factor to the basic timing outputs from the two timing maps
##Store the output as the basic ignition angle setting

== Proposed custom features ==
=== Performance flex fuel ===
The factory FlexFuel in the Simos18 has the capability of adjusting mass fuel flow (mff) for varying levels of alternative fuel both via a sensor and sensorless (using trims, etc). However, it doesn't have the ability to adjust timing.

Performance FlexFuel (@ZuMble) is the idea that in addition to handling the additional fuel required to reach stoich, the ECU can adjust timing to a point, as well.

A proposal:

Repurpose the Eurodyne [[#Octane_Slider]] so that instead of looking up the adjustable slider value and the min and max octane values - it looks up the %alternative fuel value (fac_afu_ratio_det/fac_afu_ratio), and calculates an interpolation value against that.

Existing settings for "min and max octane for adjustable features" can stay the same. The calibration can be adjusted for 0 - 50, for example.

Existing octane slider functionality would be overridden/removed. The implications of the slider 'write dynamic identifier' would need to be assessed

The following code in the octane lookup:
<pre>
movh.a a15,#0xd002
and
lea a15,[a15]-0x2172 //a15 = d001de8e
</pre>

Should change to:
<pre>
movh.a a15,0xd001
and
lea a15,[a15]-0x3e2e //a15 = 0xd000c1d2, fac_afu_ratio_sens_mmv
</pre>

Which in ASM is:
<pre>
91 20 00 fd => 91 10 00 fd
and
d9 ff ce ad => d9 ff 12 7c
</pre>

To make the search/replace more specific:
<pre>
40 f6 91 20 00 fd 40 c5 d9 dd => 40 f6 91 10 00 fd 40 c5 d9 dd
and
40 e4 d9 ff ce ad d9 cc ca ad => 40 e4 d9 ff 12 7c d9 cc ca ad
</pre>

Custom Features

2020-12-15T21:44:42Z

Joedubs: /* Performance flex fuel */

= Custom Features =

== Existing custom features ==
=== Eurodyne ===
==== Octane Slider ====
Eurodyne software includes custom features for an adjustable Octane slider. The way the adjustable octane slider works is this:

#There's a function call within the existing ignition angle calculation.
#There's custom code that checks to see if the slider is enabled
#No:
##use the "low octane" timing map (which has been repurposed from one of the existing timing maps)
#Yes:
##get the value from the slider (memory), and the minimum and maximum adjustable octane settings (cal)
##calculate an interpolation factor
##perform a map lookup against the low timing map
##perform a map lookup against the high timing map
##apply the interpolation factor to the basic timing outputs from the two timing maps
##Store the output as the basic ignition angle setting

== Proposed custom features ==
=== Performance flex fuel ===
The factory FlexFuel in the Simos18 has the capability of adjusting mass fuel flow (mff) for varying levels of alternative fuel both via a sensor and sensorless (using trims, etc). However, it doesn't have the ability to adjust timing.

Performance FlexFuel (@ZuMble) is the idea that in addition to handling the additional fuel required to reach stoich, the ECU can adjust timing to a point, as well.

A proposal:

Repurpose the Eurodyne [[#Octane_Slider]] so that instead of looking up the adjustable slider value and the min and max octane values - it looks up the %alternative fuel value (fac_afu_ratio_det/fac_afu_ratio), and calculates an interpolation value against that.

Existing settings for "min and max octane for adjustable features" can stay the same. The calibration can be adjusted for 0 - 50, for example.

Existing octane slider functionality would be overridden/removed. The implications of the slider 'write dynamic identifier' would need to be assessed

The following code in the octane lookup:
<pre>
movh.a a15,#0xd002
and
lea a15,[a15]-0x2172 //a15 = d001de8e
</pre>

Should change to:
<pre>
movh.a a15,0xd001
and
lea a15,[a15]-0x3e2e //a15 = 0xd000c1d2, fac_afu_ratio_sens_mmv
</pre>

Which in ASM is:
<pre>
91 20 00 fd -> 91 10 00 fd
and
d9 ff ce ad -> d9 ff 12 7c
</pre>

To make the search/replace more specific:
<pre>
40 f6 91 20 00 fd 40 c5 d9 dd> 40 f6 91 10 00 fd 40 c5 d9 dd
and
40 e4 d9 ff ce ad d9 cc ca ad> 40 e4 d9 ff 12 7c d9 cc ca ad
</pre>

Custom Features

2020-12-15T21:43:04Z

Joedubs: /* Performance flex fuel */

= Custom Features =

== Existing custom features ==
=== Eurodyne ===
==== Octane Slider ====
Eurodyne software includes custom features for an adjustable Octane slider. The way the adjustable octane slider works is this:

#There's a function call within the existing ignition angle calculation.
#There's custom code that checks to see if the slider is enabled
#No:
##use the "low octane" timing map (which has been repurposed from one of the existing timing maps)
#Yes:
##get the value from the slider (memory), and the minimum and maximum adjustable octane settings (cal)
##calculate an interpolation factor
##perform a map lookup against the low timing map
##perform a map lookup against the high timing map
##apply the interpolation factor to the basic timing outputs from the two timing maps
##Store the output as the basic ignition angle setting

== Proposed custom features ==
=== Performance flex fuel ===
The factory FlexFuel in the Simos18 has the capability of adjusting mass fuel flow (mff) for varying levels of alternative fuel both via a sensor and sensorless (using trims, etc). However, it doesn't have the ability to adjust timing.

Performance FlexFuel (@ZuMble) is the idea that in addition to handling the additional fuel required to reach stoich, the ECU can adjust timing to a point, as well.

A proposal:

Repurpose the Eurodyne [[#Octane_Slider]] so that instead of looking up the adjustable slider value and the min and max octane values - it looks up the %alternative fuel value (fac_afu_ratio_det/fac_afu_ratio), and calculates an interpolation value against that.

Existing settings for "min and max octane for adjustable features" can stay the same. The calibration can be adjusted for 0 - 50, for example.

Existing octane slider functionality would be overridden/removed. The implications of the slider 'write dynamic identifier' would need to be assessed

The following code in the octane lookup:
<pre>
movh.a a15,#0xd002
and
lea a15,[a15]-0x2172 //a15 = d001de8e
</pre>

Should change to:
<pre>
movh.a a15,0xd001
and
lea a15,[a15]-0x3e2e //a15 = 0xd000c1d2, fac_afu_ratio_sens_mmv
</pre>

Which in ASM is:
<pre>
91 20 00 fd -> 91 10 00 fd
and
d9 ff ce ad -> d9 ff 12 7c
</pre>

To make the search/replace more specific:
<pre>
40 f6 91 20 00 fd 40 c5 > 40 f6 91 10 00 fd 40 c5
and
40 e4 d9 ff ce ad d9 cc > 40 e4 d9 ff 12 7c d9 cc
</pre>

Custom Features

2020-12-15T21:35:37Z

Joedubs: /* Performance flex fuel */

= Custom Features =

== Existing custom features ==
=== Eurodyne ===
==== Octane Slider ====
Eurodyne software includes custom features for an adjustable Octane slider. The way the adjustable octane slider works is this:

#There's a function call within the existing ignition angle calculation.
#There's custom code that checks to see if the slider is enabled
#No:
##use the "low octane" timing map (which has been repurposed from one of the existing timing maps)
#Yes:
##get the value from the slider (memory), and the minimum and maximum adjustable octane settings (cal)
##calculate an interpolation factor
##perform a map lookup against the low timing map
##perform a map lookup against the high timing map
##apply the interpolation factor to the basic timing outputs from the two timing maps
##Store the output as the basic ignition angle setting

== Proposed custom features ==
=== Performance flex fuel ===
The factory FlexFuel in the Simos18 has the capability of adjusting mass fuel flow (mff) for varying levels of alternative fuel both via a sensor and sensorless (using trims, etc). However, it doesn't have the ability to adjust timing.

Performance FlexFuel (@ZuMble) is the idea that in addition to handling the additional fuel required to reach stoich, the ECU can adjust timing to a point, as well.

A proposal:

Repurpose the Eurodyne [[#Octane_Slider]] so that instead of looking up the adjustable slider value and the min and max octane values - it looks up the %alternative fuel value (fac_afu_ratio_det/fac_afu_ratio), and calculates an interpolation value against that.

Existing settings for "min and max octane for adjustable features" can stay the same. The calibration can be adjusted for 0 - 50, for example.

Existing octane slider functionality would be overridden/removed. The implications of the slider 'write dynamic identifier' would need to be assessed

The following code in the octane lookup:
<pre>
movh.a a15,#0xd002
and
lea a15,[a15]-0x2172 //a15 = d001de8e
</pre>

Should change to:
<pre>
movh.a a15,0xd001
and
lea a15,[a15]-0x3e2e //a15 = 0xd000c1d2, fac_afu_ratio_sens_mmv
</pre>

Which in ASM is:
<pre>
91 20 00 fd -> 91 10 00 fd
and
d9 ff ce ad -> d9 ff 12 7c
</pre>

Eurodyne Tables

2020-12-11T20:17:40Z

Joedubs: /* Timing */

= Calibration tables =
== Limiters ==
=== Maximum Clutch Torque ===
The Maximum Clutch Torque tables are used to define the maximum available torque based on RPM and gear. The two tables represent MANUAL and DSG transmissions.
The ECU will look at the current Driver requested torque percentage (input from the pedal), along with the current RPM to arrive at the target torque value.

The Max torque tables can be used to limit torque delivery in certain gears.

[[File:boss_maxclutchtorque.png|500px]]

== Fueling ==
=== Basic Lambda vs Airmass DI ===
This table is the ''part throttle'' fueling map. The ECU will target the entered lambda values during part throttle (not pedal position). At full throttle, the ECU will switch to the "Full Load Lambda" fueling table. 

'''Note:''' "Full Throttle" can happen even if the accelerator pedal is not pushed completely down.

=== Full Load Lambda ===
This table is referenced when the ECU is in a full throttle situation. The X-Axis represents time elapsed in full load in seconds.

=== Lambda EGT Protection ===
This table determines the lambda target when the ECU determines EGT (exhaust gas temperature) is too high. You may consider using targets which are not as rich if you have an aftermarket DP.

=== Minimum Lambda Target ===
This is the absolute lowest lambda value that the ECU will target. The ECU will ignore any lower values in other fueling tables.

== Boost ==
=== Maximum Turbo Pressure Ratio ===
This table is used to define the maximum turbo boost at a given RPM range. The ECU will not attempt to overshoot this boost value. Measurements are relative boost pressure *not* absolute pressure.

[[File:maxturbopressureratio.png|500px]]

=== Map for boost pressure actuator setpoint ===
More commonly known as... wastegate duty cycle (though it's the reverse).

==== Factory file ====
TBD

[[File:is20_wgdc.png|500px]]

==== Boss/Big turbo version ====

The Boss file uses a different strategy that's much more straightforward. To maintain X Boost at Y RPM open the gate Z percentage.

[[File:boss_wgdc.png|500px]]

== Timing ==

Ignition timing is determined by two look-up tables (Ignition timing, low octane and Ignition timing, high octane) and two settings tables (Min octane for adjustable features and Max octane for adjustable features). Within the Simos18 ECU there are additional lookup tables that will impact timing that Maestro does not access. Intake Air Temperature (IAT) as recorded by the MAP sensor is one such variable that will impact your timing advance. High IATs will retard timing to reduce the likelihood of pre-ignition due to high combustion temperatures within the cylinder. The ECU will override the two Maestro timing tables to ensure engine longevity in the face of extreme environmental conditions.

'''Min and Max octane for adjustable features'''

The two adjustable tables appear to represent timing for 80(low) and 100(high) octane. Setting the octane slider to some number will cause the ECU to perform a lookup against a (hidden to the user) table which defines the interpolation factor used to determine basic ignition angle. The min and max octane for adjustable features calibration settings are merely used to adjust the window that the slider will operate in. These two settings will not impact the timing interpolation.

'''Ignition timing, low and high octane'''

The tables have 3 axis:

* X axis is Air Mass per stroke
* Y Axis is Engine speed (RPM)
* Z axis (the field of cells) is ignition timing

As with any table within Maestro, the X and Y values can be modified to suit the users needs, however the Air Mass and RPM values as set on the base files should satisfy 99.99% of users and are not recommended to be modified.

The two lookup tables serve as reference points for the ECU based on the user selected octane slider. As an example, if air mass at 3000 rpm is 600 mg/stroke and the low table shows 5.250 and the high table shows 13.875 the ECU will then look at the octane slider value and interpolate timing. Keeping the stock settings of 87 low and 100 high there are 14 different timing values that could be used. The delta between low and high for our example is 13.875-5.25=8.625. 8.625/14=0.62. For every increase in 1 above 87 on the octane slider the ECU will attempt to run approximately 0.62 degrees timing above the value in the low table. If you set the slider to 99 (13/14 available positions) then the timing will be 13*0.62=8.06 added to 5.25=13.31 (Maestro only allows values as multiples of 0.375 so in actuality the timing would be 13.125...close enough).

'''Setting a Timing Curve'''

WARNING...DO NOT ADJUST ANY OF THE TIMING VALUES IN THE COLUMNS BELOW 1000MG/STROKE. Why? Daily driving around town from stoplight to stoplight the engine uses ignition timing fairly aggressively due to the lack of airmass (which is due to the lack of exhaust volume spinning the turbine) to power the vehicle. If you lower these values the car will feel sluggish at part throttle. If you increase these values the engine will knock. Only make changes to the last few columns of the tables. Once you get comfortable with tuning and are looking to move to more advanced manipulation (i.e bigger turbo, E85 blend timing, etc..) you may feel the need to increase or decrease values in some of the air mass columns in the 600-900 range. For larger framed/slow spooling turbos you may need to increase timing at low air mass to remove the off/on feeling. Winter gas blends often have less knock resistance that can often lead to excess low air mass/spool knock that one may seek to reduce without also reducing overall timing by adjusting the slider. Use your datalogs to make adjustments as needed. If you are consistently seeing knock in a few cylinders at a specific RPM range then adjust the timing down at that RPM and air mass area. It's best to make timing adjustments to both tables equally (or as equal as possible). If you are going to pull 1 degree of timing out at 6000 rpm in the 1299 air mass column then pull 0.375 from one and 0.75 from the other. If you feel like you need further reductions then pull more from the table that got the 0.375 reduction.

'''How much KR is too much KR?'''

This question comes up quite often. The answer is whatever you are most comfortable with. Some people don't want to see any KR. Some people say anything up to -3 degrees in 2 cylinders or less at the same time is ok. Most would agree that -4 or more is not a great idea and one should remedy that. Some cars seem more prone to KR, some have KR at specific RPM ranges that can't be removed with meth or even full E85. You might see one cylinder in particular that has more KR events than the others. Every motor is different. Use your own comfort level when setting timing.

== Crackle ==
- To be added by Diggs

= Unofficial changelog =
Lol

Custom Features

2020-12-06T04:10:48Z

Joedubs: /* Performance flex fuel */

Custom Features

2020-12-06T04:08:53Z

Joedubs: /* Proposed custom features */

= Custom Features =

== Existing custom features ==
=== Eurodyne ===
==== Octane Slider ====
Eurodyne software includes custom features for an adjustable Octane slider. The way the adjustable octane slider works is this:

#There's a function call within the existing ignition angle calculation.
#There's custom code that checks to see if the slider is enabled
#No:
##use the "low octane" timing map (which has been repurposed from one of the existing timing maps)
#Yes:
##get the value from the slider (memory), and the minimum and maximum adjustable octane settings (cal)
##calculate an interpolation factor
##perform a map lookup against the low timing map
##perform a map lookup against the high timing map
##apply the interpolation factor to the basic timing outputs from the two timing maps
##Store the output as the basic ignition angle setting

== Proposed custom features ==
=== Performance flex fuel ===
The factory FlexFuel in the Simos18 has the capability of adjusting mass fuel flow (mff) for varying levels of alternative fuel both via a sensor and sensorless (using trims, etc). However, it doesn't have the ability to adjust timing.

Performance FlexFuel (@ZuMble) is the idea that in addition to handling the additional fuel required to reach stoich, the ECU can adjust timing to a point, as well.

A proposal:

Repurpose the Eurodyne [[#Octane_Slider]] so that instead of looking up the adjustable slider value and the min and max octane values - it looks up the %alternative fuel value (measured), and calculates an interpolation value against that.

Existing settings for min and max octane for adjustable features can stay the same. The calibration can be adjusted for 0 - 50, for example.

Existing octane slider functionality would be overridden/removed.

Repurpose

Custom Features

2020-12-06T04:08:08Z

Joedubs: /* Performance flex fuel */

= Custom Features =

== Existing custom features ==
=== Eurodyne ===
==== Octane Slider ====
Eurodyne software includes custom features for an adjustable Octane slider. The way the adjustable octane slider works is this:

#There's a function call within the existing ignition angle calculation.
#There's custom code that checks to see if the slider is enabled
#No:
##use the "low octane" timing map (which has been repurposed from one of the existing timing maps)
#Yes:
##get the value from the slider (memory), and the minimum and maximum adjustable octane settings (cal)
##calculate an interpolation factor
##perform a map lookup against the low timing map
##perform a map lookup against the high timing map
##apply the interpolation factor to the basic timing outputs from the two timing maps
##Store the output as the basic ignition angle setting

== Proposed custom features ==
=== Performance flex fuel ===
The factory FlexFuel in the Simos18 has the capability of adjusting mass fuel flow (mff) for varying levels of alternative fuel both via a sensor and sensorless (using trims, etc). However, it doesn't have the ability to adjust timing.

Performance FlexFuel (@ZuMble) is the idea that in addition to handling the additional fuel required to reach stoich, the ECU can adjust timing to a point, as well. Ethanol increases knock resistance.

A proposal:

Repurpose the Eurodyne [[#Octane_Slider]] so that instead of looking up the adjustable slider value and the min and max octane values - it looks up the %alternative fuel value (measured), and calculates an interpolation value against that.

Existing settings for min and max octane for adjustable features can stay the same. The calibration can be adjusted for 0 - 50, for example.

Existing octane slider functionality would be overridden/removed.

Repurpose

Custom Features

2020-12-06T04:07:15Z

Joedubs: /* Proposed custom features */

= Custom Features =

== Existing custom features ==
=== Eurodyne ===
==== Octane Slider ====
Eurodyne software includes custom features for an adjustable Octane slider. The way the adjustable octane slider works is this:

#There's a function call within the existing ignition angle calculation.
#There's custom code that checks to see if the slider is enabled
#No:
##use the "low octane" timing map (which has been repurposed from one of the existing timing maps)
#Yes:
##get the value from the slider (memory), and the minimum and maximum adjustable octane settings (cal)
##calculate an interpolation factor
##perform a map lookup against the low timing map
##perform a map lookup against the high timing map
##apply the interpolation factor to the basic timing outputs from the two timing maps
##Store the output as the basic ignition angle setting

== Proposed custom features ==
=== Performance flex fuel ===
The factory FlexFuel in the Simos18 has the capability of adjusting mass fuel flow (mff) for varying levels of alternative fuel both via a sensor and sensorless (using trims, etc). However, it doesn't have the ability to adjust timing.

Performance FlexFuel (@ZuMble) is the idea that in addition to handling the additional fuel required to reach stoich, the ECU can adjust timing to a point, as well. Ethanol increases knock resistance.

A proposal:

Repurpose the Eurodyne [Octane_Slider] so that instead of looking up the adjustable slider value and the min and max octane values - it looks up the %alternative fuel value (measured), and calculates an interpolation value against that.

Existing settings for min and max octane for adjustable features can stay the same. The calibration can be adjusted for 0 - 50, for example.

Existing octane slider functionality would be overridden/removed.

Repurpose

Custom Features

2020-12-06T04:07:02Z

Joedubs: /* Performance flex fuel */

= Custom Features =

== Existing custom features ==
=== Eurodyne ===
==== Octane Slider ====
Eurodyne software includes custom features for an adjustable Octane slider. The way the adjustable octane slider works is this:

#There's a function call within the existing ignition angle calculation.
#There's custom code that checks to see if the slider is enabled
#No:
##use the "low octane" timing map (which has been repurposed from one of the existing timing maps)
#Yes:
##get the value from the slider (memory), and the minimum and maximum adjustable octane settings (cal)
##calculate an interpolation factor
##perform a map lookup against the low timing map
##perform a map lookup against the high timing map
##apply the interpolation factor to the basic timing outputs from the two timing maps
##Store the output as the basic ignition angle setting

== Proposed custom features ==
=== Performance flex fuel ===
The factory FlexFuel in the Simos18 has the capability of adjusting mass fuel flow (mff) for varying levels of alternative fuel both via a sensor and sensorless (using trims, etc). However, it doesn't have the ability to adjust timing.

Performance FlexFuel (@ZuMble) is the idea that in addition to handling the additional fuel required to reach stoich, the ECU can adjust timing to a point, as well. Ethanol increases knock resistance.

A proposal:

Repurpose the Eurodyne [[Octane_Slider]] so that instead of looking up the adjustable slider value and the min and max octane values - it looks up the %alternative fuel value (measured), and calculates an interpolation value against that.

Existing settings for min and max octane for adjustable features can stay the same. The calibration can be adjusted for 0 - 50, for example.

Existing octane slider functionality would be overridden/removed.

Repurpose

Custom Features

2020-12-06T04:06:33Z

Joedubs: /* Octane Slider */

= Custom Features =

== Existing custom features ==
=== Eurodyne ===
==== Octane Slider ====
Eurodyne software includes custom features for an adjustable Octane slider. The way the adjustable octane slider works is this:

#There's a function call within the existing ignition angle calculation.
#There's custom code that checks to see if the slider is enabled
#No:
##use the "low octane" timing map (which has been repurposed from one of the existing timing maps)
#Yes:
##get the value from the slider (memory), and the minimum and maximum adjustable octane settings (cal)
##calculate an interpolation factor
##perform a map lookup against the low timing map
##perform a map lookup against the high timing map
##apply the interpolation factor to the basic timing outputs from the two timing maps
##Store the output as the basic ignition angle setting

== Proposed custom features ==
=== Performance flex fuel ===
The factory FlexFuel in the Simos18 has the capability of adjusting mass fuel flow (mff) for varying levels of alternative fuel both via a sensor and sensorless (using trims, etc). However, it doesn't have the ability to adjust timing.

Performance FlexFuel (@ZuMble) is the idea that in addition to handling the additional fuel required to reach stoich, the ECU can adjust timing to a point, as well. Ethanol increases knock resistance.

A proposal:

Repurpose the Eurodyne octane slider so that instead of looking up the adjustable slider value and the min and max octane values - it looks up the %alternative fuel value (measured), and calculates an interpolation value against that.

Existing settings for min and max octane for adjustable features can stay the same. The calibration can be adjusted for 0 - 50, for example.

Existing octane slider functionality would be overridden/removed.

Repurpose

Custom Features

2020-12-06T04:05:31Z

Joedubs: Created page with "= Custom Features = == Existing custom features == === Eurodyne === ==== Octane Slider ==== Eurodyne software includes custom features for an adjustable Octane slider. The w..."

= Custom Features =

== Existing custom features ==
=== Eurodyne ===
==== Octane Slider ====
Eurodyne software includes custom features for an adjustable Octane slider. The way the adjustable octane slider works is this:

#There's a function call within the existing ignition angle calculation.
#There's custom code that checks to see if the slider is enabled
##If no, use the "low octane" timing map (which has been repurposed from one of the existing timing maps)
##If yes, get the value from the slider, and the minimum and maximum adjustable octane settings from the cal
##calculate an interpolation factor
##perform a map lookup against the low timing map
##perform a map lookup against the high timing map
##apply the interpolation factor to the basic timing outputs from the two timing maps
##Store the output as the basic ignition angle setting

== Proposed custom features ==
=== Performance flex fuel ===
The factory FlexFuel in the Simos18 has the capability of adjusting mass fuel flow (mff) for varying levels of alternative fuel both via a sensor and sensorless (using trims, etc). However, it doesn't have the ability to adjust timing.

Performance FlexFuel (@ZuMble) is the idea that in addition to handling the additional fuel required to reach stoich, the ECU can adjust timing to a point, as well. Ethanol increases knock resistance.

A proposal:

Repurpose the Eurodyne octane slider so that instead of looking up the adjustable slider value and the min and max octane values - it looks up the %alternative fuel value (measured), and calculates an interpolation value against that.

Existing settings for min and max octane for adjustable features can stay the same. The calibration can be adjusted for 0 - 50, for example.

Existing octane slider functionality would be overridden/removed.

Repurpose

Reverse Engineering Information

2020-12-04T02:06:41Z

Joedubs: /* Quick Reference */

= Purpose of this section =

=Helpful links=
https://www.infineon.com/dgdl/tc_v131_instructionset_v138.pdf?fileId=db3a304412b407950112b409b6dd0352

https://www.infineon.com/dgdl/Infineon-SAK-TC1796-256F150E%20BE-DS-v01_00-EN.pdf?fileId=5546d46249a28d750149a34e1f28045d

https://www.infineon.com/dgdl/TriCore_EABI_v2_3.pdf?fileId=db3a304412b407950112b40f8d7a142b

=Quick Reference=
==Memory address lookup==
Registers a0, a1, a8, and a9 are used as offsets when the code needs to reference different memory locations.
There's a table in the ECU that sets up those offsets at boot:

<pre>
0000:808835CC movh.a a0, #0xD002
0000:808835D0 lea a0, [a0]-0x8000
0000:808835D4 movh.a a1, #0xA081
0000:808835D8 lea a1, [a1]-0x8000
0000:808835DC movh.a a8, #0x8005
0000:808835E0 lea a8, [a8]-0x7800
0000:808835E4 movh.a a9, #0xD001
0000:808835E8 lea a9, [a9]-0x4000
</pre>

What that means, is that at any point in the code, these registers always have the following values:
<pre>
a0: 0xD0018000
a1: 0xA0808000
a8: 0x80048800
a9: 0xD000C000
</pre>

A quick example of how this is implemented in code:
<pre>
8019044a c9 00 de c9 ld.h d0,[a0]-0x60e2
</pre>

This takes the value of a0 (0xD0018000), subtracts 0x60e2 (=0xD0011F1E), and pulls the value of that memory address into d0. In the case of one common software version, that's:

<pre>
/begin MEASUREMENT tia_cha_up
"Air Temperature upstream the Charger"
SWORD
_CNV_A_R_CHRG_LINEA_171_CM
1
100.
-48.
335.994140625
DISPLAY_IDENTIFIER TIA_CHA_UP
ECU_ADDRESS 0xd0011f1e
FORMAT "%7.3"
/begin IF_DATA ETK
KP_BLOB
0xd0011f1e
INTERN
2
RASTER 30
/end IF_DATA
/end MEASUREMENT
</pre>

== Table address lookup ==
Table lookup in the calibration isn't as straightforward.
Occasionally you'll see reference in code to something like "0x8083DF8C". 0x8------- is the same as 0xA-------. So "0x8083DF8C" in the ASM is actually reference to 0xA083DF8C

Reverse Engineering Information

2020-11-23T17:04:35Z

Joedubs: /* Helpful links */

= Purpose of this section =

=Helpful links=
https://www.infineon.com/dgdl/tc_v131_instructionset_v138.pdf?fileId=db3a304412b407950112b409b6dd0352

https://www.infineon.com/dgdl/Infineon-SAK-TC1796-256F150E%20BE-DS-v01_00-EN.pdf?fileId=5546d46249a28d750149a34e1f28045d

https://www.infineon.com/dgdl/TriCore_EABI_v2_3.pdf?fileId=db3a304412b407950112b40f8d7a142b

=Quick Reference=
==Memory address lookup==
Registers a0, a1, a8, and a9 are used as offsets when the code needs to reference different memory locations.
There's a table in the ECU that sets up those offsets at boot:

<pre>
0000:808835CC movh.a a0, #0xD002
0000:808835D0 lea a0, [a0]-0x8000
0000:808835D4 movh.a a1, #0xA081
0000:808835D8 lea a1, [a1]-0x8000
0000:808835DC movh.a a8, #0x8005
0000:808835E0 lea a8, [a8]-0x7800
0000:808835E4 movh.a a9, #0xD001
0000:808835E8 lea a9, [a9]-0x4000
</pre>

What that means, is that at any point in the code, these registers always have the following values:
<pre>
a0: 0xD0018000
a1: 0xA0808000
a8: 0x80048800
a9: 0xD000C000
</pre>

A quick example of how this is implemented in code:
<pre>
8019044a c9 00 de c9 ld.h d0,[a0]-0x60e2
</pre>

This takes the value of a0 (0xD0018000), subtracts 0x60e2 (=0xD0011F1E), and pulls the value of that memory address into d0. In the case of one common software version, that's:

<pre>
/begin MEASUREMENT tia_cha_up
"Air Temperature upstream the Charger"
SWORD
_CNV_A_R_CHRG_LINEA_171_CM
1
100.
-48.
335.994140625
DISPLAY_IDENTIFIER TIA_CHA_UP
ECU_ADDRESS 0xd0011f1e
FORMAT "%7.3"
/begin IF_DATA ETK
KP_BLOB
0xd0011f1e
INTERN
2
RASTER 30
/end IF_DATA
/end MEASUREMENT
</pre>

Reverse Engineering Information

2020-11-23T17:03:12Z

Joedubs: /* Helpful links */

= Purpose of this section =

=Helpful links=
https://www.infineon.com/dgdl/Infineon-SAK-TC1796-256F150E%20BE-DS-v01_00-EN.pdf?fileId=5546d46249a28d750149a34e1f28045d

https://www.infineon.com/dgdl/TriCore_EABI_v2_3.pdf?fileId=db3a304412b407950112b40f8d7a142b

=Quick Reference=
==Memory address lookup==
Registers a0, a1, a8, and a9 are used as offsets when the code needs to reference different memory locations.
There's a table in the ECU that sets up those offsets at boot:

<pre>
0000:808835CC movh.a a0, #0xD002
0000:808835D0 lea a0, [a0]-0x8000
0000:808835D4 movh.a a1, #0xA081
0000:808835D8 lea a1, [a1]-0x8000
0000:808835DC movh.a a8, #0x8005
0000:808835E0 lea a8, [a8]-0x7800
0000:808835E4 movh.a a9, #0xD001
0000:808835E8 lea a9, [a9]-0x4000
</pre>

What that means, is that at any point in the code, these registers always have the following values:
<pre>
a0: 0xD0018000
a1: 0xA0808000
a8: 0x80048800
a9: 0xD000C000
</pre>

A quick example of how this is implemented in code:
<pre>
8019044a c9 00 de c9 ld.h d0,[a0]-0x60e2
</pre>

This takes the value of a0 (0xD0018000), subtracts 0x60e2 (=0xD0011F1E), and pulls the value of that memory address into d0. In the case of one common software version, that's:

<pre>
/begin MEASUREMENT tia_cha_up
"Air Temperature upstream the Charger"
SWORD
_CNV_A_R_CHRG_LINEA_171_CM
1
100.
-48.
335.994140625
DISPLAY_IDENTIFIER TIA_CHA_UP
ECU_ADDRESS 0xd0011f1e
FORMAT "%7.3"
/begin IF_DATA ETK
KP_BLOB
0xd0011f1e
INTERN
2
RASTER 30
/end IF_DATA
/end MEASUREMENT
</pre>

Reverse Engineering Information

2020-11-23T17:03:05Z

Joedubs:

= Purpose of this section =

=Helpful links=
https://www.infineon.com/dgdl/Infineon-SAK-TC1796-256F150E%20BE-DS-v01_00-EN.pdf?fileId=5546d46249a28d750149a34e1f28045d
https://www.infineon.com/dgdl/TriCore_EABI_v2_3.pdf?fileId=db3a304412b407950112b40f8d7a142b

=Quick Reference=
==Memory address lookup==
Registers a0, a1, a8, and a9 are used as offsets when the code needs to reference different memory locations.
There's a table in the ECU that sets up those offsets at boot:

<pre>
0000:808835CC movh.a a0, #0xD002
0000:808835D0 lea a0, [a0]-0x8000
0000:808835D4 movh.a a1, #0xA081
0000:808835D8 lea a1, [a1]-0x8000
0000:808835DC movh.a a8, #0x8005
0000:808835E0 lea a8, [a8]-0x7800
0000:808835E4 movh.a a9, #0xD001
0000:808835E8 lea a9, [a9]-0x4000
</pre>

What that means, is that at any point in the code, these registers always have the following values:
<pre>
a0: 0xD0018000
a1: 0xA0808000
a8: 0x80048800
a9: 0xD000C000
</pre>

A quick example of how this is implemented in code:
<pre>
8019044a c9 00 de c9 ld.h d0,[a0]-0x60e2
</pre>

This takes the value of a0 (0xD0018000), subtracts 0x60e2 (=0xD0011F1E), and pulls the value of that memory address into d0. In the case of one common software version, that's:

<pre>
/begin MEASUREMENT tia_cha_up
"Air Temperature upstream the Charger"
SWORD
_CNV_A_R_CHRG_LINEA_171_CM
1
100.
-48.
335.994140625
DISPLAY_IDENTIFIER TIA_CHA_UP
ECU_ADDRESS 0xd0011f1e
FORMAT "%7.3"
/begin IF_DATA ETK
KP_BLOB
0xd0011f1e
INTERN
2
RASTER 30
/end IF_DATA
/end MEASUREMENT
</pre>

Main Page

2020-11-15T02:33:43Z

Joedubs: /* Select a topic from the left nav bar or the links below */

__NOTOC__
The SimosWiki

This site is dedicated to tuning the Simos(18) family of ECUs commonly found in the MQB platform of VW/Audi cars.

Most of the information here revolves around the use of Eurodyne Maestro. Eurodyne does change some maps and axis names, but the vast majority of ecu strategies are kept consistent with the way Continental designed it. An example of where there's a change in the software is the Boss file wastegate duty tables. The factory uses a complex scheme to calculate the exhaust flow vs Boost, while Eurodyne changes this to use a simple RPM vs. Boost level. Examples of the two different tables are on the [[Eurodyne_Tables|Eurodyne Maestro Tables]] page.

THIS WIKI IS A WORK IN PROGRESS. We went live with it on 9/21/2020, and we're working on getting info in place.

=== Select a topic from the left nav bar or the links below ===
[[High_Level_Overview|High level overview]] of ECU operation

[[Boost_Management|Boost Management]]

[[Fuel_Management|Fueling Management]]

[[Reverse_Engineering_Information|Reverse Engineering]]

=== Editing Software ===
Eurodyne Maestro (and HPTuners as of late 2020) are the only software suites that allow for end user modifications to the calibration tables

[[Eurodyne_Tables|Eurodyne Maestro Tables]] is an overview of the tables available in Eurodyne Maestro

[[HP_Tuners_Tables|HPTuners Tables]] is an overview of HPTuners software

=== Helpful Links ===
Note: External links will attempt to open in a new tab 
[https://cobbtuning.atlassian.net/wiki/spaces/PRS/pages/143753246/Volkswagen+MQB+Tuning+Guide Cobb Tuning Volkswagen MQB Tuning Guide] 
[https://ecutek.atlassian.net/wiki/spaces/SUPPORT/pages/21430325/VW+EA888+Engine+Tuning Ecutek EA888 Tuning Guide] 
[https://www.youtube.com/watch?v=5wQ9lQq2vDQ Maestro MK7 GTI MQB, Basic overview (YouTube video)] 
[https://www.youtube.com/watch?v=0Yglshxokv4 Understanding AFR and Lambda] 
[http://www.nefariousmotorsports.com/forum/ Nefmoto] (Not a whole lot that's simos specific) 
[https://s4wiki.com/wiki/Tuning S4 Tuning Wiki] (Not Simos - but still can be helpful) 
[https://cobbtuning.atlassian.net/wiki/spaces/PRS/pages/619872308/Volkswagen+MQB+6+Speed+DSG+Tuning+Guide Cobb Tuning 6-Speed DSG Tuning Guide] 
[https://cobbtuning.atlassian.net/wiki/spaces/PRS/pages/1052606501/Volkswagen+MQB+7+Speed+DSG+Tuning+Guide Cobb Tuning 7-Speed DSG Tuning Guide] 

=== Just saying ===
As with anything, you make modifications at your own risk. Nobody else is responsible for anything that happens while you're tuning your car.

If the information here has been helpful, consider donating. Domain names and web hosting aren't free.
*Paypal: webmaster@simoswiki.com
*Bitcoin: 34JVVe9pE7gZJ5Pu1B3rhWCPiV5SWavQL2

SIMOS is a registered trademark of CONTINENTAL AUTOMOTIVE GMBH. This site has no affiliation.

Reverse Engineering Information

2020-11-15T02:26:55Z

Joedubs: Created page with "= Purpose of this section = =Quick Reference= ==Memory address lookup== Registers a0, a1, a8, and a9 are used as offsets when the code needs to reference different memory..."

= Purpose of this section =

=Quick Reference=
==Memory address lookup==
Registers a0, a1, a8, and a9 are used as offsets when the code needs to reference different memory locations.
There's a table in the ECU that sets up those offsets at boot:

<pre>
0000:808835CC movh.a a0, #0xD002
0000:808835D0 lea a0, [a0]-0x8000
0000:808835D4 movh.a a1, #0xA081
0000:808835D8 lea a1, [a1]-0x8000
0000:808835DC movh.a a8, #0x8005
0000:808835E0 lea a8, [a8]-0x7800
0000:808835E4 movh.a a9, #0xD001
0000:808835E8 lea a9, [a9]-0x4000
</pre>

What that means, is that at any point in the code, these registers always have the following values:
<pre>
a0: 0xD0018000
a1: 0xA0808000
a8: 0x80048800
a9: 0xD000C000
</pre>

A quick example of how this is implemented in code:
<pre>
8019044a c9 00 de c9 ld.h d0,[a0]-0x60e2
</pre>

This takes the value of a0 (0xD0018000), subtracts 0x60e2 (=0xD0011F1E), and pulls the value of that memory address into d0. In the case of one common software version, that's:

<pre>
/begin MEASUREMENT tia_cha_up
"Air Temperature upstream the Charger"
SWORD
_CNV_A_R_CHRG_LINEA_171_CM
1
100.
-48.
335.994140625
DISPLAY_IDENTIFIER TIA_CHA_UP
ECU_ADDRESS 0xd0011f1e
FORMAT "%7.3"
/begin IF_DATA ETK
KP_BLOB
0xd0011f1e
INTERN
2
RASTER 30
/end IF_DATA
/end MEASUREMENT
</pre>

High Level Overview

2020-11-14T11:14:02Z

Joedubs: /* The flash blocks */

The ecu in any car is designed to control how the engine operates. Car manufacturers want their engines to produce power, while still being fuel efficient, reliable, quiet, etc. The way they accomplish this is by defining "maps" which contain modifiable parameters that the ecu will use to make decisions on how the engine should be working. In the case of the Simos18, there are both measured values and modeled values in these maps.

= Primary Control Strategy =
The accelerator pedal tells the ecu how much torque the driver wants the engine to produce.
That driver input is referenced against a table that defines the maximum torque available at any given RPM.
That target torque value is referenced against other maps which define how much airflow, followed fuel and timing, the ecu should target to achieve the driver request torque value.

The way the ECU chooses to achieve different levels of performance are called "combustion modes". Refer to the FR page 1673 for more detailed combustion mode definitions.

= Simos Information =
== Physical info ==

If you open up the 18.1 ecu casing and look at the number written on the processor, this is what you’ll find:
<pre>
SAK-TC1791S-384 F200EP
3MB total flash
200 MHz Processor
</pre>

Physically it contains 3MB of flash in total, spread over two flash units inside the chip (PMU0 – 2MB and PMU1 - 1MB) Other variants of the chip can have different configurations, for example the 18.10 ECU uses a SAK-TC1791S-512 F240EP chip with 4MB (PMU0 – 2MB and PMU1 – 2MB). All of this is in the free Infineon datasheets. So when the tools read out the contents, sometimes they read past the end of the physical chip! In which case anything after the physical end is just lots of zeroes. The 18.1 only has 3MB physically there, if you get a read bigger than 3MB then is all going to be zeroes and you can ignore it anyway.

== The flash blocks ==

There are six blocks:

*PMU0 (2MB)
**1. SBOOT – supplier boot (0x0000 0000 -> 0x0001 BFFF) [112K]
**2. CBOOT – customer boot (0x0001 C000 - > 0x0003 FFFF) [144K]
**3. ASW1 – Application SW part #1 (0x0004 0000 -> 0x0013 FFFF) [1024K]
**4. ASW2 – Application SW part #2 (0x0014 0000 -> 0x001F FFFF) [768K]
*PMU1 (1MB)
**5. CAL – Calibration (0x0020 0000 -> 0x0027 FFFF) [512K]
**6. ASW3 – Application SW part #3 (0x0028 0000 -> 0x002F FFFF) [512K]

Their logical locations in software:
*SBOOT: 0x80000000-0x8001C000
*CBOOT: 0x8001C000-0x80040000
*ASW1: 0x80040000-0x80140000
*ASW2: 0x80140000-0x80880000
*ASW3: 0x80880000-0x808FFC00
*CAL: 0xA0800000

=== Each block's purpose ===
==== SBOOT ====
SBOOT is not a field replaceable unit, so can’t be flashed over with OBD and you can ignore it for all intents and purposes since you can’t really modify it. The other five can be replaced via OBD and are subject to modifying.

==== CBOOT ====
CBOOT does all the flashing. Basically when you want to reflash via OBD, the ECU reboots into CBOOT and runs all the re-flashing procedures etc out of CBOOT. Once complete, it reboots again into ASW. ASW, the application software, is what controls the combustion process in your petrol engine. CBOOT has nothing to do with ASW. You can’t flash from ASW, you have to go into CBOOT for that. Both CBOOT and ASW have their own UDS comm stack, so when CBOOT is active it uses its own comm stack for CAN messages and similarly when ASW is active its using its own separate comm stack as well

==== ASW ====
ASW is the "Application Software" and contains all of the engine management software itself. This is the software that reads sensor data, and makes decisions.

==== CAL ====
This is the calibration data. The "maps" and "tables" that affect the way the car runs.

== Calibration changes ==
It's important to understand that while making changes to the ECU, there's literally hundreds of different tables that may be referenced at any given time or situation. The process of identifying what tables should be used to achieve a given result includes reverse engineering the process that the ECU uses to make certain decisions. One example of this fact is that while anybody familiar with tuning this ECU knows (by know) about the Max clutch torque tables, they probably don't realize that there's more than than one (15?). These tables are (likely) used in different situations/combustions modes. Some tools will link all of them together as a single abstract table so that they all get updated simultaneously, since that's probably the goal of the tuner anyway.

=== Definitions files ===
Definitions files are essentially a "map" to where the maps are located within the calibration data. They give software the ability to display maps in a human readable way. They're proprietary (in the case of factory definitions files), or they're built by hand using the factory definitions as a model.

== Flashing the ECU ==
Technically, you could retune the ECU by just changing the maps that are contained in the calibration block - but each data block in the ECU must be validated before the ECU will use it. The calibration block must be checksummed by the ECU to make sure it hasn't been modified.

The first flashing procedure includes a process which overrides the restrictions that exist in the factory ASW and effectively unlocks the ECU. This allows the tuner to modify the calibration block and flash it to the ECU without triggering the ASW to reject anything. This process is proprietary. Tools like Flashtec, Alientech, bFlash etc have their own way of accomplishing this. Once the ECU is unlocked, any table located in the calibration block can be modified and the entire calibration block reflashed to the ECU as a single action. If you've ever been through the process of flashing calibration changes - they go much faster than the initial flashing process (as they're only changing 1/5th of the overall data).

=== Unlocking the ECU ===
This is the factory OEM flash routine (aka FRF)

The numbers with the $xy suffix are UDS Service Routines, occasionally referred to in hex notation (0x31, 0x37, 0x2C, etc)

picture_1.pdf
123 kB PDF123 kB — Click to view

*$31 eraseMemory
**What is says. Deletes the entire CAL area so the whole block is grey to represent this.
*$34 requestDownload
**Ask to initiate a data transfer
*$36 requestDownload
**Actually move the bytes from the flash tool to the ECU
*$37 requestTransferExit
**Terminate the transfer after all bytes have been copied over. If you look the picture now, you’ll see that the blue data transferred doesn’t quite fill up the flash block. There is still a little bit of grey space remaining. That’s intentional, the flash block really is bigger than the blue CAL data. That little bit of spare space is used in the next steps.
*$31 checkMemory
**“Performs checks to write security keys for reprogrammed components. Security keys in flash memory to secure the reprogramming session if checksum and coherence are fitting. They are tested at start-up of the ECU. If one of the Security Keys is not valid, the applicative software is inhibited and there is no system operation”. So that’s the OKAY bytes written in green. NB – it’s a routine in the ECU that writes these OKAY bytes onto the flash after all checks are successful (checkMemory). Once the block has got the OKAY bytes, the block is allowed to be used. The OKAY bytes are written into the flash just after the blue data. If you look at a full 4MB file, you can see the OKAY bytes yourself just after the end of the CAL data. If there’s something invalid about the CAL data, then the check won’t write the OKAY bytes and the block is invalid…

And this is the initial exploit (this is just one step of several in what the tools do. There are some subsequent steps as well. This just gets some non-OEM code onto the ECU. In subsequent steps that non-OEM code will do further stuff)
The normal sequence is Erase, Write, Check.

picture_2.pdf

Because the Erase wipes both the Data AND the Okay bytes, once you’ve erased and sent the new data across you have to run the check to rewrite the Okay bytes and make the entire thing valid again. But now if you look very carefully, when the tool sends some patched ASW immediately again, it DOESN’T erase first. And because it doesn’t erase first, the Okay bytes are still there…
But there are some restrictions if you are going to write WITHOUT erasing. I found this in the Infineon documentation:
“The erased state of a flash cell is ZERO. After programming a ONE to a cell, only an erase can bring it back to ZERO. Writing a second time to the same cell with a ZERO does not change the ONE. But a ZERO can always be programmed to a ONE”

That means that you can only put additional stuff in a blank area, you can’t change existing areas. I think like this:
Flash after "Erase, Write, Check"
Write this to Flash again without
"Erase"
Flash ends up being a combination of the
two writes
t h i s i s t h e o r i g i n a l
s o u r c e c o d e 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
+
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 a p a t c h 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
=
t h i s i s t h e o r i g i n a l
s o u r c e c o d e 0 0 0 0 0
0 0 0 0 0 a p a t c h 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Okay, the next thing is CBOOT. The CBOOT handles the flashing but there are actually two CBOOT used in the process (CBOOT_temp and CBOOT_actual)

image.png
image.png

Whilst you can directly update CAL, ASWx and CBOOT_temp via OBD flash routines, you can’t reach CBOOT_actual. You can only reach it indirectly. This is a safety thing. The flash routines are executing out of CBOOT_actual. It doesn’t matter how many times you mess up the blocks on the left, you just simply reboot, start execution out of CBOOT_actual and try again until you get it correct. But if you messed up CBOOT actual, then you’ve got nothing that works to reboot into. It’s bricked.
Thus the indirect way to update CBOOT is to OBD write to CBOOT_temp. Then CBOOT_temp gets checked over very carefully to ensure it is totally intact, no corruption, checksums okay and crypto signature all valid etc. And only then does an internal routine move CBOOT_temp to CBOOT_actual
You can read about this in detail in the FR – it’s explained in Section 21.2 ECRP-ECU Customer reprogramming (Appl. Inc.)

image.png
image.png

So now building up the story, step by step. The first step talked about writing without erasing. Second was the concept of CBOOT_temp and CBOOT_actual. Thirdly is below.

image.png
image.png

You can directly reach ASW1 via OBD. You can inject some extra code into ASW1 by write without erase. Limitation is you can only add, not delete or modify… Then when the ECU reboots into ASW1, the extra code in ASW1 does a low-level flash write to the flash memory location of CBOOT_actual (0x8000xxxx). It’s also subject to the same limitations because it’s not doing a delete, it’s writing on top of what’s already present. Basically it’s trying to change just a few bytes in CBOOT_actual.
No point in changing them in CBOOT_temp – the _temp to _actual checks will catch any suspicious changes before _temp is allowed to be copied over to _actual. You have to change _actual itself.
So eventually after all this you end up with some changes in CBOOT_actual, having gone via ASW1.
What do the few changed bytes in CBOOT_actual do? They switch off crypto signature checking, allowing modified files to be flashed via the OEM process :blush:
Just a few notes at this point in the flashing process
The first initial software blocks sent from tool to ecu are most likely to be stock blocks, just returning the ecu to the stock software. If the tool is going to be trying to crack the ecu and exploit stuff, it doesn’t want to be colliding with weird code that a previous tool / another tool vendor has potentially already left behind… No, you want to start greenfield, with known software and utterly predictable behaviour. Set it back to stock and start from there, the OEM software will always go back on because it’s always signed legitimately and check summed correctly.

When transferring from tool to ecu, the software blocks (CAL, ASWx, CBOOT) are compressed one-at-a-time by a LZSS algo and then the compressed files are encrypted with an AES key. Finally these AES-encrypted, compressed files are sent from the tool to the ECU with the ISO-TP multiblock packet size set to the biggest size possible (4095 bytes at a time). Get it across as fast as possible, small file in the biggest chunks possible (obviously inside the ecu it then decrypts and un-compresses them).

But what I’ve seen when the tools do the WriteWithoutErase exploit, the block is NOT compressed. It’s only AES encrypted. And the ISO-TP packet size is stepped down from 4000 to just a 100-or-so bytes per packet. So you have a big (uncompressed) file being sent a little bit at a time. And to make it worse, it’s like an old fashioned reel of tape! You can’t specify just an address in the middle. It always starts at the beginning and plods along to the very end, even if it was just 100 bytes in the middle you were trying to write. So that’s the file mostly filled with zeroes. It’s gonna start at the beginning, plod along through all the zeroes which won’t change anything, get to a few bytes and write them, then carry on with more zeroes until it reaches the end.
That makes it really slow and I think this slowness is deliberate. I believe that when you are trying to write data to a flash substrate that hasn’t been freshly erased, it can take time for the bytes to ‘soak’ into the flash. It’s not freshly erased and just sitting there waiting. Instead it’s already got some contents and now you’re writing to it again. Maybe it takes longer to sink in and for the binary state to change… So that is your thirty to forty-five minutes waiting around time when the crack first happens.
Those checks I mentioned that set the green OKAY bytes in the pictures I drew. Those checks only happen when you ‘step through the front door’. They don’t happen again. Just a once-off when the file is first pushed onto the ECU through the OBD front door. After it’s written to the flash, no point in checking it again, it already passed once and caused the OKAY bytes to be written. Simply the presence of the OKAY bytes suffices to say it was checked. That’s why if you can somehow change the code and leave the OKAY bytes intact, the code will not be checked again and your changes will go undetected!

Now you’ve reached the point, after a lot of effort, that you can write modified stuff down to the ecu. Great. But what if this is the second or third or nth time you want to flash. Clearly you don’t need to patch the ecu every single time, just the first time. No one want to sit around for 45 minutes unnecessarily. So wouldn’t it be nice to somehow check if the ECU has already been patched and we can just skip straight to sending modified files. Or discover if it was never patched and we have to start from scratch. Maybe a friend brings their ecu along and you don’t know the history. You need a way to talk to the ECU…
So now I must digress back to UDS again.
You’ve see services $2C, $22 and $23 for logging. There’s another service $3E TesterPresent. It is simply a heartbeat sent from any OBD tool to the ECU periodically every few 100ms and reminds the ECU that the tool is still there. Just a little tap on the shoulder. Useful for things like elevated security levels – if the tool had requested an elevated privilege level (Service $27 SeedKey) and the ECU then went into that privilege mode, but then the tool disappeared for some reason (flat battery/disconnected cable) then the ECU would notice the missing heartbeat, tear down the elevated privilege session and go back to a basic diagnostic mode waiting for the next connect.
A regular ISO/SAE UDS hearbeat is really simple. The format is always the same as well:
0x02 0x3E 0x00:
2 – it’s 2 bytes in length. Mandated by the UDS standards. Anything other than 2 in this field returns an error
3E – the first byte, it’s service $3E
00 – the second byte, it’s allowed to be 00 or 80 (acknowledgement required/not required)
So many third party tools re-task the UDS heartbeat message for their own purposes. What they’ve done is to slightly ‘corrupt’ the heartbeat request/reply, to use it beyond the original intention:
0x03 0x3E 0x00 0x01
3 - it’s 3 bytes in length.
3E - the first byte, it’s service $3E
00 - the second byte, it’s allowed to be 00 or 80 (acknowledgement required/not required)
01 – an extra byte, tacked upon the end. This could represent Command #1
So now you send this modified heartbeat. Firstly, the length is different now, 3 bytes instead of 2 bytes. So an unpatched stock ECU would reply with an Error 13 – incorrectMessageLengthOrInvalidFor
mat because the ISO/SAE standard is just 2 bytes always . But a patched ECU (with suitable patching in the UDS stack) would accept this and reply with a positive response instead. And there you have it, the tool can learn whether the ECU is previously patched or stock by simply send a little heartbeat message and seeing if the reply is positive or negative.
In addition, you can use that extra byte at the end to trigger something inside the ECU as well (as long as there is corresponding patching to accept it). In the example above, the extra byte being a value of 0x01 could mean invoke activity #1. A value of 0x02 might mean invoke activity #2. All driven by the tool. The clever bit here is that it’s a combination of external tool and ecu patches. It’s not enough just to have the patches inside the ECU, you also need the external tool to trigger those patches inside the ECU otherwise they just sit there waiting.

Next chapter of the story
So now the ECU is wide open. After several steps (and going around the houses via ASW), finally a couple of bytes (yes, it really is just two) have been changed in CBOOT_actual which bypass the RSA signature checks. The ECU will now accept any modified file (i.e. signature not matching contents) that you throw at it, moreover you can just use the factory flash sequence of UDS commands to send the modified files. You don’t need a fancy tool costing £££ thousands either, anything that can send the UDS commands will do the job.
So the pendulum has swung too far if you are a tool vendor! And now they dial it back a bit and make sure that it’s their tool in control again and you have to use their tool.
So whilst the ECU is wide open with RSA signature checks bypassed, the flash tools send down a CBOOT with a number of changes:
A patched heartbeat
Remember UDS command $31 02 02 checkMemory, described much earlier? The one that does a bunch of checks and write the green OKAY bytes? Well, there’s a patch that does the same thing but it doesn’t do any checks beforehand, it just blindly writes the OKAY bytes
And the RSA signature checking is re-activated (the two bytes are reverted)

The ECU reboots, comes up running this modified CBOOT (and although it’s modified it runs quite happily because no checks are done after the fact. The checks are only done once when it passes through the front door on the way in via OBD).
The active RSA signature checks prevent you from sending down any more modified files. Err - but then how do you send a modified CAL?
Remember again that modified UDS heartbeat $3E? Tacking a byte onto the end? And using that byte to represent some command?
Well, you send over the modified CAL using the same UDS flash sequence commands Erase, then Write, all legitimately ($34, $36 etc). The CAL ends up on the flash inside the ECU and the final step is to get the OKAY bytes. At this point, instead of running the OEM $31 02 02 checkMemory which will fail because the file is modified and not write the OKAY bytes, the tools send a modified heartbeat. A patch inside the ECU recognises the modified heartbeat and blindly writes the OKAY bytes for CAL. Then as far as the ECU is concerned, all is fine, the OKAY bytes are there and everything is perfect.
And the tool vendor is happy because you’ve had to use their tool to do this and their modified heartbeat comms channel and whatever command byte sequence they put in :blush:

== Adding features ==
Since the ASW blocks can be flashed, it is possible to not only recalibrate tables in the calibration but also add or modify functions and features in the ASW. Unencrypted application bins include the machine code that's actually run by the ECU. The scope of what's possible is only limited to the amount of free space available (and whether or not you can decipher the instructions).

=== Logging ===
One example of an added feature is the Eurodyne High Speed Logger (HSL). There's a couple of different ways that the operation of the engine can be logged (usually for tuning/optimization purposes).
#Reading data available on the CANbus
#Reading memory address directly from the ECU
##Direct readByAddress queries
##Defining a dynamic identifier

==== CAN ====
The CANbus is essentially an open bus that can be sniffed. However, not every data point is available on the CANbus (since the ECU doesn't need to broadcast everything). RPM might be there (since the ECU communicates with the cluster), but the ecu won't broadcast knock statistics over the CAN network.

==== Reading memory by address ====
Tools that have the capability of connecting to the ECU can also request the values that the ECU has stored in various memory addresses. These values are stored in a non-human readable way with scaling factors that might only make sense to the ECU itself. The memory locations and their scaling factors are available in A2L/Definitions files, so assuming you have access to one of those for the ECU in question, you can find the location and it's scaling factor and you can query the ECU for it. The downside to this is that it has the potential to slow down dramatically as the number of logged parameters increases. If you have the capability of requesting 30 memory addresses per second, but you want to request the value of 10 different parameters, you'll only get 3 responses per second for each one. This has the potential to be inaccurate.

==== Dynamic Identifier ====
A dynamic identifier is (essentially) an identifier in the ECU that "maps" to multiple memory addresses. What that means is that you could, in theory, create a single dynamic identifier that maps to 5 different memory addresses. When you make a single request to the ECU for the value of that identifier, the ECU responds with the values in each of the memory addresses at once. This has the potentially to be many times faster than directly reading memory by address, though it's not available in every ECU (and when it is, it requires special [security level] access to be granted by the ECU).

Eurodyne actually installs a full dynamic identifier routine patched into the ECU for use with the high speed logger.

=== Map Switching ===
While this isn't specific to the Simos ECU (or even directly applicable), it outlines a procedure which should, in theory, achieve the same results if copied. Again, write the new feature, find free space (00's) in memory where it can be placed, and then find out what you want to do to trigger it.

https://www.tangentmotorsport.com/?p=47

== ROM Consolidation ==
ROM Consolidation is something that tuners do, though Cobb seems to the be only one that advertises it. In short, this technique is used by tuners to broadly support a common family of ECUs by modifying them all with the same box code/application software. Since (mostly?) all of the Simos 18.1 ECUs use the same hardware code, the only difference from one to another is what software is installed on them. From the factory, there's a portion of the code which (like the checksums in the calibration block) verify the ASW that the ECU has installed. By bypassing this verification it allows the tuner to load the same code (and thus, the same calibration blocks) onto any ECU that shares/controls the same hardware. If they didn't do this, they would need definitions for each different calibration block since tables can be shifted slightly or exist in different places all together.

High Level Overview

2020-10-19T15:45:05Z

Joedubs: /* Unlocking the ECU */

The ecu in any car is designed to control how the engine operates. Car manufacturers want their engines to produce power, while still being fuel efficient, reliable, quiet, etc. The way they accomplish this is by defining "maps" which contain modifiable parameters that the ecu will use to make decisions on how the engine should be working. In the case of the Simos18, there are both measured values and modeled values in these maps.

= Primary Control Strategy =
The accelerator pedal tells the ecu how much torque the driver wants the engine to produce.
That driver input is referenced against a table that defines the maximum torque available at any given RPM.
That target torque value is referenced against other maps which define how much airflow, followed fuel and timing, the ecu should target to achieve the driver request torque value.

The way the ECU chooses to achieve different levels of performance are called "combustion modes". Refer to the FR page 1673 for more detailed combustion mode definitions.

= Simos Information =
== Physical info ==

If you open up the 18.1 ecu casing and look at the number written on the processor, this is what you’ll find:
<pre>
SAK-TC1791S-384 F200EP
3MB total flash
200 MHz Processor
</pre>

Physically it contains 3MB of flash in total, spread over two flash units inside the chip (PMU0 – 2MB and PMU1 - 1MB) Other variants of the chip can have different configurations, for example the 18.10 ECU uses a SAK-TC1791S-512 F240EP chip with 4MB (PMU0 – 2MB and PMU1 – 2MB). All of this is in the free Infineon datasheets. So when the tools read out the contents, sometimes they read past the end of the physical chip! In which case anything after the physical end is just lots of zeroes. The 18.1 only has 3MB physically there, if you get a read bigger than 3MB then is all going to be zeroes and you can ignore it anyway.

== The flash blocks ==

There are six blocks:

*PMU0 (2MB)
**1. SBOOT – supplier boot (0x0000 0000 -> 0x0001 BFFF)
**2. CBOOT – customer boot (0x0001 C000 - > 0x0003 FFFF)
**3. ASW1 – Application SW part #1 (0x0004 0000 -> 0x0013 FFFF)
**4. ASW2 – Application SW part #2 (0x0014 0000 -> 0x001F FFFF)
*PMU1 (1MB)
**5. CAL – Calibration (0x0020 0000 -> 0x0027 FFFF)
**6. ASW3 – Application SW part #3 (0x0028 0000 -> 0x002F FFFF)

=== Each block's purpose ===
==== SBOOT ====
SBOOT is not a field replaceable unit, so can’t be flashed over with OBD and you can ignore it for all intents and purposes since you can’t really modify it. The other five can be replaced via OBD and are subject to modifying.

==== CBOOT ====
CBOOT does all the flashing. Basically when you want to reflash via OBD, the ECU reboots into CBOOT and runs all the re-flashing procedures etc out of CBOOT. Once complete, it reboots again into ASW. ASW, the application software, is what controls the combustion process in your petrol engine. CBOOT has nothing to do with ASW. You can’t flash from ASW, you have to go into CBOOT for that. Both CBOOT and ASW have their own UDS comm stack, so when CBOOT is active it uses its own comm stack for CAN messages and similarly when ASW is active its using its own separate comm stack as well

==== ASW ====
ASW is the "Application Software" and contains all of the engine management software itself. This is the software that reads sensor data, and makes decisions.

==== CAL ====
This is the calibration data. The "maps" and "tables" that affect the way the car runs.

== Calibration changes ==
It's important to understand that while making changes to the ECU, there's literally hundreds of different tables that may be referenced at any given time or situation. The process of identifying what tables should be used to achieve a given result includes reverse engineering the process that the ECU uses to make certain decisions. One example of this fact is that while anybody familiar with tuning this ECU knows (by know) about the Max clutch torque tables, they probably don't realize that there's more than than one (15?). These tables are (likely) used in different situations/combustions modes. Some tools will link all of them together as a single abstract table so that they all get updated simultaneously, since that's probably the goal of the tuner anyway.

=== Definitions files ===
Definitions files are essentially a "map" to where the maps are located within the calibration data. They give software the ability to display maps in a human readable way. They're proprietary (in the case of factory definitions files), or they're built by hand using the factory definitions as a model.

== Flashing the ECU ==
Technically, you could retune the ECU by just changing the maps that are contained in the calibration block - but each data block in the ECU must be validated before the ECU will use it. The calibration block must be checksummed by the ECU to make sure it hasn't been modified.

The first flashing procedure includes a process which overrides the restrictions that exist in the factory ASW and effectively unlocks the ECU. This allows the tuner to modify the calibration block and flash it to the ECU without triggering the ASW to reject anything. This process is proprietary. Tools like Flashtec, Alientech, bFlash etc have their own way of accomplishing this. Once the ECU is unlocked, any table located in the calibration block can be modified and the entire calibration block reflashed to the ECU as a single action. If you've ever been through the process of flashing calibration changes - they go much faster than the initial flashing process (as they're only changing 1/5th of the overall data).

=== Unlocking the ECU ===
This is the factory OEM flash routine (aka FRF)

The numbers with the $xy suffix are UDS Service Routines, occasionally referred to in hex notation (0x31, 0x37, 0x2C, etc)

picture_1.pdf
123 kB PDF123 kB — Click to view

*$31 eraseMemory
**What is says. Deletes the entire CAL area so the whole block is grey to represent this.
*$34 requestDownload
**Ask to initiate a data transfer
*$36 requestDownload
**Actually move the bytes from the flash tool to the ECU
*$37 requestTransferExit
**Terminate the transfer after all bytes have been copied over. If you look the picture now, you’ll see that the blue data transferred doesn’t quite fill up the flash block. There is still a little bit of grey space remaining. That’s intentional, the flash block really is bigger than the blue CAL data. That little bit of spare space is used in the next steps.
*$31 checkMemory
**“Performs checks to write security keys for reprogrammed components. Security keys in flash memory to secure the reprogramming session if checksum and coherence are fitting. They are tested at start-up of the ECU. If one of the Security Keys is not valid, the applicative software is inhibited and there is no system operation”. So that’s the OKAY bytes written in green. NB – it’s a routine in the ECU that writes these OKAY bytes onto the flash after all checks are successful (checkMemory). Once the block has got the OKAY bytes, the block is allowed to be used. The OKAY bytes are written into the flash just after the blue data. If you look at a full 4MB file, you can see the OKAY bytes yourself just after the end of the CAL data. If there’s something invalid about the CAL data, then the check won’t write the OKAY bytes and the block is invalid…

And this is the initial exploit (this is just one step of several in what the tools do. There are some subsequent steps as well. This just gets some non-OEM code onto the ECU. In subsequent steps that non-OEM code will do further stuff)
The normal sequence is Erase, Write, Check.

picture_2.pdf

Because the Erase wipes both the Data AND the Okay bytes, once you’ve erased and sent the new data across you have to run the check to rewrite the Okay bytes and make the entire thing valid again. But now if you look very carefully, when the tool sends some patched ASW immediately again, it DOESN’T erase first. And because it doesn’t erase first, the Okay bytes are still there…
But there are some restrictions if you are going to write WITHOUT erasing. I found this in the Infineon documentation:
“The erased state of a flash cell is ZERO. After programming a ONE to a cell, only an erase can bring it back to ZERO. Writing a second time to the same cell with a ZERO does not change the ONE. But a ZERO can always be programmed to a ONE”

That means that you can only put additional stuff in a blank area, you can’t change existing areas. I think like this:
Flash after "Erase, Write, Check"
Write this to Flash again without
"Erase"
Flash ends up being a combination of the
two writes
t h i s i s t h e o r i g i n a l
s o u r c e c o d e 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
+
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 a p a t c h 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
=
t h i s i s t h e o r i g i n a l
s o u r c e c o d e 0 0 0 0 0
0 0 0 0 0 a p a t c h 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Okay, the next thing is CBOOT. The CBOOT handles the flashing but there are actually two CBOOT used in the process (CBOOT_temp and CBOOT_actual)

image.png
image.png

Whilst you can directly update CAL, ASWx and CBOOT_temp via OBD flash routines, you can’t reach CBOOT_actual. You can only reach it indirectly. This is a safety thing. The flash routines are executing out of CBOOT_actual. It doesn’t matter how many times you mess up the blocks on the left, you just simply reboot, start execution out of CBOOT_actual and try again until you get it correct. But if you messed up CBOOT actual, then you’ve got nothing that works to reboot into. It’s bricked.
Thus the indirect way to update CBOOT is to OBD write to CBOOT_temp. Then CBOOT_temp gets checked over very carefully to ensure it is totally intact, no corruption, checksums okay and crypto signature all valid etc. And only then does an internal routine move CBOOT_temp to CBOOT_actual
You can read about this in detail in the FR – it’s explained in Section 21.2 ECRP-ECU Customer reprogramming (Appl. Inc.)

image.png
image.png

So now building up the story, step by step. The first step talked about writing without erasing. Second was the concept of CBOOT_temp and CBOOT_actual. Thirdly is below.

image.png
image.png

You can directly reach ASW1 via OBD. You can inject some extra code into ASW1 by write without erase. Limitation is you can only add, not delete or modify… Then when the ECU reboots into ASW1, the extra code in ASW1 does a low-level flash write to the flash memory location of CBOOT_actual (0x8000xxxx). It’s also subject to the same limitations because it’s not doing a delete, it’s writing on top of what’s already present. Basically it’s trying to change just a few bytes in CBOOT_actual.
No point in changing them in CBOOT_temp – the _temp to _actual checks will catch any suspicious changes before _temp is allowed to be copied over to _actual. You have to change _actual itself.
So eventually after all this you end up with some changes in CBOOT_actual, having gone via ASW1.
What do the few changed bytes in CBOOT_actual do? They switch off crypto signature checking, allowing modified files to be flashed via the OEM process :blush:
Just a few notes at this point in the flashing process
The first initial software blocks sent from tool to ecu are most likely to be stock blocks, just returning the ecu to the stock software. If the tool is going to be trying to crack the ecu and exploit stuff, it doesn’t want to be colliding with weird code that a previous tool / another tool vendor has potentially already left behind… No, you want to start greenfield, with known software and utterly predictable behaviour. Set it back to stock and start from there, the OEM software will always go back on because it’s always signed legitimately and check summed correctly.

When transferring from tool to ecu, the software blocks (CAL, ASWx, CBOOT) are compressed one-at-a-time by a LZSS algo and then the compressed files are encrypted with an AES key. Finally these AES-encrypted, compressed files are sent from the tool to the ECU with the ISO-TP multiblock packet size set to the biggest size possible (4095 bytes at a time). Get it across as fast as possible, small file in the biggest chunks possible (obviously inside the ecu it then decrypts and un-compresses them).

But what I’ve seen when the tools do the WriteWithoutErase exploit, the block is NOT compressed. It’s only AES encrypted. And the ISO-TP packet size is stepped down from 4000 to just a 100-or-so bytes per packet. So you have a big (uncompressed) file being sent a little bit at a time. And to make it worse, it’s like an old fashioned reel of tape! You can’t specify just an address in the middle. It always starts at the beginning and plods along to the very end, even if it was just 100 bytes in the middle you were trying to write. So that’s the file mostly filled with zeroes. It’s gonna start at the beginning, plod along through all the zeroes which won’t change anything, get to a few bytes and write them, then carry on with more zeroes until it reaches the end.
That makes it really slow and I think this slowness is deliberate. I believe that when you are trying to write data to a flash substrate that hasn’t been freshly erased, it can take time for the bytes to ‘soak’ into the flash. It’s not freshly erased and just sitting there waiting. Instead it’s already got some contents and now you’re writing to it again. Maybe it takes longer to sink in and for the binary state to change… So that is your thirty to forty-five minutes waiting around time when the crack first happens.
Those checks I mentioned that set the green OKAY bytes in the pictures I drew. Those checks only happen when you ‘step through the front door’. They don’t happen again. Just a once-off when the file is first pushed onto the ECU through the OBD front door. After it’s written to the flash, no point in checking it again, it already passed once and caused the OKAY bytes to be written. Simply the presence of the OKAY bytes suffices to say it was checked. That’s why if you can somehow change the code and leave the OKAY bytes intact, the code will not be checked again and your changes will go undetected!

Now you’ve reached the point, after a lot of effort, that you can write modified stuff down to the ecu. Great. But what if this is the second or third or nth time you want to flash. Clearly you don’t need to patch the ecu every single time, just the first time. No one want to sit around for 45 minutes unnecessarily. So wouldn’t it be nice to somehow check if the ECU has already been patched and we can just skip straight to sending modified files. Or discover if it was never patched and we have to start from scratch. Maybe a friend brings their ecu along and you don’t know the history. You need a way to talk to the ECU…
So now I must digress back to UDS again.
You’ve see services $2C, $22 and $23 for logging. There’s another service $3E TesterPresent. It is simply a heartbeat sent from any OBD tool to the ECU periodically every few 100ms and reminds the ECU that the tool is still there. Just a little tap on the shoulder. Useful for things like elevated security levels – if the tool had requested an elevated privilege level (Service $27 SeedKey) and the ECU then went into that privilege mode, but then the tool disappeared for some reason (flat battery/disconnected cable) then the ECU would notice the missing heartbeat, tear down the elevated privilege session and go back to a basic diagnostic mode waiting for the next connect.
A regular ISO/SAE UDS hearbeat is really simple. The format is always the same as well:
0x02 0x3E 0x00:
2 – it’s 2 bytes in length. Mandated by the UDS standards. Anything other than 2 in this field returns an error
3E – the first byte, it’s service $3E
00 – the second byte, it’s allowed to be 00 or 80 (acknowledgement required/not required)
So many third party tools re-task the UDS heartbeat message for their own purposes. What they’ve done is to slightly ‘corrupt’ the heartbeat request/reply, to use it beyond the original intention:
0x03 0x3E 0x00 0x01
3 - it’s 3 bytes in length.
3E - the first byte, it’s service $3E
00 - the second byte, it’s allowed to be 00 or 80 (acknowledgement required/not required)
01 – an extra byte, tacked upon the end. This could represent Command #1
So now you send this modified heartbeat. Firstly, the length is different now, 3 bytes instead of 2 bytes. So an unpatched stock ECU would reply with an Error 13 – incorrectMessageLengthOrInvalidFor
mat because the ISO/SAE standard is just 2 bytes always . But a patched ECU (with suitable patching in the UDS stack) would accept this and reply with a positive response instead. And there you have it, the tool can learn whether the ECU is previously patched or stock by simply send a little heartbeat message and seeing if the reply is positive or negative.
In addition, you can use that extra byte at the end to trigger something inside the ECU as well (as long as there is corresponding patching to accept it). In the example above, the extra byte being a value of 0x01 could mean invoke activity #1. A value of 0x02 might mean invoke activity #2. All driven by the tool. The clever bit here is that it’s a combination of external tool and ecu patches. It’s not enough just to have the patches inside the ECU, you also need the external tool to trigger those patches inside the ECU otherwise they just sit there waiting.

Next chapter of the story
So now the ECU is wide open. After several steps (and going around the houses via ASW), finally a couple of bytes (yes, it really is just two) have been changed in CBOOT_actual which bypass the RSA signature checks. The ECU will now accept any modified file (i.e. signature not matching contents) that you throw at it, moreover you can just use the factory flash sequence of UDS commands to send the modified files. You don’t need a fancy tool costing £££ thousands either, anything that can send the UDS commands will do the job.
So the pendulum has swung too far if you are a tool vendor! And now they dial it back a bit and make sure that it’s their tool in control again and you have to use their tool.
So whilst the ECU is wide open with RSA signature checks bypassed, the flash tools send down a CBOOT with a number of changes:
A patched heartbeat
Remember UDS command $31 02 02 checkMemory, described much earlier? The one that does a bunch of checks and write the green OKAY bytes? Well, there’s a patch that does the same thing but it doesn’t do any checks beforehand, it just blindly writes the OKAY bytes
And the RSA signature checking is re-activated (the two bytes are reverted)

The ECU reboots, comes up running this modified CBOOT (and although it’s modified it runs quite happily because no checks are done after the fact. The checks are only done once when it passes through the front door on the way in via OBD).
The active RSA signature checks prevent you from sending down any more modified files. Err - but then how do you send a modified CAL?
Remember again that modified UDS heartbeat $3E? Tacking a byte onto the end? And using that byte to represent some command?
Well, you send over the modified CAL using the same UDS flash sequence commands Erase, then Write, all legitimately ($34, $36 etc). The CAL ends up on the flash inside the ECU and the final step is to get the OKAY bytes. At this point, instead of running the OEM $31 02 02 checkMemory which will fail because the file is modified and not write the OKAY bytes, the tools send a modified heartbeat. A patch inside the ECU recognises the modified heartbeat and blindly writes the OKAY bytes for CAL. Then as far as the ECU is concerned, all is fine, the OKAY bytes are there and everything is perfect.
And the tool vendor is happy because you’ve had to use their tool to do this and their modified heartbeat comms channel and whatever command byte sequence they put in :blush:

== Adding features ==
Since the ASW blocks can be flashed, it is possible to not only recalibrate tables in the calibration but also add or modify functions and features in the ASW. Unencrypted application bins include the machine code that's actually run by the ECU. The scope of what's possible is only limited to the amount of free space available (and whether or not you can decipher the instructions).

=== Logging ===
One example of an added feature is the Eurodyne High Speed Logger (HSL). There's a couple of different ways that the operation of the engine can be logged (usually for tuning/optimization purposes).
#Reading data available on the CANbus
#Reading memory address directly from the ECU
##Direct readByAddress queries
##Defining a dynamic identifier

==== CAN ====
The CANbus is essentially an open bus that can be sniffed. However, not every data point is available on the CANbus (since the ECU doesn't need to broadcast everything). RPM might be there (since the ECU communicates with the cluster), but the ecu won't broadcast knock statistics over the CAN network.

==== Reading memory by address ====
Tools that have the capability of connecting to the ECU can also request the values that the ECU has stored in various memory addresses. These values are stored in a non-human readable way with scaling factors that might only make sense to the ECU itself. The memory locations and their scaling factors are available in A2L/Definitions files, so assuming you have access to one of those for the ECU in question, you can find the location and it's scaling factor and you can query the ECU for it. The downside to this is that it has the potential to slow down dramatically as the number of logged parameters increases. If you have the capability of requesting 30 memory addresses per second, but you want to request the value of 10 different parameters, you'll only get 3 responses per second for each one. This has the potential to be inaccurate.

==== Dynamic Identifier ====
A dynamic identifier is (essentially) an identifier in the ECU that "maps" to multiple memory addresses. What that means is that you could, in theory, create a single dynamic identifier that maps to 5 different memory addresses. When you make a single request to the ECU for the value of that identifier, the ECU responds with the values in each of the memory addresses at once. This has the potentially to be many times faster than directly reading memory by address, though it's not available in every ECU (and when it is, it requires special [security level] access to be granted by the ECU).

Eurodyne actually installs a full dynamic identifier routine patched into the ECU for use with the high speed logger.

=== Map Switching ===
While this isn't specific to the Simos ECU (or even directly applicable), it outlines a procedure which should, in theory, achieve the same results if copied. Again, write the new feature, find free space (00's) in memory where it can be placed, and then find out what you want to do to trigger it.

https://www.tangentmotorsport.com/?p=47

== ROM Consolidation ==
ROM Consolidation is something that tuners do, though Cobb seems to the be only one that advertises it. In short, this technique is used by tuners to broadly support a common family of ECUs by modifying them all with the same box code/application software. Since (mostly?) all of the Simos 18.1 ECUs use the same hardware code, the only difference from one to another is what software is installed on them. From the factory, there's a portion of the code which (like the checksums in the calibration block) verify the ASW that the ECU has installed. By bypassing this verification it allows the tuner to load the same code (and thus, the same calibration blocks) onto any ECU that shares/controls the same hardware. If they didn't do this, they would need definitions for each different calibration block since tables can be shifted slightly or exist in different places all together.

High Level Overview

2020-10-19T15:44:08Z

Joedubs: /* Primary Control Strategy */

The ecu in any car is designed to control how the engine operates. Car manufacturers want their engines to produce power, while still being fuel efficient, reliable, quiet, etc. The way they accomplish this is by defining "maps" which contain modifiable parameters that the ecu will use to make decisions on how the engine should be working. In the case of the Simos18, there are both measured values and modeled values in these maps.

= Primary Control Strategy =
The accelerator pedal tells the ecu how much torque the driver wants the engine to produce.
That driver input is referenced against a table that defines the maximum torque available at any given RPM.
That target torque value is referenced against other maps which define how much airflow, followed fuel and timing, the ecu should target to achieve the driver request torque value.

The way the ECU chooses to achieve different levels of performance are called "combustion modes". Refer to the FR page 1673 for more detailed combustion mode definitions.

= Simos Information =
== Physical info ==

If you open up the 18.1 ecu casing and look at the number written on the processor, this is what you’ll find:
<pre>
SAK-TC1791S-384 F200EP
3MB total flash
200 MHz Processor
</pre>

Physically it contains 3MB of flash in total, spread over two flash units inside the chip (PMU0 – 2MB and PMU1 - 1MB) Other variants of the chip can have different configurations, for example the 18.10 ECU uses a SAK-TC1791S-512 F240EP chip with 4MB (PMU0 – 2MB and PMU1 – 2MB). All of this is in the free Infineon datasheets. So when the tools read out the contents, sometimes they read past the end of the physical chip! In which case anything after the physical end is just lots of zeroes. The 18.1 only has 3MB physically there, if you get a read bigger than 3MB then is all going to be zeroes and you can ignore it anyway.

== The flash blocks ==

There are six blocks:

*PMU0 (2MB)
**1. SBOOT – supplier boot (0x0000 0000 -> 0x0001 BFFF)
**2. CBOOT – customer boot (0x0001 C000 - > 0x0003 FFFF)
**3. ASW1 – Application SW part #1 (0x0004 0000 -> 0x0013 FFFF)
**4. ASW2 – Application SW part #2 (0x0014 0000 -> 0x001F FFFF)
*PMU1 (1MB)
**5. CAL – Calibration (0x0020 0000 -> 0x0027 FFFF)
**6. ASW3 – Application SW part #3 (0x0028 0000 -> 0x002F FFFF)

=== Each block's purpose ===
==== SBOOT ====
SBOOT is not a field replaceable unit, so can’t be flashed over with OBD and you can ignore it for all intents and purposes since you can’t really modify it. The other five can be replaced via OBD and are subject to modifying.

==== CBOOT ====
CBOOT does all the flashing. Basically when you want to reflash via OBD, the ECU reboots into CBOOT and runs all the re-flashing procedures etc out of CBOOT. Once complete, it reboots again into ASW. ASW, the application software, is what controls the combustion process in your petrol engine. CBOOT has nothing to do with ASW. You can’t flash from ASW, you have to go into CBOOT for that. Both CBOOT and ASW have their own UDS comm stack, so when CBOOT is active it uses its own comm stack for CAN messages and similarly when ASW is active its using its own separate comm stack as well

==== ASW ====
ASW is the "Application Software" and contains all of the engine management software itself. This is the software that reads sensor data, and makes decisions.

==== CAL ====
This is the calibration data. The "maps" and "tables" that affect the way the car runs.

== Calibration changes ==
It's important to understand that while making changes to the ECU, there's literally hundreds of different tables that may be referenced at any given time or situation. The process of identifying what tables should be used to achieve a given result includes reverse engineering the process that the ECU uses to make certain decisions. One example of this fact is that while anybody familiar with tuning this ECU knows (by know) about the Max clutch torque tables, they probably don't realize that there's more than than one (15?). These tables are (likely) used in different situations/combustions modes. Some tools will link all of them together as a single abstract table so that they all get updated simultaneously, since that's probably the goal of the tuner anyway.

=== Definitions files ===
Definitions files are essentially a "map" to where the maps are located within the calibration data. They give software the ability to display maps in a human readable way. They're proprietary (in the case of factory definitions files), or they're built by hand using the factory definitions as a model.

== Flashing the ECU ==
Technically, you could retune the ECU by just changing the maps that are contained in the calibration block - but each data block in the ECU must be validated before the ECU will use it. The calibration block must be checksummed by the ECU to make sure it hasn't been modified.

The first flashing procedure includes a process which overrides the restrictions that exist in the factory ASW and effectively unlocks the ECU. This allows the tuner to modify the calibration block and flash it to the ECU without triggering the ASW to reject anything. This process is proprietary. Tools like Flashtec, Alientech, bFlash etc have their own way of accomplishing this. Once the ECU is unlocked, any table located in the calibration block can be modified and the entire calibration block reflashed to the ECU as a single action. If you've ever been through the process of flashing calibration changes - they go much faster than the initial flashing process (as they're only changing 1/5th of the overall data).

=== Unlocking the ECU ===
This is the factory OEM flash routine (aka FRF)

The numbers with the $xy suffix are UDS Service Routines, occasionally referred to in hex notation (0x31, 0x37, 0x2C, etc)

picture_1.pdf
123 kB PDF123 kB — Click to view

*$31 eraseMemory
**What is says. Deletes the entire CAL area so the whole block is grey to represent this.
*$34 requestDownload
**Ask to initiate a data transfer
*$36 requestDownload
**Actually move the bytes from the flash tool to the ECU
*$37 requestTransferExit
**Terminate the transfer after all bytes have been copied over. If you look the picture now, you’ll see that the blue data transferred doesn’t quite fill up the flash block. There is still a little bit of grey space remaining. That’s intentional, the flash block really is bigger than the blue CAL data. That little bit of spare space is used in the next steps.
*$31 checkMemory
**“Performs checks to write security keys for reprogrammed components. Security keys in flash memory to secure the reprogramming session if checksum and coherence are fitting. They are tested at start-up of the ECU. If one of the Security Keys is not valid, the applicative software is inhibited and there is no system operation”. So that’s the OKAY bytes written in green. NB – it’s a routine in the ECU that writes these OKAY bytes onto the flash after all checks are successful (checkMemory). Once the block has got the OKAY bytes, the block is allowed to be used. The OKAY bytes are written into the flash just after the blue data. If you look at a full 4MB file, you can see the OKAY bytes yourself just after the end of the CAL data. If there’s something invalid about the CAL data, then the check won’t write the OKAY bytes and the block is invalid…

And this is the initial exploit (this is just one step of several in what the tools do. There are some subsequent steps as well. This just gets some non-OEM code onto the ECU. In subsequent steps that non-OEM code will do further stuff)
The normal sequence is Erase, Write, Check.

picture_2.pdf

Because the Erase wipes both the Data AND the Okay bytes, once you’ve erased and sent the new data across you have to run the check to rewrite the Okay bytes and make the entire thing valid again. But now if you look very carefully, when the tool sends some patched ASW immediately again, it DOESN’T erase first. And because it doesn’t erase first, the Okay bytes are still there…
But there are some restrictions if you are going to write WITHOUT erasing. I found this in the Infineon documentation:
“The erased state of a flash cell is ZERO. After programming a ONE to a cell, only an erase can bring it back to ZERO. Writing a second time to the same cell with a ZERO does not change the ONE. But a ZERO can always be programmed to a ONE”

That means that you can only put additional stuff in a blank area, you can’t change existing areas. I think like this:
Flash after "Erase, Write, Check"
Write this to Flash again without
"Erase"
Flash ends up being a combination of the
two writes
t h i s i s t h e o r i g i n a l
s o u r c e c o d e 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
+
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 a p a t c h 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
=
t h i s i s t h e o r i g i n a l
s o u r c e c o d e 0 0 0 0 0
0 0 0 0 0 a p a t c h 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Okay, the next thing is CBOOT. The CBOOT handles the flashing but there are actually two CBOOT used in the process (CBOOT_temp and CBOOT_actual)

image.png
image.png

Whilst you can directly update CAL, ASWx and CBOOT_temp via OBD flash routines, you can’t reach CBOOT_actual. You can only reach it indirectly. This is a safety thing. The flash routines are executing out of CBOOT_actual. It doesn’t matter how many times you mess up the blocks on the left, you just simply reboot, start execution out of CBOOT_actual and try again until you get it correct. But if you messed up CBOOT actual, then you’ve got nothing that works to reboot into. It’s bricked.
Thus the indirect way to update CBOOT is to OBD write to CBOOT_temp. Then CBOOT_temp gets checked over very carefully to ensure it is totally intact, no corruption, checksums okay and crypto signature all valid etc. And only then does an internal routine move CBOOT_temp to CBOOT_actual
You can read about this in detail in the FR – it’s explained in Section 21.2 ECRP-ECU Customer reprogramming (Appl. Inc.)

image.png
image.png

So now building up the story, step by step. The first step talked about writing without erasing. Second was the concept of CBOOT_temp and CBOOT_actual. Thirdly is below.

image.png
image.png

You can directly reach ASW1 via OBD. You can inject some extra code into ASW1 by write without erase. Limitation is you can only add, not delete or modify… Then when the ECU reboots into ASW1, the extra code in ASW1 does a low-level flash write to the flash memory location of CBOOT_actual (0x8000xxxx). It’s also subject to the same limitations because it’s not doing a delete, it’s writing on top of what’s already present. Basically it’s trying to change just a few bytes in CBOOT_actual.
No point in changing them in CBOOT_temp – the _temp to _actual checks will catch any suspicious changes before _temp is allowed to be copied over to _actual. You have to change _actual itself.
So eventually after all this you end up with some changes in CBOOT_actual, having gone via ASW1.
What do the few changed bytes in CBOOT_actual do? They switch off crypto signature checking, allowing modified files to be flashed via the OEM process :blush:
Just a few notes at this point in the flashing process
The first initial software blocks sent from tool to ecu are most likely to be stock blocks, just returning the ecu to the stock software. If the tool is going to be trying to crack the ecu and exploit stuff, it doesn’t want to be colliding with weird code that a previous tool / another tool vendor has potentially already left behind… No, you want to start greenfield, with known software and utterly predictable behaviour. Set it back to stock and start from there, the OEM software will always go back on because it’s always signed legitimately and check summed correctly.

When transferring from tool to ecu, the software blocks (CAL, ASWx, CBOOT) are compressed one-at-a-time by a LZSS algo and then the compressed files are encrypted with an AES key. Finally these AES-encrypted, compressed files are sent from the tool to the ECU with the ISO-TP multiblock packet size set to the biggest size possible (4095 bytes at a time). Get it across as fast as possible, small file in the biggest chunks possible (obviously inside the ecu it then decrypts and un-compresses them).

But what I’ve seen when the tools do the WriteWithoutErase exploit, the block is NOT compressed. It’s only AES encrypted. And the ISO-TP packet size is stepped down from 4000 to just a 100-or-so bytes per packet. So you have a big (uncompressed) file being sent a little bit at a time. And to make it worse, it’s like an old fashioned reel of tape! You can’t specify just an address in the middle. It always starts at the beginning and plods along to the very end, even if it was just 100 bytes in the middle you were trying to write. So that’s the file mostly filled with zeroes. It’s gonna start at the beginning, plod along through all the zeroes which won’t change anything, get to a few bytes and write them, then carry on with more zeroes until it reaches the end.
That makes it really slow and I think this slowness is deliberate. I believe that when you are trying to write data to a flash substrate that hasn’t been freshly erased, it can take time for the bytes to ‘soak’ into the flash. It’s not freshly erased and just sitting there waiting. Instead it’s already got some contents and now you’re writing to it again. Maybe it takes longer to sink in and for the binary state to change… So that is your thirty to forty-five minutes waiting around time when the crack first happens.
Those checks I mentioned that set the green OKAY bytes in the pictures I drew. Those checks only happen when you ‘step through the front door’. They don’t happen again. Just a once-off when the file is first pushed onto the ECU through the OBD front door. After it’s written to the flash, no point in checking it again, it already passed once and caused the OKAY bytes to be written. Simply the presence of the OKAY bytes suffices to say it was checked. That’s why if you can somehow change the code and leave the OKAY bytes intact, the code will not be checked again and your changes will go undetected!

== Adding features ==
Since the ASW blocks can be flashed, it is possible to not only recalibrate tables in the calibration but also add or modify functions and features in the ASW. Unencrypted application bins include the machine code that's actually run by the ECU. The scope of what's possible is only limited to the amount of free space available (and whether or not you can decipher the instructions).

=== Logging ===
One example of an added feature is the Eurodyne High Speed Logger (HSL). There's a couple of different ways that the operation of the engine can be logged (usually for tuning/optimization purposes).
#Reading data available on the CANbus
#Reading memory address directly from the ECU
##Direct readByAddress queries
##Defining a dynamic identifier

==== CAN ====
The CANbus is essentially an open bus that can be sniffed. However, not every data point is available on the CANbus (since the ECU doesn't need to broadcast everything). RPM might be there (since the ECU communicates with the cluster), but the ecu won't broadcast knock statistics over the CAN network.

==== Reading memory by address ====
Tools that have the capability of connecting to the ECU can also request the values that the ECU has stored in various memory addresses. These values are stored in a non-human readable way with scaling factors that might only make sense to the ECU itself. The memory locations and their scaling factors are available in A2L/Definitions files, so assuming you have access to one of those for the ECU in question, you can find the location and it's scaling factor and you can query the ECU for it. The downside to this is that it has the potential to slow down dramatically as the number of logged parameters increases. If you have the capability of requesting 30 memory addresses per second, but you want to request the value of 10 different parameters, you'll only get 3 responses per second for each one. This has the potential to be inaccurate.

==== Dynamic Identifier ====
A dynamic identifier is (essentially) an identifier in the ECU that "maps" to multiple memory addresses. What that means is that you could, in theory, create a single dynamic identifier that maps to 5 different memory addresses. When you make a single request to the ECU for the value of that identifier, the ECU responds with the values in each of the memory addresses at once. This has the potentially to be many times faster than directly reading memory by address, though it's not available in every ECU (and when it is, it requires special [security level] access to be granted by the ECU).

Eurodyne actually installs a full dynamic identifier routine patched into the ECU for use with the high speed logger.

=== Map Switching ===
While this isn't specific to the Simos ECU (or even directly applicable), it outlines a procedure which should, in theory, achieve the same results if copied. Again, write the new feature, find free space (00's) in memory where it can be placed, and then find out what you want to do to trigger it.

https://www.tangentmotorsport.com/?p=47

== ROM Consolidation ==
ROM Consolidation is something that tuners do, though Cobb seems to the be only one that advertises it. In short, this technique is used by tuners to broadly support a common family of ECUs by modifying them all with the same box code/application software. Since (mostly?) all of the Simos 18.1 ECUs use the same hardware code, the only difference from one to another is what software is installed on them. From the factory, there's a portion of the code which (like the checksums in the calibration block) verify the ASW that the ECU has installed. By bypassing this verification it allows the tuner to load the same code (and thus, the same calibration blocks) onto any ECU that shares/controls the same hardware. If they didn't do this, they would need definitions for each different calibration block since tables can be shifted slightly or exist in different places all together.

High Level Overview

2020-10-19T15:41:39Z

Joedubs: /* Calibration changes */

The ecu in any car is designed to control how the engine operates. Car manufacturers want their engines to produce power, while still being fuel efficient, reliable, quiet, etc. The way they accomplish this is by defining "maps" which contain modifiable parameters that the ecu will use to make decisions on how the engine should be working. In the case of the Simos18, there are both measured values and modeled values in these maps.

= Primary Control Strategy =
The accelerator pedal tells the ecu how much torque the driver wants the engine to produce.
That driver input is referenced against a table that defines the maximum torque available at any given RPM.
That target torque value is referenced against other maps which define how much airflow, followed fuel and timing, the ecu should target to achieve the driver request torque value.

= Simos Information =
== Physical info ==

If you open up the 18.1 ecu casing and look at the number written on the processor, this is what you’ll find:
<pre>
SAK-TC1791S-384 F200EP
3MB total flash
200 MHz Processor
</pre>

Physically it contains 3MB of flash in total, spread over two flash units inside the chip (PMU0 – 2MB and PMU1 - 1MB) Other variants of the chip can have different configurations, for example the 18.10 ECU uses a SAK-TC1791S-512 F240EP chip with 4MB (PMU0 – 2MB and PMU1 – 2MB). All of this is in the free Infineon datasheets. So when the tools read out the contents, sometimes they read past the end of the physical chip! In which case anything after the physical end is just lots of zeroes. The 18.1 only has 3MB physically there, if you get a read bigger than 3MB then is all going to be zeroes and you can ignore it anyway.

== The flash blocks ==

There are six blocks:

*PMU0 (2MB)
**1. SBOOT – supplier boot (0x0000 0000 -> 0x0001 BFFF)
**2. CBOOT – customer boot (0x0001 C000 - > 0x0003 FFFF)
**3. ASW1 – Application SW part #1 (0x0004 0000 -> 0x0013 FFFF)
**4. ASW2 – Application SW part #2 (0x0014 0000 -> 0x001F FFFF)
*PMU1 (1MB)
**5. CAL – Calibration (0x0020 0000 -> 0x0027 FFFF)
**6. ASW3 – Application SW part #3 (0x0028 0000 -> 0x002F FFFF)

=== Each block's purpose ===
==== SBOOT ====
SBOOT is not a field replaceable unit, so can’t be flashed over with OBD and you can ignore it for all intents and purposes since you can’t really modify it. The other five can be replaced via OBD and are subject to modifying.

==== CBOOT ====
CBOOT does all the flashing. Basically when you want to reflash via OBD, the ECU reboots into CBOOT and runs all the re-flashing procedures etc out of CBOOT. Once complete, it reboots again into ASW. ASW, the application software, is what controls the combustion process in your petrol engine. CBOOT has nothing to do with ASW. You can’t flash from ASW, you have to go into CBOOT for that. Both CBOOT and ASW have their own UDS comm stack, so when CBOOT is active it uses its own comm stack for CAN messages and similarly when ASW is active its using its own separate comm stack as well

==== ASW ====
ASW is the "Application Software" and contains all of the engine management software itself. This is the software that reads sensor data, and makes decisions.

==== CAL ====
This is the calibration data. The "maps" and "tables" that affect the way the car runs.

== Calibration changes ==
It's important to understand that while making changes to the ECU, there's literally hundreds of different tables that may be referenced at any given time or situation. The process of identifying what tables should be used to achieve a given result includes reverse engineering the process that the ECU uses to make certain decisions. One example of this fact is that while anybody familiar with tuning this ECU knows (by know) about the Max clutch torque tables, they probably don't realize that there's more than than one (15?). These tables are (likely) used in different situations/combustions modes. Some tools will link all of them together as a single abstract table so that they all get updated simultaneously, since that's probably the goal of the tuner anyway.

=== Definitions files ===
Definitions files are essentially a "map" to where the maps are located within the calibration data. They give software the ability to display maps in a human readable way. They're proprietary (in the case of factory definitions files), or they're built by hand using the factory definitions as a model.

== Flashing the ECU ==
Technically, you could retune the ECU by just changing the maps that are contained in the calibration block - but each data block in the ECU must be validated before the ECU will use it. The calibration block must be checksummed by the ECU to make sure it hasn't been modified.

The first flashing procedure includes a process which overrides the restrictions that exist in the factory ASW and effectively unlocks the ECU. This allows the tuner to modify the calibration block and flash it to the ECU without triggering the ASW to reject anything. This process is proprietary. Tools like Flashtec, Alientech, bFlash etc have their own way of accomplishing this. Once the ECU is unlocked, any table located in the calibration block can be modified and the entire calibration block reflashed to the ECU as a single action. If you've ever been through the process of flashing calibration changes - they go much faster than the initial flashing process (as they're only changing 1/5th of the overall data).

=== Unlocking the ECU ===
This is the factory OEM flash routine (aka FRF)

The numbers with the $xy suffix are UDS Service Routines, occasionally referred to in hex notation (0x31, 0x37, 0x2C, etc)

picture_1.pdf
123 kB PDF123 kB — Click to view

*$31 eraseMemory
**What is says. Deletes the entire CAL area so the whole block is grey to represent this.
*$34 requestDownload
**Ask to initiate a data transfer
*$36 requestDownload
**Actually move the bytes from the flash tool to the ECU
*$37 requestTransferExit
**Terminate the transfer after all bytes have been copied over. If you look the picture now, you’ll see that the blue data transferred doesn’t quite fill up the flash block. There is still a little bit of grey space remaining. That’s intentional, the flash block really is bigger than the blue CAL data. That little bit of spare space is used in the next steps.
*$31 checkMemory
**“Performs checks to write security keys for reprogrammed components. Security keys in flash memory to secure the reprogramming session if checksum and coherence are fitting. They are tested at start-up of the ECU. If one of the Security Keys is not valid, the applicative software is inhibited and there is no system operation”. So that’s the OKAY bytes written in green. NB – it’s a routine in the ECU that writes these OKAY bytes onto the flash after all checks are successful (checkMemory). Once the block has got the OKAY bytes, the block is allowed to be used. The OKAY bytes are written into the flash just after the blue data. If you look at a full 4MB file, you can see the OKAY bytes yourself just after the end of the CAL data. If there’s something invalid about the CAL data, then the check won’t write the OKAY bytes and the block is invalid…

And this is the initial exploit (this is just one step of several in what the tools do. There are some subsequent steps as well. This just gets some non-OEM code onto the ECU. In subsequent steps that non-OEM code will do further stuff)
The normal sequence is Erase, Write, Check.

picture_2.pdf

Because the Erase wipes both the Data AND the Okay bytes, once you’ve erased and sent the new data across you have to run the check to rewrite the Okay bytes and make the entire thing valid again. But now if you look very carefully, when the tool sends some patched ASW immediately again, it DOESN’T erase first. And because it doesn’t erase first, the Okay bytes are still there…
But there are some restrictions if you are going to write WITHOUT erasing. I found this in the Infineon documentation:
“The erased state of a flash cell is ZERO. After programming a ONE to a cell, only an erase can bring it back to ZERO. Writing a second time to the same cell with a ZERO does not change the ONE. But a ZERO can always be programmed to a ONE”

That means that you can only put additional stuff in a blank area, you can’t change existing areas. I think like this:
Flash after "Erase, Write, Check"
Write this to Flash again without
"Erase"
Flash ends up being a combination of the
two writes
t h i s i s t h e o r i g i n a l
s o u r c e c o d e 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
+
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 a p a t c h 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
=
t h i s i s t h e o r i g i n a l
s o u r c e c o d e 0 0 0 0 0
0 0 0 0 0 a p a t c h 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Okay, the next thing is CBOOT. The CBOOT handles the flashing but there are actually two CBOOT used in the process (CBOOT_temp and CBOOT_actual)

image.png
image.png

Whilst you can directly update CAL, ASWx and CBOOT_temp via OBD flash routines, you can’t reach CBOOT_actual. You can only reach it indirectly. This is a safety thing. The flash routines are executing out of CBOOT_actual. It doesn’t matter how many times you mess up the blocks on the left, you just simply reboot, start execution out of CBOOT_actual and try again until you get it correct. But if you messed up CBOOT actual, then you’ve got nothing that works to reboot into. It’s bricked.
Thus the indirect way to update CBOOT is to OBD write to CBOOT_temp. Then CBOOT_temp gets checked over very carefully to ensure it is totally intact, no corruption, checksums okay and crypto signature all valid etc. And only then does an internal routine move CBOOT_temp to CBOOT_actual
You can read about this in detail in the FR – it’s explained in Section 21.2 ECRP-ECU Customer reprogramming (Appl. Inc.)

image.png
image.png

So now building up the story, step by step. The first step talked about writing without erasing. Second was the concept of CBOOT_temp and CBOOT_actual. Thirdly is below.

image.png
image.png

You can directly reach ASW1 via OBD. You can inject some extra code into ASW1 by write without erase. Limitation is you can only add, not delete or modify… Then when the ECU reboots into ASW1, the extra code in ASW1 does a low-level flash write to the flash memory location of CBOOT_actual (0x8000xxxx). It’s also subject to the same limitations because it’s not doing a delete, it’s writing on top of what’s already present. Basically it’s trying to change just a few bytes in CBOOT_actual.
No point in changing them in CBOOT_temp – the _temp to _actual checks will catch any suspicious changes before _temp is allowed to be copied over to _actual. You have to change _actual itself.
So eventually after all this you end up with some changes in CBOOT_actual, having gone via ASW1.
What do the few changed bytes in CBOOT_actual do? They switch off crypto signature checking, allowing modified files to be flashed via the OEM process :blush:
Just a few notes at this point in the flashing process
The first initial software blocks sent from tool to ecu are most likely to be stock blocks, just returning the ecu to the stock software. If the tool is going to be trying to crack the ecu and exploit stuff, it doesn’t want to be colliding with weird code that a previous tool / another tool vendor has potentially already left behind… No, you want to start greenfield, with known software and utterly predictable behaviour. Set it back to stock and start from there, the OEM software will always go back on because it’s always signed legitimately and check summed correctly.

When transferring from tool to ecu, the software blocks (CAL, ASWx, CBOOT) are compressed one-at-a-time by a LZSS algo and then the compressed files are encrypted with an AES key. Finally these AES-encrypted, compressed files are sent from the tool to the ECU with the ISO-TP multiblock packet size set to the biggest size possible (4095 bytes at a time). Get it across as fast as possible, small file in the biggest chunks possible (obviously inside the ecu it then decrypts and un-compresses them).

But what I’ve seen when the tools do the WriteWithoutErase exploit, the block is NOT compressed. It’s only AES encrypted. And the ISO-TP packet size is stepped down from 4000 to just a 100-or-so bytes per packet. So you have a big (uncompressed) file being sent a little bit at a time. And to make it worse, it’s like an old fashioned reel of tape! You can’t specify just an address in the middle. It always starts at the beginning and plods along to the very end, even if it was just 100 bytes in the middle you were trying to write. So that’s the file mostly filled with zeroes. It’s gonna start at the beginning, plod along through all the zeroes which won’t change anything, get to a few bytes and write them, then carry on with more zeroes until it reaches the end.
That makes it really slow and I think this slowness is deliberate. I believe that when you are trying to write data to a flash substrate that hasn’t been freshly erased, it can take time for the bytes to ‘soak’ into the flash. It’s not freshly erased and just sitting there waiting. Instead it’s already got some contents and now you’re writing to it again. Maybe it takes longer to sink in and for the binary state to change… So that is your thirty to forty-five minutes waiting around time when the crack first happens.
Those checks I mentioned that set the green OKAY bytes in the pictures I drew. Those checks only happen when you ‘step through the front door’. They don’t happen again. Just a once-off when the file is first pushed onto the ECU through the OBD front door. After it’s written to the flash, no point in checking it again, it already passed once and caused the OKAY bytes to be written. Simply the presence of the OKAY bytes suffices to say it was checked. That’s why if you can somehow change the code and leave the OKAY bytes intact, the code will not be checked again and your changes will go undetected!

== Adding features ==
Since the ASW blocks can be flashed, it is possible to not only recalibrate tables in the calibration but also add or modify functions and features in the ASW. Unencrypted application bins include the machine code that's actually run by the ECU. The scope of what's possible is only limited to the amount of free space available (and whether or not you can decipher the instructions).

=== Logging ===
One example of an added feature is the Eurodyne High Speed Logger (HSL). There's a couple of different ways that the operation of the engine can be logged (usually for tuning/optimization purposes).
#Reading data available on the CANbus
#Reading memory address directly from the ECU
##Direct readByAddress queries
##Defining a dynamic identifier

==== CAN ====
The CANbus is essentially an open bus that can be sniffed. However, not every data point is available on the CANbus (since the ECU doesn't need to broadcast everything). RPM might be there (since the ECU communicates with the cluster), but the ecu won't broadcast knock statistics over the CAN network.

==== Reading memory by address ====
Tools that have the capability of connecting to the ECU can also request the values that the ECU has stored in various memory addresses. These values are stored in a non-human readable way with scaling factors that might only make sense to the ECU itself. The memory locations and their scaling factors are available in A2L/Definitions files, so assuming you have access to one of those for the ECU in question, you can find the location and it's scaling factor and you can query the ECU for it. The downside to this is that it has the potential to slow down dramatically as the number of logged parameters increases. If you have the capability of requesting 30 memory addresses per second, but you want to request the value of 10 different parameters, you'll only get 3 responses per second for each one. This has the potential to be inaccurate.

==== Dynamic Identifier ====
A dynamic identifier is (essentially) an identifier in the ECU that "maps" to multiple memory addresses. What that means is that you could, in theory, create a single dynamic identifier that maps to 5 different memory addresses. When you make a single request to the ECU for the value of that identifier, the ECU responds with the values in each of the memory addresses at once. This has the potentially to be many times faster than directly reading memory by address, though it's not available in every ECU (and when it is, it requires special [security level] access to be granted by the ECU).

Eurodyne actually installs a full dynamic identifier routine patched into the ECU for use with the high speed logger.

=== Map Switching ===
While this isn't specific to the Simos ECU (or even directly applicable), it outlines a procedure which should, in theory, achieve the same results if copied. Again, write the new feature, find free space (00's) in memory where it can be placed, and then find out what you want to do to trigger it.

https://www.tangentmotorsport.com/?p=47

== ROM Consolidation ==
ROM Consolidation is something that tuners do, though Cobb seems to the be only one that advertises it. In short, this technique is used by tuners to broadly support a common family of ECUs by modifying them all with the same box code/application software. Since (mostly?) all of the Simos 18.1 ECUs use the same hardware code, the only difference from one to another is what software is installed on them. From the factory, there's a portion of the code which (like the checksums in the calibration block) verify the ASW that the ECU has installed. By bypassing this verification it allows the tuner to load the same code (and thus, the same calibration blocks) onto any ECU that shares/controls the same hardware. If they didn't do this, they would need definitions for each different calibration block since tables can be shifted slightly or exist in different places all together.