E5/6 switchable maps and CEL flash on knock - Page 5

Grant620 · 28-11-2009, 09:31 PM

Do you wanna borrow a 5 ECU?

evonut270 · 28-11-2009, 09:37 PM

Quote:

Originally Posted by Grant620

Do you wanna borrow a 5 ECU?

do you have a stock grant? could do with a back up or 2.

HermaN · 09-12-2009, 01:45 PM

any updates on this andy...?

Grant620 · 09-12-2009, 05:39 PM

Quote:

Originally Posted by evonut270

do you have a stock grant? could do with a back up or 2.

No mate, but I will be fitting a 260 ECU very soon, so can lend my 5 ECU.

todd · 28-12-2009, 08:01 PM

Any update on ALS tables

todd · 01-02-2010, 08:57 PM

Quote:

Originally Posted by todd

Any update on ALS tables

ahem

robevans · 28-02-2010, 07:53 PM

any updates andy? =]

**AndyF** · 08-07-2010, 03:53 PM

Well seeing as how I'm now actually working on this again I guess I should update this thread

(Be aware that there are no pics at the moment because I've been writing this at work and don't have access to my home PC with all my programs and screendumps on so I'll update it when I get home)

Basically, last week I had a lovely E5 over for a mapping session and so whilst he was over I took the time to look for an input that could be used for the map switching part of the code as per Ceddys thread here

This was done by changing the custom request value at the bottom of the Evoscan screen to the MUT request that logs the particular memory locations associated with the inputs to the ECU.

To put that in slightly simpler terms...

The input locations for the ECU are memory addresses F0E6, F0E7, F0E8 and F0E9.
If you look in the MUT table in ECUFlash for the E5/6 you will find these memory addresses are already logged as part of the MUT coding (see pic below)

Therefore you see what MUT address they are logged at (addresses B0, B1, B2 and B3 ) and then put that value into the 'custom request' box in Evoscan. (see pic again)

You then need to earth out the unused pins on the ECU and find what pin changes what MUT request. So with my trusty piece of wire put into pin44 I then logged each MUT request identified above and watched to see if any of the response values changed whilst I was putting my wire to earth and lo and behold memory location F0E8 changes from a value of 0x07 to a value of 0x17 when pin 44 is switched to earth.

This therefore means that we now have a direct link between switching pin 44 and what changes in the ECU code when that happens so we can get on with writing the code (which is actually the 'easy' bit

)

Opening up the E6 ECU code with IDAPro using Ceddys guide here you end up with a lovely bit of ECU code for you to spend many minutes/hours/days/months/years to look over

What we need to do to get switchable maps working is to now find the location where the ECU actually decides what map it will use and then we need to change that part of the code. So how do we go about doing that???

The easiest way to find it is to do a bit of detective work by using ECUFlash.
If you open up ECUFlash and then right-click on the Hi Octane Fuel Map tag and go to 'edit map' you will get a box come up that shows you the memory locaiton within the ECU where the fuel map is actually stored - memory address 118A9 (see piccie below)

If you then go back into IDAPro you can find that memory address in the code itself (see below)

Now... what you need to know here is that the address in ECUFlash is the actual starting point of the table but in terms of the ECU code, the map has a few values before it that describe whether its a 2 or 3D map and another few values also tell the ECU what it needs to use to interpret the map.

So we now know the particular coding location where the ECU will look at when it wants to use the fuel map. We can then use the binary search facility in IDAPro to identify where in the code that particular location is used (see pic)

This gives us the following output from the search (see pic)

and we can now see that the location for the 'pointer' is at 2CF0E.

We then repeat the search for address CF0E and find that it is used in this particular part of code here

and looking at it we can also see that it uses the pointer location for the lo octane map as well (CF2E) so I think we're in the correct place

So all we need to do now is modify the code to tell the ECU that if pin 44 is switched then use a different map location and this is how we do it...

If we scroll back up this thread a bit, we can see that when we ground pin 44, memory address F0E8 changes from a 0x07 to a 0x17 in hexadecimal so we can see that when the pin is earthed, bit 4 of memory location F0E8 is changed from a 0 to a 1.

Those of you familiar with hex and binary can skip this next bit in italics

Each byte of code in the ECU is made up of 8 bits and they are in binary format so they can be either a 0 or a 1

Bit no0 corresponds to the number of 1's in the number
Bit no1 corresponds to the number of 2's in the number
Bit no2 corresponds to the number of 4's in the number
Bit no3 corresponds to the number of 8's in the number
Bit no4 corresponds to the number of 16's in the number
Bit no5 corresponds to the number of 32's in the number
Bit no6 corresponds to the number of 64's in the number
Bit no7 corresponds to the number of 128's in the number

For the input codes, each one of these bits corresponds to a particular input pin on the ECU.

So if we look at the 'normal' value of 0x07 then the bits in address F0E8 look as follows (the bit numbers are shown on top)

76543210
00000111

Now for our changed value of 0x17 in hexadecimal we first need to change it into decimal which means it equals 23 and putting 23 into binary gives the following bit values

76543210
00010111

and so we can see the change due to our pin being grounded is that it changes bit 4 from a 0 to a 1

So what we now need to do is tell the ECU that when bit 4 of memory location F0E8 changes from a 0 to a 1 (i.e. we have pressed the switch) we need to use the alternative memory location for the fuel map.

Firstly we set up the alternative map in a spare space in the memory. I use ECUEdit to do this but any hex editor will do.

Looking at the memory I found a nice sized suitable space around 03000 memory location

So I just copied over the original fuel map into that space and then added the definition to ECUFlash so it now looks like

Now for writing the actual code we first need to jump the fuelling code out to a new bit of space where we can add in our extra lines that we need so the first thing we do is remove the first part of the fuelling code and replace it with a jump instruction.

I need to go back to the 'pointers' part of the code and change one of the values to the new location for our switched map (see pic)

evofan · 08-07-2010, 04:44 PM

thats excellent work andy looks like she's almost there :)

bfarnam · 08-07-2010, 06:00 PM

Andy . . . I have been trying to duplicate these changes in the 3000GT world with a little help from Ceddy but I am mostly flying blind . . . the 3000GT ROM has basically been ignored and apart from a little work Ceddy did for the basics most of the stuff has not been mapped out. Have you worked on that ROM at all?

28-11-2009, 09:31 PM	#41
Grant620 Senior Member Join Date: Mar 2009 Posts: 162	Do you wanna borrow a 5 ECU? __________________ Cheers Grant http://www.gb-ent.com

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

09-12-2009, 01:45 PM	#43
HermaN Senior Member Join Date: May 2009 Location: NE Scotland Posts: 573	any updates on this andy...?

28-12-2009, 08:01 PM	#45
todd Senior Member Join Date: Jan 2009 Location: ireland Posts: 378	Any update on ALS tables

28-02-2010, 07:53 PM	#47
robevans Senior Member Join Date: Feb 2009 Posts: 157	any updates andy? =]

08-07-2010, 03:53 PM	#48
AndyF Legend Join Date: Jan 2009 Posts: 981	Well seeing as how I'm now actually working on this again I guess I should update this thread (Be aware that there are no pics at the moment because I've been writing this at work and don't have access to my home PC with all my programs and screendumps on so I'll update it when I get home) Basically, last week I had a lovely E5 over for a mapping session and so whilst he was over I took the time to look for an input that could be used for the map switching part of the code as per Ceddys thread here This was done by changing the custom request value at the bottom of the Evoscan screen to the MUT request that logs the particular memory locations associated with the inputs to the ECU. To put that in slightly simpler terms... The input locations for the ECU are memory addresses F0E6, F0E7, F0E8 and F0E9. If you look in the MUT table in ECUFlash for the E5/6 you will find these memory addresses are already logged as part of the MUT coding (see pic below) Therefore you see what MUT address they are logged at (addresses B0, B1, B2 and B3 ) and then put that value into the 'custom request' box in Evoscan. (see pic again) You then need to earth out the unused pins on the ECU and find what pin changes what MUT request. So with my trusty piece of wire put into pin44 I then logged each MUT request identified above and watched to see if any of the response values changed whilst I was putting my wire to earth and lo and behold memory location F0E8 changes from a value of 0x07 to a value of 0x17 when pin 44 is switched to earth. This therefore means that we now have a direct link between switching pin 44 and what changes in the ECU code when that happens so we can get on with writing the code (which is actually the 'easy' bit ) Opening up the E6 ECU code with IDAPro using Ceddys guide here you end up with a lovely bit of ECU code for you to spend many minutes/hours/days/months/years to look over What we need to do to get switchable maps working is to now find the location where the ECU actually decides what map it will use and then we need to change that part of the code. So how do we go about doing that??? The easiest way to find it is to do a bit of detective work by using ECUFlash. If you open up ECUFlash and then right-click on the Hi Octane Fuel Map tag and go to 'edit map' you will get a box come up that shows you the memory locaiton within the ECU where the fuel map is actually stored - memory address 118A9 (see piccie below) If you then go back into IDAPro you can find that memory address in the code itself (see below) Now... what you need to know here is that the address in ECUFlash is the actual starting point of the table but in terms of the ECU code, the map has a few values before it that describe whether its a 2 or 3D map and another few values also tell the ECU what it needs to use to interpret the map. So we now know the particular coding location where the ECU will look at when it wants to use the fuel map. We can then use the binary search facility in IDAPro to identify where in the code that particular location is used (see pic) This gives us the following output from the search (see pic) and we can now see that the location for the 'pointer' is at 2CF0E. We then repeat the search for address CF0E and find that it is used in this particular part of code here and looking at it we can also see that it uses the pointer location for the lo octane map as well (CF2E) so I think we're in the correct place So all we need to do now is modify the code to tell the ECU that if pin 44 is switched then use a different map location and this is how we do it... If we scroll back up this thread a bit, we can see that when we ground pin 44, memory address F0E8 changes from a 0x07 to a 0x17 in hexadecimal so we can see that when the pin is earthed, bit 4 of memory location F0E8 is changed from a 0 to a 1. Those of you familiar with hex and binary can skip this next bit in italics Each byte of code in the ECU is made up of 8 bits and they are in binary format so they can be either a 0 or a 1 Bit no0 corresponds to the number of 1's in the number Bit no1 corresponds to the number of 2's in the number Bit no2 corresponds to the number of 4's in the number Bit no3 corresponds to the number of 8's in the number Bit no4 corresponds to the number of 16's in the number Bit no5 corresponds to the number of 32's in the number Bit no6 corresponds to the number of 64's in the number Bit no7 corresponds to the number of 128's in the number For the input codes, each one of these bits corresponds to a particular input pin on the ECU. So if we look at the 'normal' value of 0x07 then the bits in address F0E8 look as follows (the bit numbers are shown on top) 76543210 00000111 Now for our changed value of 0x17 in hexadecimal we first need to change it into decimal which means it equals 23 and putting 23 into binary gives the following bit values 76543210 00010111 and so we can see the change due to our pin being grounded is that it changes bit 4 from a 0 to a 1 So what we now need to do is tell the ECU that when bit 4 of memory location F0E8 changes from a 0 to a 1 (i.e. we have pressed the switch) we need to use the alternative memory location for the fuel map. Firstly we set up the alternative map in a spare space in the memory. I use ECUEdit to do this but any hex editor will do. Looking at the memory I found a nice sized suitable space around 03000 memory location So I just copied over the original fuel map into that space and then added the definition to ECUFlash so it now looks like Now for writing the actual code we first need to jump the fuelling code out to a new bit of space where we can add in our extra lines that we need so the first thing we do is remove the first part of the fuelling code and replace it with a jump instruction. I need to go back to the 'pointers' part of the code and change one of the values to the new location for our switched map (see pic)

08-07-2010, 04:44 PM	#49
evofan Member Join Date: Jun 2010 Location: UK Posts: 35	thats excellent work andy looks like she's almost there :)

08-07-2010, 06:00 PM	#50
bfarnam Junior Member Join Date: Jul 2010 Posts: 5	Andy . . . I have been trying to duplicate these changes in the 3000GT world with a little help from Ceddy but I am mostly flying blind . . . the 3000GT ROM has basically been ignored and apart from a little work Ceddy did for the basics most of the stuff has not been mapped out. Have you worked on that ROM at all?