- Location
- Chicago
- First Name
- Mike
- Drive
- 1997 Mitsubishi Legnum VR4 COTY
2022 Subaru Outback Onyx XT
1999 Honda Civic EX
I was able to find a 7202 ECU and it is working perfectly now. Just need to find someone that can assist with remote tuning. 
ECUFlash Definitions
- Thread starter BCX
- Start date
good day all, been reading through this thread and I pray I am not asking a duplicate question. Had a 10hr day, and my brain is fried to a crisp.
96 Legnum VR4, auto, ayc/tcs/asc/abs (LGYF)
Currently running a metal cased ECU that I can't quite get to read anywhere but evoscan... so I am assuming 7201 chip.
I have an MD340289 with a confirmed MH7202F chip.
1. am I able to just plug and play this ECU into my car (assuming it's unmolested by previous owner)
2. is there a way to add the FL 280PS maps, and still maintain the ayc/tcs/asc?
If there are any threads or posts I am missing, please forward me there. I've been searching for about 2hr now.
96 Legnum VR4, auto, ayc/tcs/asc/abs (LGYF)
Currently running a metal cased ECU that I can't quite get to read anywhere but evoscan... so I am assuming 7201 chip.
I have an MD340289 with a confirmed MH7202F chip.
1. am I able to just plug and play this ECU into my car (assuming it's unmolested by previous owner)
2. is there a way to add the FL 280PS maps, and still maintain the ayc/tcs/asc?
If there are any threads or posts I am missing, please forward me there. I've been searching for about 2hr now.
MD340289
7201FS chip
I swapped in the plastic case MD340289/7202F. Engine runs like a champ, but my TCS light is slowly blinking. No other warning lights. I have Tatrix 2.0, and applicable programs to flash. I am assuming the current map is a non-TCL type, going to the dropbox listed elsewhere it looks like there are a couple XMLs I can use... but which one is right?
On edit, looks like I missed the earlier comment, I'm going to give EM2005 a go and see what happens.
Another edit: loading the EM2005 still has flashing TCS lamp. Found a thread on clubvr4 about toggling periphery0 at bit 13 or something… need to research this further.
Last edited:
been doing a bit of reading today, so let me know if I have this right....
1. downloaded all the files on the first page of this thread.
2. modified the vr4_at_base.xml to show xmlid = vr4base, modified file name to vr4base.xml, verified memodel = H8539F to suit my 7202F chip.
3. verified the 20030011.xml showed xmlid = 20030011, verified memodel = H8539F
4. moved read_galant7202.xml (which appears to be a blank file?), and the new saved vr4base.xml and 20030011.xml to OpenECU/ECUflash/rommetadata/mitsubishi/galant folder.
5. downloaded from the ClubVR4 dropbox "default vr-4 7202 Auto TCL - EM2005.hex" and placed in same folder as the .xml files above
Renaming in #2 were to adjust file names to match those listed in the ROM info for the .hex file... specifically "Internal ID: 20030011" and "Inherits: vr4base" I don't know if this was a correct action, but I figured it seemed logical. Additionally, I have all files in the same rommetadata subfolder as I assumed EcuFlash will pull information as needed from that folder. Also, the read_galant7202.xml seems to be a flat blank file when I open in notepad, is this normal?
Car is a 1996 Legnum VR4 5AT, AYC/TCS/ASC/ABS, moving from metal cased MD340289/7201FS to a plastic case MD340289/7202F. My goal is to get things running normal on the new ECU in and work my way through a modest bump in boost to give the car back it's 20ps, and maybe a hair more.
Looking for those with experience, did I screw something up, or am I on the right path? What am I missing, and what is needed to move to flashing the new ECU?
Edit: looks like I got it to work. The flash on the new ECU was too close to what I wanted to change that EcuFlash wouldn’t push the full file to the ROM. The fix was downloading a copy of the non-TCL ROM, flashing that. Then flashing back to the TCL. No warning lights! Lets see if it sticks.
1. downloaded all the files on the first page of this thread.
2. modified the vr4_at_base.xml to show xmlid = vr4base, modified file name to vr4base.xml, verified memodel = H8539F to suit my 7202F chip.
3. verified the 20030011.xml showed xmlid = 20030011, verified memodel = H8539F
4. moved read_galant7202.xml (which appears to be a blank file?), and the new saved vr4base.xml and 20030011.xml to OpenECU/ECUflash/rommetadata/mitsubishi/galant folder.
5. downloaded from the ClubVR4 dropbox "default vr-4 7202 Auto TCL - EM2005.hex" and placed in same folder as the .xml files above
Renaming in #2 were to adjust file names to match those listed in the ROM info for the .hex file... specifically "Internal ID: 20030011" and "Inherits: vr4base" I don't know if this was a correct action, but I figured it seemed logical. Additionally, I have all files in the same rommetadata subfolder as I assumed EcuFlash will pull information as needed from that folder. Also, the read_galant7202.xml seems to be a flat blank file when I open in notepad, is this normal?
Car is a 1996 Legnum VR4 5AT, AYC/TCS/ASC/ABS, moving from metal cased MD340289/7201FS to a plastic case MD340289/7202F. My goal is to get things running normal on the new ECU in and work my way through a modest bump in boost to give the car back it's 20ps, and maybe a hair more.
Looking for those with experience, did I screw something up, or am I on the right path? What am I missing, and what is needed to move to flashing the new ECU?
Edit: looks like I got it to work. The flash on the new ECU was too close to what I wanted to change that EcuFlash wouldn’t push the full file to the ROM. The fix was downloading a copy of the non-TCL ROM, flashing that. Then flashing back to the TCL. No warning lights! Lets see if it sticks.
Last edited:
- Location
- SA
- First Name
- Bill
- Drive
- 2000 Galant Type-V
1997 MK Triton GLS [6G74 conversion]
2019 i30 N-Line
- Thread starter
- #166
I've fixed the Read templates... not sure why they were empty online...
recommend to delete any existing xml files in the ecuflash metadata folder and place all the ones here in there... or point ecuflash to a new folder which contains these defs and read templates.
If you're a MH7202F, make sure all the 2003001x.xml, 2381000x.xml files and vr4base.xml is updated to use H8539F memmodel.
MH7203F - make sure memmodel is set to H8539FA.
vr4_at_base.xml is for the auto trans computer. So if you're interested in reflashing that, need to make sure the memmodel matches the processor in the TCU (Not related to the ECU!)
MD340289 in a MH7201F should be an EM0005, so use an EM2005 rom.
MD340288 in a MH7201F should be an EM0004, so use an EM2004 rom.
There isn't much different between the EM2004/EM2005 roms, except couple of options and table values are different.
Latest rom 'version' is a 20030013, but a 20030011 will work anyways.
I've got a collection of roms if you need a em2005 20030013 rom
recommend to delete any existing xml files in the ecuflash metadata folder and place all the ones here in there... or point ecuflash to a new folder which contains these defs and read templates.
If you're a MH7202F, make sure all the 2003001x.xml, 2381000x.xml files and vr4base.xml is updated to use H8539F memmodel.
MH7203F - make sure memmodel is set to H8539FA.
vr4_at_base.xml is for the auto trans computer. So if you're interested in reflashing that, need to make sure the memmodel matches the processor in the TCU (Not related to the ECU!)
MD340289 in a MH7201F should be an EM0005, so use an EM2005 rom.
MD340288 in a MH7201F should be an EM0004, so use an EM2004 rom.
There isn't much different between the EM2004/EM2005 roms, except couple of options and table values are different.
Latest rom 'version' is a 20030013, but a 20030011 will work anyways.
I've got a collection of roms if you need a em2005 20030013 rom
This is where I am getting a bit glassy eyed. I haven't been able to find a clear answer.
There are various files I need in a folder for EcuFlash to use.
.hex = the ROM EcuFlash loads, and contains calls to the .xml files in the folder... or that's my understanding. In the example below, the ROM pulls data from the #1 23810003.xml, and #2 vr4base.xml. Is this correct?
I would like to play with FL maps, which I am understanding are found within the 20030013.xml, but I would need the .hex that calls back to that under the internal ID, correct? Keeping the AYC/ASC/TCS systems is high on my list. Are these systems controlled by the data from the ROM .hex, the file noted in Internal ID, the file in Inherits, or someplace else?
The current files I am running now is using a TCS enabled Em2005, which calls back to 20030011 and vr4base.
Am I grasping the basic concepts here, or am I way off? Can I simply edit the .hex to call back to 20030013 to get the better performance, but still have my PFL systems functioning?
Thank you for your support on this. I have a feeling there will be more and more "basic" questions tossed around here as more of these cars make it to the US. You all have a 10-15yr head start on us.
First one is the mines rom you were inspecting years ago on clibvr4 (grabbed it for future reference, NOT this early in my game).
The second is the
Default VR-4 7202 Auto TCL EM2005.hex from Foxdie’s folder. This is the only .hex I have been able to find that specifically says it’s for a 7202 Auto with TCL. The base map on my 7202 ECU when it arrived caused the slow blink TCS light. By flashing based on this .xml that light is gone. I don’t know where in the coding to find if a given .xml has, or does not have, TCL enabled, nor how to toggle that myself (or copy/paste some lines over). I cannot get EcuFlash to open any .xml files as the base map, just as references inside the .hex file ROM info. I also don’t know if I can just go in somewhere and edit that line to read 20030013? This is where my understanding stops, and I hit the wall.
I really appreciate your patience. This is my first toe-dip into ECUs, coding, etc, and I know I can make a LOT of catastrophic errors. I’m a quick study, but I learn best by tinkering, and by understanding the basics of something. I’m dumb enough to go for it, yet smart enough to realize I’m walking into a mine field in a pair of snowshoes with my eyes closed and plugging my ears for safety.
On edit:
I loaded a few .hex files into EcuFlash and compared the non-TCL to the TCL. I can see a difference in Bit.13 under ECU Periphery0 (FAA) Bits, specifically the TCL map has this feature toggled off, and non-TCL has toggled on. Is the TCL/non-TCL as simple as toggling Bit.13 on/off to have the ROM be a TCL?
Additionally, to get the 20030013 to read on the TCL friendly .hex from Foxdie's folder, is it as simple as changing the name of the file from 20030013.hex to 20030011.hex to 'trick' EcuFlash?
Last edited:
- Location
- SA
- First Name
- Bill
- Drive
- 2000 Galant Type-V
1997 MK Triton GLS [6G74 conversion]
2019 i30 N-Line
- Thread starter
- #172
Lets take a step back
The hex file (or 'rom') is the contents of the flash memory within the ECU. In the case of our processor (very close relative of the Hitachi H8/539), this 128kb flash memory contains both the program/code that the processor executes, and all the map data/values. There's some other stuff in there that is needed for the processor to function (vector table, etc), but the point I'm trying to make here is... everything is contained in the rom file. Failed reflash equals ECU might not function correctly as the program its trying to execute is garbage.
The XML files (or 'definitions') describe to ECUFlash where in the rom the various maps are, and also applies a scaling which makes the raw binary/hex values into something human readable... like RPM, AFR, voltage, load, timing advance, etc etc etc.
The XML files don't have any map values... They purely just describe to ECUFLash where and how to present the values in the rom. When you edit a value in a map in ECUFlash, you're changing the value in the rom file.
The rom file has a couple of identifiers within it. The XML files also describe to ECUFlash where and what the identifier is. This is what makes ECUFlash pick up the correct XML file. All the VR4 roms have similar tables, so a lot of the table descriptions are in the vr4base file, then anything unique parameter (like the map locations, etc) are in the specific XML files. ECUFlash basically combines the XML in the vr4base file and the rom specific XML. Don't get caught up on the XML inheritance... if the correct XML is picked up when you open your rom (ie 200300xx), and you can see the maps, then your good.
Back to the identifiers:
The EMxxxx number is more like a calibration ID.
A rom can have a few calibrations in it. The rom has provision for up to 8, but usually there's only 1-2 in most Mitsubishi roms.
The 2003xxxx part is a bit harder to explain... but the xxxx part is the software revision. The 2003 part comes because the 8th calibration would be an EM2003 but its not a calibration the VR4 uses. Don't get too caught up on this either, the EMxxxx number is more important imo.
There's 6 calibrations for a VR4:
EM0004/EM0005 (found in a metal cased ecu with a MH7201)
EM2004/EM2005 (which you'll find in an 200300xx rom)
EM2381/EM2428 (which you'll find in a 238100xx rom)
Here's some tables which shows some data I've collected out of ASA
GALANT:
LEGNUM:
Data from ROMs:
I've never really looked into what the actual difference between 238100xx and a 200300xx rom is. The code part of the rom is actually different, which places the map values in a different spot.
The most common roms are EM2004/EM2005 (200300xx)... and most of the development into extra mods I've written is in these roms.
For me, I focused on a 20030013 rom as it's what my 7203 ECU had on it, theoretically its the latest software ver (fixed bugs? service campaigns?) and I had a manual box. I believe Kenneth was the same, hence KSmods is based off a 20030013 rom.
So for you... coming from an EM0005 in a Metal cased MD340289 would be most compatible with a EM2005 rom in theory.
Disregarding the part number of the ECU not matching your metal cased ecu (and the fact the part number was also superseded), an EM2005 (20030013) rom will give you all the table values of a 2000 onwards VR4.
For ASC models: The ECU communicates directly the TCU.
For non-ASC models: ECU communicates to ASC-ECU, and then ASC-ECU then communicates with the TCU.
For manual models: pins aren't populated in the ECU plug.
It's not something that I've actively confirmed or checked - especially as I own a manual VR4... but the difference in ASC vs non-ASC roms presumably is the format and/or whats communicated.
If ASC/TCL is happy after a reflash, then you're all good to start modding the maps - as the rom you're using must satisfy whatever the ASC/TCL needs to function.
Hope this helps.
The hex file (or 'rom') is the contents of the flash memory within the ECU. In the case of our processor (very close relative of the Hitachi H8/539), this 128kb flash memory contains both the program/code that the processor executes, and all the map data/values. There's some other stuff in there that is needed for the processor to function (vector table, etc), but the point I'm trying to make here is... everything is contained in the rom file. Failed reflash equals ECU might not function correctly as the program its trying to execute is garbage.
The XML files (or 'definitions') describe to ECUFlash where in the rom the various maps are, and also applies a scaling which makes the raw binary/hex values into something human readable... like RPM, AFR, voltage, load, timing advance, etc etc etc.
The XML files don't have any map values... They purely just describe to ECUFLash where and how to present the values in the rom. When you edit a value in a map in ECUFlash, you're changing the value in the rom file.
The rom file has a couple of identifiers within it. The XML files also describe to ECUFlash where and what the identifier is. This is what makes ECUFlash pick up the correct XML file. All the VR4 roms have similar tables, so a lot of the table descriptions are in the vr4base file, then anything unique parameter (like the map locations, etc) are in the specific XML files. ECUFlash basically combines the XML in the vr4base file and the rom specific XML. Don't get caught up on the XML inheritance... if the correct XML is picked up when you open your rom (ie 200300xx), and you can see the maps, then your good.
Back to the identifiers:
The EMxxxx number is more like a calibration ID.
A rom can have a few calibrations in it. The rom has provision for up to 8, but usually there's only 1-2 in most Mitsubishi roms.
The 2003xxxx part is a bit harder to explain... but the xxxx part is the software revision. The 2003 part comes because the 8th calibration would be an EM2003 but its not a calibration the VR4 uses. Don't get too caught up on this either, the EMxxxx number is more important imo.
There's 6 calibrations for a VR4:
EM0004/EM0005 (found in a metal cased ecu with a MH7201)
EM2004/EM2005 (which you'll find in an 200300xx rom)
EM2381/EM2428 (which you'll find in a 238100xx rom)
Here's some tables which shows some data I've collected out of ASA
GALANT:
LEGNUM:
Data from ROMs:
I've never really looked into what the actual difference between 238100xx and a 200300xx rom is. The code part of the rom is actually different, which places the map values in a different spot.
The most common roms are EM2004/EM2005 (200300xx)... and most of the development into extra mods I've written is in these roms.
For me, I focused on a 20030013 rom as it's what my 7203 ECU had on it, theoretically its the latest software ver (fixed bugs? service campaigns?) and I had a manual box. I believe Kenneth was the same, hence KSmods is based off a 20030013 rom.
So for you... coming from an EM0005 in a Metal cased MD340289 would be most compatible with a EM2005 rom in theory.
Disregarding the part number of the ECU not matching your metal cased ecu (and the fact the part number was also superseded), an EM2005 (20030013) rom will give you all the table values of a 2000 onwards VR4.
For ASC models: The ECU communicates directly the TCU.
For non-ASC models: ECU communicates to ASC-ECU, and then ASC-ECU then communicates with the TCU.
For manual models: pins aren't populated in the ECU plug.
It's not something that I've actively confirmed or checked - especially as I own a manual VR4... but the difference in ASC vs non-ASC roms presumably is the format and/or whats communicated.
If ASC/TCL is happy after a reflash, then you're all good to start modding the maps - as the rom you're using must satisfy whatever the ASC/TCL needs to function.
Hope this helps.
Last edited:
- Location
- SA
- First Name
- Bill
- Drive
- 2000 Galant Type-V
1997 MK Triton GLS [6G74 conversion]
2019 i30 N-Line
- Thread starter
- #173
combined some of the data in tables with some assumptions.
Galant:
Legnum:
EDIT: looking at my tables below, an EM2005 (20030013) might not really exist in the wild... but the rom has the provision, so should be able to create one.
EDIT 2: I just did a compare between 20030011 vs 20030013... they are pretty identical except for 2 changes. Use the 20030011 rom.
Galant:
Legnum:
EDIT: looking at my tables below, an EM2005 (20030013) might not really exist in the wild... but the rom has the provision, so should be able to create one.
EDIT 2: I just did a compare between 20030011 vs 20030013... they are pretty identical except for 2 changes. Use the 20030011 rom.
Last edited:
^^^ which files do you have that is giving you all the WGDC values, my defs doesn't show those options.
I’m starting to think I need to delete everything and start over. This is what I'm seeing:
yep deleted all and started over worked... now my tables are the same as yours. With that I can now see many more options and more information. Playing with TCL I have the ROM off my 7202 ECU that is clearly a non-TCL and throws the flashing light to prove it. This ROM shows Perphery0 bit.13 as:
The known TCL ROM shows the following for Perphery0 bit.13:
I know you are a MT guy, but in your history with cracking these nuts, is the only item I have to toggle in 0?
Last edited:
- Location
- SA
- First Name
- Bill
- Drive
- 2000 Galant Type-V
1997 MK Triton GLS [6G74 conversion]
2019 i30 N-Line
- Thread starter
- #178
Even in this screenshot, wgdc is there, just as its full name - wastegate base duty cycle
Same for BDEL - desired engine load.
For the TCL stuff, can you screen shot the following two tables for each rom?
I'm trying to ID your existing non-working rom.
'Software Version' and 'Spec Index'
'Spec Index' aligns with the column in the periphery (0-7... remember how I said that a rom can have 8 calibrations?)
Even in this screenshot, wgdc is there, just as its full name - wastegate base duty cycle
Same for BDEL - desired engine load.
For the TCL stuff, can you screen shot the following two tables for each rom?
I'm trying to ID your existing non-working rom.
'Software Version' and 'Spec Index'
'Spec Index' aligns with the column in the periphery (0-7... remember how I said that a rom can have 8 calibrations?)
I remember you saying that but I'm assuming I had the wrong definitions as the previous presentation in EcuFlash was missing a lot of detail and fields that I can see now.
As soon as I got the 7202F ECU plugged into the car I pulled the ROM off and saved it, that is what I have as "oem black MD340289_2":
The TCL ROM I have works in the car, and ye olde' boost gauge shows me it targets/sits at .5bar under WOT. I register a spike to about .6 bar, with momentary peak somewhere under load at .7bar. Below is the info from that ROM:
Both of these ROMs run the car, just that the TCL light is on for the former, and off for the latter. I have been driving off the TCL friendly lower ROM for a week or so. Was trying to compare the two ROMs to see where/what changes between a TCL and non-TCL to see if I can start editing other maps to 'unlock' that feature on them. Example - have a KS-Rom I want to use as a base map, but it's for an non-TCL tune, I'd like to go into the ROM and toggle the TCL.
Again, I appreciate your willingness to help. We are 15yrs behind you in all this understanding and trying to catch up, and your patience is amazing!
