High Level Overview - Revision history

Aaronc7: /* The flash blocks */

2020-11-24T01:26:00Z

The flash blocks

Joedubs: /* The flash blocks */

2020-11-14T11:14:02Z

The flash blocks

Aaronc7: /* The flash blocks */

2020-10-28T23:48:47Z

The flash blocks

Joedubs: /* Unlocking the ECU */

2020-10-19T15:45:05Z

Unlocking the ECU

Joedubs: /* Primary Control Strategy */

2020-10-19T15:44:08Z

Primary Control Strategy

Joedubs: /* Calibration changes */

2020-10-19T15:41:39Z

Calibration changes

Joedubs: /* The flash blocks */

2020-10-19T15:40:48Z

The flash blocks

Joedubs: /* Primary Strategy */

2020-10-19T15:37:59Z

Primary Strategy

Joedubs: /* Unlocking the ECU */

2020-10-19T15:37:26Z

Unlocking the ECU

Joedubs: /* Unlocking the ECU */

2020-10-19T15:36:29Z

Unlocking the ECU

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

@@ Line 32: / Line 32: @@
 **5. CAL – Calibration (0x0020 0000 -> 0x0027 FFFF) [512K]
 **6. ASW3 – Application SW part #3 (0x0028 0000 -> 0x002F FFFF) [512K]
 === Each block's purpose ===

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

@@ Line 142: / Line 142: @@
 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 ==

@@ Line 5: / Line 5: @@
 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 =

@@ Line 46: / Line 46: @@
 == 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 (as outlined by ECUTek).  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.  If we ever have access to open source tools (technically we do already) for modifying our calibrations, that linking is highly unlikely (and will complicate the tuning process greatly).
+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 ==

@@ Line 21: / Line 21: @@
 There are six blocks:
-=== Each blocks purpose ===
+*PMU0 (2MB)
 ==== 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.
@@ Line 38: / Line 39: @@
 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
 == Calibration changes ==

@@ Line 1: / Line 1: @@
 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 Strategy =
+= 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.

@@ Line 58: / Line 58: @@
 kB PDF123 kB — Click to view
-#$31 eraseMemory
+*$31 eraseMemory
-##What is says. Deletes the entire CAL area so the whole block is grey to represent this.
+**What is says. Deletes the entire CAL area so the whole block is grey to represent this.
-#$34 requestDownload
+*$34 requestDownload
-##Ask to initiate a data transfer
+**Ask to initiate a data transfer
-#$36 requestDownload
+*$36 requestDownload
-##Actually move the bytes from the flash tool to the ECU
+**Actually move the bytes from the flash tool to the ECU
-#$37 requestTransferExit
+*$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.
+**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
+*$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…
+**“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…