2011 Candian ecu rom
Feb 5, 2012, 08:24 AM
#16
Newbie
Thread Starter
Join Date: Jul 2009
Location: edmonton
Posts: 50
Likes: 0
Received 0 Likes
on
0 Posts
Okay... so... just to make sure all these concepts are clear in your head:
There are two ROM IDs at work here...
1) The stock ROM you read from his vehicle, 56940009.
2) The ROM used for "v27", 56940007.
It's generally considered perfectly fine to replace one ROM image with another, as long as the first 4 digits of the ROM ID match. So this car's ECU will be okay to run 56940007 or 56940009.
However, EcuFlash doesn't like to work with ECU image files it doesn't recognise. So...
In order to flash "v27 Base Map" to the car, then EcuFlash needs to have .xml def(s) for 56940007.
In order to flash back to the original factory tune, EcuFlash needs to have .xml def(s) for 56940009.
So the issue here is not so much a v27 flashing problem. It's that you would have to play "juggle the xml" in order to switch back to the factory tune.
Clear?
Rich
There are two ROM IDs at work here...
1) The stock ROM you read from his vehicle, 56940009.
2) The ROM used for "v27", 56940007.
It's generally considered perfectly fine to replace one ROM image with another, as long as the first 4 digits of the ROM ID match. So this car's ECU will be okay to run 56940007 or 56940009.
However, EcuFlash doesn't like to work with ECU image files it doesn't recognise. So...
In order to flash "v27 Base Map" to the car, then EcuFlash needs to have .xml def(s) for 56940007.
In order to flash back to the original factory tune, EcuFlash needs to have .xml def(s) for 56940009.
So the issue here is not so much a v27 flashing problem. It's that you would have to play "juggle the xml" in order to switch back to the factory tune.
Clear?
Rich
Last edited by rschaffer; Feb 5, 2012 at 08:26 AM.
Feb 5, 2012, 09:38 AM
#17
Rich, would the RAX patch work the same for the rom id ending in 09. They sent me the stock rom and I read it using my 07 xml file. Everything matched up except your patch job (compared to my stock rom image). So if they flash the 2.7 basemap, would your RAX patch still work. That was my concern to them. Guess it just means more work for you if that is the case, stupid Mitsubishi and their multiple rom id's.
Feb 5, 2012, 10:13 AM
#18
Newbie
Thread Starter
Join Date: Jul 2009
Location: edmonton
Posts: 50
Likes: 0
Received 0 Likes
on
0 Posts
Rich, would the RAX patch work the same for the rom id ending in 09. They sent me the stock rom and I read it using my 07 xml file. Everything matched up except your patch job (compared to my stock rom image). So if they flash the 2.7 basemap, would your RAX patch still work. That was my concern to them. Guess it just means more work for you if that is the case, stupid Mitsubishi and their multiple rom id's.
Wonder if openecu needs to be updated on my laptop
Feb 5, 2012, 12:11 PM
#19
Evolved Member
Rich, would the RAX patch work the same for the rom id ending in 09. They sent me the stock rom and I read it using my 07 xml file. Everything matched up except your patch job (compared to my stock rom image). So if they flash the 2.7 basemap, would your RAX patch still work. That was my concern to them. Guess it just means more work for you if that is the case, stupid Mitsubishi and their multiple rom id's.
I don't have a copy of ROM 56940009, so I can't say. I do know I haven't included 56940009 in RAX Patch's list of supported ROMs.
Fortunately, that's not what anyone's trying to do here.
Rich
PS. rschaffer, these XMLs are purely for EcuFlash. Nothing to do with logging. Evoscan has its own config for logging addresses.
Feb 5, 2012, 12:15 PM
#20
Evolved Member
Feb 5, 2012, 03:14 PM
#21
Newbie
Thread Starter
Join Date: Jul 2009
Location: edmonton
Posts: 50
Likes: 0
Received 0 Likes
on
0 Posts
IF someone really wanted to run 56940009 ROM and apply RAX Patch to it, I'd want to take a look at that ROM file. The code may have moved around - if so, it would need its very own RAX Patch XML.
I don't have a copy of ROM 56940009, so I can't say. I do know I haven't included 56940009 in RAX Patch's list of supported ROMs.
Fortunately, that's not what anyone's trying to do here.
Rich
PS. rschaffer, these XMLs are purely for EcuFlash. Nothing to do with logging. Evoscan has its own config for logging addresses.
I don't have a copy of ROM 56940009, so I can't say. I do know I haven't included 56940009 in RAX Patch's list of supported ROMs.
Fortunately, that's not what anyone's trying to do here.
Rich
PS. rschaffer, these XMLs are purely for EcuFlash. Nothing to do with logging. Evoscan has its own config for logging addresses.
What i am getting at is when i saved the xml file that is specific to my friends 2011 ra in openecu and evoscan i could not open his rom which is fine because i am still able to flash from basemap back to stock, correct? But when trying to log his car to see how it took to being flashed by the basemap evoscan would connect to his car but would not log anything properly such as it was saying his car was reving at 35,000 rpm or he was hitting 350 psi.
Feb 5, 2012, 04:41 PM
#22
Evolved Member
Ain't this fun - a learning curve like a cliff. Don't worry, it gets easier! 
Not if you're talking about XMLs from places like goldenevo.com, no.
The data files for EcuFlash are totally unrelated to the data files used by Evoscan.
There are only two things vaguely similar about them... they both happen to use xml format (like everything these days), and they relate to ECUs.
The stuff you download from Golden's website is for EcuFlash - the files named things like 56789012.xml. These tell EcuFlash where tables live in the ROM, how to interpret the values therein, where their scales are, how to interpret those, etc.
In contrast, Evoscan configuration is for "mode23" style logging. That info tells Evoscan what RAM addresses tell you what stuff as the ECU operates. EvoScan is therefore able to ask the ECU things like, "tell me what 2-byte value is at RAM address 80a012", and then present that as "RPM", using a set evaluation formula.
If EcuFlash shows you a pile of pants instead of a fuel map, it's because the fuel map definition file for that ROM ID doesn't actually point to a fuel map.
If Evoscan shows you a pile of pants instead of RPM, it's because the "RPM" RAM address definition doesn't actually point to where in RAM the ECU is putting "RPM" as it runs.
First off, don't mix in Evoscan when talking about ROM XML definition files (well, not unless you're doing map tracing... which is bunk in Evoscan anyway).
If you found an EcuFlash XML definition for your friend's actual ROM ID, then EcuFlash would be able to work with that ROM image file. eg. open it, review it, reflash it to ECU.
Without that ROM ID being defined in some way, EcuFlash wouldn't know what to do with that ROM image file.
To work with the v27 Base Map in EcuFlash, you need its XML definition file. With that in place, you can open/review/reflash.
For Evoscan "mode23" logging to work, it needs the correct RAM addresses for the ROM ID in question. There is a pull-down menu that chooses different data sets. One of them should work for the car in question.
As a side note, "mode23" logging won't work on factory ROMs. It's something that must be enabled in the ROM. Bryan's v27 base maps have "mode23" logging enabled.
Rich
The data files for EcuFlash are totally unrelated to the data files used by Evoscan.
There are only two things vaguely similar about them... they both happen to use xml format (like everything these days), and they relate to ECUs.
The stuff you download from Golden's website is for EcuFlash - the files named things like 56789012.xml. These tell EcuFlash where tables live in the ROM, how to interpret the values therein, where their scales are, how to interpret those, etc.
In contrast, Evoscan configuration is for "mode23" style logging. That info tells Evoscan what RAM addresses tell you what stuff as the ECU operates. EvoScan is therefore able to ask the ECU things like, "tell me what 2-byte value is at RAM address 80a012", and then present that as "RPM", using a set evaluation formula.
If EcuFlash shows you a pile of pants instead of a fuel map, it's because the fuel map definition file for that ROM ID doesn't actually point to a fuel map.
If Evoscan shows you a pile of pants instead of RPM, it's because the "RPM" RAM address definition doesn't actually point to where in RAM the ECU is putting "RPM" as it runs.
If you found an EcuFlash XML definition for your friend's actual ROM ID, then EcuFlash would be able to work with that ROM image file. eg. open it, review it, reflash it to ECU.
Without that ROM ID being defined in some way, EcuFlash wouldn't know what to do with that ROM image file.
To work with the v27 Base Map in EcuFlash, you need its XML definition file. With that in place, you can open/review/reflash.
As a side note, "mode23" logging won't work on factory ROMs. It's something that must be enabled in the ROM. Bryan's v27 base maps have "mode23" logging enabled.
Rich
Feb 5, 2012, 06:46 PM
#23
Newbie
Thread Starter
Join Date: Jul 2009
Location: edmonton
Posts: 50
Likes: 0
Received 0 Likes
on
0 Posts
Ain't this fun - a learning curve like a cliff. Don't worry, it gets easier!
Not if you're talking about XMLs from places like goldenevo.com, no.
The data files for EcuFlash are totally unrelated to the data files used by Evoscan.
There are only two things vaguely similar about them... they both happen to use xml format (like everything these days), and they relate to ECUs.
The stuff you download from Golden's website is for EcuFlash - the files named things like 56789012.xml. These tell EcuFlash where tables live in the ROM, how to interpret the values therein, where their scales are, how to interpret those, etc.
In contrast, Evoscan configuration is for "mode23" style logging. That info tells Evoscan what RAM addresses tell you what stuff as the ECU operates. EvoScan is therefore able to ask the ECU things like, "tell me what 2-byte value is at RAM address 80a012", and then present that as "RPM", using a set evaluation formula.
If EcuFlash shows you a pile of pants instead of a fuel map, it's because the fuel map definition file for that ROM ID doesn't actually point to a fuel map.
If Evoscan shows you a pile of pants instead of RPM, it's because the "RPM" RAM address definition doesn't actually point to where in RAM the ECU is putting "RPM" as it runs.
First off, don't mix in Evoscan when talking about ROM XML definition files (well, not unless you're doing map tracing... which is bunk in Evoscan anyway).
If you found an EcuFlash XML definition for your friend's actual ROM ID, then EcuFlash would be able to work with that ROM image file. eg. open it, review it, reflash it to ECU.
Without that ROM ID being defined in some way, EcuFlash wouldn't know what to do with that ROM image file.
To work with the v27 Base Map in EcuFlash, you need its XML definition file. With that in place, you can open/review/reflash.
For Evoscan "mode23" logging to work, it needs the correct RAM addresses for the ROM ID in question. There is a pull-down menu that chooses different data sets. One of them should work for the car in question.
As a side note, "mode23" logging won't work on factory ROMs. It's something that must be enabled in the ROM. Bryan's v27 base maps have "mode23" logging enabled.
Rich
Not if you're talking about XMLs from places like goldenevo.com, no.
The data files for EcuFlash are totally unrelated to the data files used by Evoscan.
There are only two things vaguely similar about them... they both happen to use xml format (like everything these days), and they relate to ECUs.
The stuff you download from Golden's website is for EcuFlash - the files named things like 56789012.xml. These tell EcuFlash where tables live in the ROM, how to interpret the values therein, where their scales are, how to interpret those, etc.
In contrast, Evoscan configuration is for "mode23" style logging. That info tells Evoscan what RAM addresses tell you what stuff as the ECU operates. EvoScan is therefore able to ask the ECU things like, "tell me what 2-byte value is at RAM address 80a012", and then present that as "RPM", using a set evaluation formula.
If EcuFlash shows you a pile of pants instead of a fuel map, it's because the fuel map definition file for that ROM ID doesn't actually point to a fuel map.
If Evoscan shows you a pile of pants instead of RPM, it's because the "RPM" RAM address definition doesn't actually point to where in RAM the ECU is putting "RPM" as it runs.
First off, don't mix in Evoscan when talking about ROM XML definition files (well, not unless you're doing map tracing... which is bunk in Evoscan anyway).
If you found an EcuFlash XML definition for your friend's actual ROM ID, then EcuFlash would be able to work with that ROM image file. eg. open it, review it, reflash it to ECU.
Without that ROM ID being defined in some way, EcuFlash wouldn't know what to do with that ROM image file.
To work with the v27 Base Map in EcuFlash, you need its XML definition file. With that in place, you can open/review/reflash.
For Evoscan "mode23" logging to work, it needs the correct RAM addresses for the ROM ID in question. There is a pull-down menu that chooses different data sets. One of them should work for the car in question.
As a side note, "mode23" logging won't work on factory ROMs. It's something that must be enabled in the ROM. Bryan's v27 base maps have "mode23" logging enabled.
Rich
Basically i just wanted to be able to do a pull for my buddy and throw it into virtual dyno and then do the same after the basemap just to kinda show him what great work you guys do
but sounds like ill just be able to show him after the basemap is on.
Feb 5, 2012, 07:07 PM
#24
Evolved Member
Note that you can load up any XML file in a web browser to review its contents. To make changes, just use any text editor - Wordpad, whatever.
Rich
Feb 5, 2012, 07:50 PM
#25
Newbie
Thread Starter
Join Date: Jul 2009
Location: edmonton
Posts: 50
Likes: 0
Received 0 Likes
on
0 Posts
Yep. He probably just created a new file for 56940009 that had nowt but a simple "include" statement in it, pointing EcuFlash at the 56940007 def.
Note that you can load up any XML file in a web browser to review its contents. To make changes, just use any text editor - Wordpad, whatever.
As the stock ROM won't speekee mode23, you'll have to mess about with Evoscan's MUT-III (or CAN) mode - that'll get you RPM logged, which is technically all you really need. So it's possible... if you're really keen.
Rich
Note that you can load up any XML file in a web browser to review its contents. To make changes, just use any text editor - Wordpad, whatever.
As the stock ROM won't speekee mode23, you'll have to mess about with Evoscan's MUT-III (or CAN) mode - that'll get you RPM logged, which is technically all you really need. So it's possible... if you're really keen.
Rich
Feb 5, 2012, 08:31 PM
#26
Evolved Member
When it comes down to it, a ROM image file is just a megabyte blob of machine code and data. EcuFlash will try valiantly to stop you blatting over a perfectly functional ECU ROM with any old crap (ie. a funny cat AVI, an ABBA mp3, a ROM image from a totally incompatible ECU).
A def file is just what you use to make sense of the ROM image file in EcuFlash... so you don't need a binary editor to work with it. The def file just tells EcuFlash about the ROM. If EcuFlash thinks it "knows" the ROM, it will be willing have a go at flashing it.
But that will fail if the ROM image file contains fundamentally incompatible data compared to the resident ROM in the ECU. If you're lucky, EcuFlash will spot that first, by performing sanity-checks during the flashing process - looking at raw data, or checksums, or God knows what. If you're unlucky, hello bricked ECU.
From what I've heard, the first four digits of a ROM image file give a good indication of ROM compatibility... ie. you can choose between ROM IDs that have the same first four digits. Follow that rule of thumb and you'll be unlikely come to grief.
And I'm unsubscribing now, as I'm going to end up in a straitjacket if I try to explain ROM defs and binary data in any additional ways:
"Say this rubber duck is the ROM, my bottle of vodka is the xml, and this cat is EcuFlash. Now the rubber duck DRINKS the vodka, the cat eats the duck, while I wear the cat as a hat. Obviously my brain is the ECU - see how it all works?".
Rich
Feb 5, 2012, 08:45 PM
#27
Hey Rich,
Well they sent me their stock ROM and I did a compare to my ROM, these were the differences,
[22:09:57.693] table Mode 23 - IFMode 0x05 -> 0x23 #1 has differences
[22:09:57.693] table Mode 23 - IFMode 0x05 -> 0x23 #2 has differences
[22:09:57.693] table Mode 23 - DoMode 0x4D -> 0x5D has differences
[22:09:57.693] table DTC P1235 Disable 0x0026 -> 0xFFFF Mass airflow sensor plausibility has differences
[22:09:57.693] table DTC P1233 Disable 0x0028 -> 0xFFFF Throttle position sensor (main) plausibility has differences
[22:09:57.693] table DTC P1234 Disable 0x0028 -> 0xFFFF Throttle position sensor (sub) plausibility has differences
[22:09:57.693] table ECU ID has differences
[22:09:57.693] table Variable for Boost Control 0xC7AE -> 0xC752 has differences
[22:09:57.693] table SHLR->SHLR2 0x5101 -> 0x5102 has differences
[22:09:57.693] table Boost Error RAM Address 0xC5c4 -> 0xC5c2 (is 0x8085c2 for logging) has differences
[22:09:57.693] table Boost Error RAM Address in Load Error Table 0xC5c4 -> 0xC5c2 has differences
[22:09:57.693] table OBTR Variable for Boost Control 0xC7AE -> 0xC752 has differences
[22:09:57.693] table OBTR SHLR->SHLR2 0x5201 -> 0x5202 has differences
[22:09:57.693] table OBTR Boost Error RAM Address 0xC5c4 -> 0xC5c2 has differences
[22:09:57.693] table OBTR Boost Error RAM Address in Load Error Table 0xC5c4 -> 0xC5c2 has differences
[22:09:57.693] table Boost Control RPM Per MPH Xover (Gear Based) has differences
[22:09:57.693] table Reactive Solenoid WGDC Correction Interval (Low Gear Range) has differences
[22:09:57.693] table Throttle Conditional Switch has differences
[22:09:57.693] table Stationary Rev Limiter has differences
[22:09:57.693] table Stationary Rev Limit Cross Under Max Speed Enable Delay has differences
[22:09:57.693] table Max Speed for Stationary Rev Limit has differences
[22:09:57.693] table MUT Table has differences
So you can see, even mode23 is different. I would assume that then the xml definition is different. I think you need to make a sticky of your explanations, since I feel more ppl are getting confused between ROMS, Rom id's, xmls for ecuflash, xml for evoscan. We need a 'Flashing your car for Dummies'.
Well they sent me their stock ROM and I did a compare to my ROM, these were the differences,
[22:09:57.693] table Mode 23 - IFMode 0x05 -> 0x23 #1 has differences
[22:09:57.693] table Mode 23 - IFMode 0x05 -> 0x23 #2 has differences
[22:09:57.693] table Mode 23 - DoMode 0x4D -> 0x5D has differences
[22:09:57.693] table DTC P1235 Disable 0x0026 -> 0xFFFF Mass airflow sensor plausibility has differences
[22:09:57.693] table DTC P1233 Disable 0x0028 -> 0xFFFF Throttle position sensor (main) plausibility has differences
[22:09:57.693] table DTC P1234 Disable 0x0028 -> 0xFFFF Throttle position sensor (sub) plausibility has differences
[22:09:57.693] table ECU ID has differences
[22:09:57.693] table Variable for Boost Control 0xC7AE -> 0xC752 has differences
[22:09:57.693] table SHLR->SHLR2 0x5101 -> 0x5102 has differences
[22:09:57.693] table Boost Error RAM Address 0xC5c4 -> 0xC5c2 (is 0x8085c2 for logging) has differences
[22:09:57.693] table Boost Error RAM Address in Load Error Table 0xC5c4 -> 0xC5c2 has differences
[22:09:57.693] table OBTR Variable for Boost Control 0xC7AE -> 0xC752 has differences
[22:09:57.693] table OBTR SHLR->SHLR2 0x5201 -> 0x5202 has differences
[22:09:57.693] table OBTR Boost Error RAM Address 0xC5c4 -> 0xC5c2 has differences
[22:09:57.693] table OBTR Boost Error RAM Address in Load Error Table 0xC5c4 -> 0xC5c2 has differences
[22:09:57.693] table Boost Control RPM Per MPH Xover (Gear Based) has differences
[22:09:57.693] table Reactive Solenoid WGDC Correction Interval (Low Gear Range) has differences
[22:09:57.693] table Throttle Conditional Switch has differences
[22:09:57.693] table Stationary Rev Limiter has differences
[22:09:57.693] table Stationary Rev Limit Cross Under Max Speed Enable Delay has differences
[22:09:57.693] table Max Speed for Stationary Rev Limit has differences
[22:09:57.693] table MUT Table has differences
So you can see, even mode23 is different. I would assume that then the xml definition is different. I think you need to make a sticky of your explanations, since I feel more ppl are getting confused between ROMS, Rom id's, xmls for ecuflash, xml for evoscan. We need a 'Flashing your car for Dummies'.
Last edited by TurtleRA; Feb 5, 2012 at 09:35 PM.
Feb 5, 2012, 09:31 PM
#30
Evolved Member
Okay, wtf is going on here, lol.
This whole gabfest was focused on 56940007 vs. 56940009.
The ROM you've got there is 53600009.
You guys are just f**king with me now. Go on, admit it. This is a stitch-up.
Rich
This whole gabfest was focused on 56940007 vs. 56940009.
The ROM you've got there is 53600009.
You guys are just f**king with me now. Go on, admit it. This is a stitch-up.
Rich