A few small corrections in the 53600010 map...
Dec 21, 2009, 10:31 PM
#1
Evolved Member
Thread Starter
A few small corrections in the 53600010 map...
This post is mostly aimed at those doing the disassembly of the EVO stuff.
Since I spent the last 10 months working full time on the older Ralliart, eclipse, outlander, endeavor, and galant roms I haven't paid much attention to the EVO stuff. They just started selling EVO's in Canada so I had my first few clients show up with '09 Ralliart turbos.
I downloaded the roms in ecuflash. I spent about an hour matching up known routines I had already disassembled in other non-public definitions we have built for internal use.
Working on rom 53600010 I picked and started disassembling what I usually call process_fuel_maps. On this rom it was at 0x1ce74. I am running IDA Pro 5.5.0.925 but I've written some extensive mods to the processor modules to provide automatic RAM/Variable referencing and some automated map detection against my rom database.
As near as I can tell the alt fuel maps like at 0x5517f are not even used. These extra spaceholders were sometimes used to mivec fuel maps in other rom versions.
People seem to have missed is that AFR override table that's at the top of the routine.
The map at: 57A2E overrides the selected target AFR based on the TPS if the one found here is richer. I haven't verified in this version of the rom for the Ralliart but in all other mitsu stuff that's how it works.
At the bottom of the routine you will find the VE table.
I haven't seen the VE defined in any of the maps people have published yet. Although I really haven't spent more than a few hours looking at ecuflash definitions. That software just pisses me off because it's so full of bugs...
-Michael
Since I spent the last 10 months working full time on the older Ralliart, eclipse, outlander, endeavor, and galant roms I haven't paid much attention to the EVO stuff. They just started selling EVO's in Canada so I had my first few clients show up with '09 Ralliart turbos.
I downloaded the roms in ecuflash. I spent about an hour matching up known routines I had already disassembled in other non-public definitions we have built for internal use.
Working on rom 53600010 I picked and started disassembling what I usually call process_fuel_maps. On this rom it was at 0x1ce74. I am running IDA Pro 5.5.0.925 but I've written some extensive mods to the processor modules to provide automatic RAM/Variable referencing and some automated map detection against my rom database.
As near as I can tell the alt fuel maps like at 0x5517f are not even used. These extra spaceholders were sometimes used to mivec fuel maps in other rom versions.
People seem to have missed is that AFR override table that's at the top of the routine.
Code:
sth R0, @((word_804590 - unk_808000), fp) ld24 R0, #axis_tps bl.l axis_lookup_16 ld24 R0, #map_tps_target_override bl.l map_lookup_8 mv R9, R0 || nop bl.s sub_1CF64 || nop ; no exact matches in db sth R0, @((word_804590 - unk_808000), fp) ld24 R0, #axis_rpm_0 bl.l axis_lookup_16 ld24 R0, #axis_load_0 bl.l axis_lookup_16 lduh R0, @((word_8045FE - unk_808000), fp) btst #2, R0
At the bottom of the routine you will find the VE table.
Code:
loc_1CF2C: sth R8, @((ram_target_afr - unk_808000), fp) lduh R0, @((ram_load_value - unk_808000), fp) sth R0, @((ram_gp_sensor_val - unk_808000), fp) ld24 R0, #axis_rpm_1 bl.l axis_lookup_16 ld24 R0, #axis_load_1 bl.l axis_lookup_16 ld24 R0, #map_ve bl.l map_lookup_8 bl.l sub_A10A0 ; no exact matches in db sth R0, @((ram_ve_processed - unk_808000), fp)
-Michael
Dec 22, 2009, 01:58 AM
#3
Evolved Member
Join Date: Mar 2008
Location: Lattitude 48.38°, Longitude 17.58°, Altitude 146m = Slovakia, for common dude
Posts: 730
Likes: 0
Received 2 Likes
on
2 Posts
I believe nobody will get angry if you go and pioneer discovering new maps.
They will eventually get into ecuflash release.
Ecuflash is a freeware. Everybody pays for cable only. XMLs are created as
free time effort of enthusiast that are frequent here. So I really do not see your point.
Last edited by acamus; Dec 22, 2009 at 02:06 AM.
Dec 22, 2009, 06:20 AM
#4
Evolved Member
Thread Starter
ECUFlash is listed as open source. It is not open source. The source is not available. If the source were available I would have fixed some of the bugs a year ago.
I don't use EcuFlash to edit the roms but since the community uses it then changes I make to the definitions for everyone must be done in the software so I'm stuck putting up with the bugs. It's not like I haven't reported them all. The software itself is free the same as LogWorks is free but each package is a support item for a commercial venture. ECUFlash works with a tactrix cable.
For those who have time in hacking the EVO rom, do you agree with the 2 tables I've commented on?
-Michael
I don't use EcuFlash to edit the roms but since the community uses it then changes I make to the definitions for everyone must be done in the software so I'm stuck putting up with the bugs. It's not like I haven't reported them all. The software itself is free the same as LogWorks is free but each package is a support item for a commercial venture. ECUFlash works with a tactrix cable.
For those who have time in hacking the EVO rom, do you agree with the 2 tables I've commented on?
-Michael
Dec 22, 2009, 07:56 AM
#5
Evolving Member
iTrader: (4)
Join Date: Feb 2008
Location: Fort Worth TX
Posts: 408
Likes: 0
Received 0 Likes
on
0 Posts
^^wow just wow...
if you see it that it has too many bugs and it really pisses you off i guess don't use it at all...suggest something new for your clients..
bashing the product, won't get you any answers at all..just my .02
if you see it that it has too many bugs and it really pisses you off i guess don't use it at all...suggest something new for your clients..
bashing the product, won't get you any answers at all..just my .02
Dec 22, 2009, 08:01 AM
#6
Actually I have the same annoying feeling with the "open source" designation of ecuflash as Michael.
The typical definition of "open source" is just that, the source of the code is open to the public so that bugs that people find can be fixed by many contributors. It simply makes for better software. Also the risk of spyware and viruses goes way down because people can inspect the code.
Michael, thanks for looking into the Evo rom. I think that this is one of the reasons that the "closed source" tools are advancing faster than the "open source" tools at this point in time -- not enough people really tearing into the rom.
The typical definition of "open source" is just that, the source of the code is open to the public so that bugs that people find can be fixed by many contributors. It simply makes for better software. Also the risk of spyware and viruses goes way down because people can inspect the code.
Michael, thanks for looking into the Evo rom. I think that this is one of the reasons that the "closed source" tools are advancing faster than the "open source" tools at this point in time -- not enough people really tearing into the rom.
Dec 22, 2009, 08:24 AM
#7
That being said, this pisses me off every time I see it. Really? There's an "open source version" somewhere? I must have missed that.
Colby pulled a bait-and-switch several years ago regarding source availability for EcuFlash. He promised to release it outright. He could have even just released the source to customers who bought a cable (see DSMLink), and I think most would have been satisfied with that. But he created the expectation of source availability (even going so far as to call openecu.org "Open Source Tuning"; notice how that logo changed recently?), and then changed his mind.
Actually, he didn't just change his mind. Try pointing IDA at ecuflash.exe sometime. He didn't just decide not to make source available, he decided to make reverse-engineering it even more difficult. (The irony amuses me.)
I wouldn't have cared if, originally, he'd have said "I'm going to release this as a commercial product, and I'm asking for help in debugging/testing". People can make their own decision at that point. Certainly, being up-front about his commercial intentions didn't hurt Hamish at all; arguably, I'd say it helped.
I see nothing wrong with calling Colby/Tactrix out on any of that, and reminding new users (particularly, the X owners) of that history when they read a few of us being bitter about it. Happy holidays.
Trending Topics
Dec 22, 2009, 10:19 AM
#8
Evolved Member
Thread Starter
-Michael
Dec 22, 2009, 10:34 AM
#9
Evolving Member
Join Date: Apr 2008
Location: New Zealand
Posts: 199
Likes: 0
Received 0 Likes
on
0 Posts
I tend to agree that ECUflash is not open source as you have to pay 3x what the cable is worth.
He all so stops the cables that have not been purchased through him from working, This is not the thing a true open source release would do.
He all so stops the cables that have not been purchased through him from working, This is not the thing a true open source release would do.
Dec 22, 2009, 11:26 AM
#11
Evolved Member
Join Date: Mar 2008
Location: Lattitude 48.38°, Longitude 17.58°, Altitude 146m = Slovakia, for common dude
Posts: 730
Likes: 0
Received 2 Likes
on
2 Posts
In the spirit of helpfulness: Colby apparently shares the source with some people. It's how donour was able to do the original Mac port.
That being said, this pisses me off every time I see it. Really? There's an "open source version" somewhere? I must have missed that.
Colby pulled a bait-and-switch several years ago regarding source availability for EcuFlash. He promised to release it outright. He could have even just released the source to customers who bought a cable (see DSMLink), and I think most would have been satisfied with that. But he created the expectation of source availability (even going so far as to call openecu.org "Open Source Tuning"; notice how that logo changed recently?), and then changed his mind.
Actually, he didn't just change his mind. Try pointing IDA at ecuflash.exe sometime. He didn't just decide not to make source available, he decided to make reverse-engineering it even more difficult. (The irony amuses me.)
I wouldn't have cared if, originally, he'd have said "I'm going to release this as a commercial product, and I'm asking for help in debugging/testing". People can make their own decision at that point. Certainly, being up-front about his commercial intentions didn't hurt Hamish at all; arguably, I'd say it helped.
I see nothing wrong with calling Colby/Tactrix out on any of that, and reminding new users (particularly, the X owners) of that history when they read a few of us being bitter about it. Happy holidays.
That being said, this pisses me off every time I see it. Really? There's an "open source version" somewhere? I must have missed that.
Colby pulled a bait-and-switch several years ago regarding source availability for EcuFlash. He promised to release it outright. He could have even just released the source to customers who bought a cable (see DSMLink), and I think most would have been satisfied with that. But he created the expectation of source availability (even going so far as to call openecu.org "Open Source Tuning"; notice how that logo changed recently?), and then changed his mind.
Actually, he didn't just change his mind. Try pointing IDA at ecuflash.exe sometime. He didn't just decide not to make source available, he decided to make reverse-engineering it even more difficult. (The irony amuses me.)
I wouldn't have cared if, originally, he'd have said "I'm going to release this as a commercial product, and I'm asking for help in debugging/testing". People can make their own decision at that point. Certainly, being up-front about his commercial intentions didn't hurt Hamish at all; arguably, I'd say it helped.
I see nothing wrong with calling Colby/Tactrix out on any of that, and reminding new users (particularly, the X owners) of that history when they read a few of us being bitter about it. Happy holidays.
for the processor. It should not be that hard to do it
Dec 22, 2009, 11:33 AM
#12
Evolved Member
Join Date: Mar 2008
Location: Lattitude 48.38°, Longitude 17.58°, Altitude 146m = Slovakia, for common dude
Posts: 730
Likes: 0
Received 2 Likes
on
2 Posts
Now let us count together:
You need to buy some ECUs,
You need to buy processor development board,
You need to buy ISO/SAE protocol standards,
You need to buy IDA
You need to invest time to study and design that you could have spent for earning some money.
You need to write working software.
Will you do it for the benefit of the community for free?
And I am not defending Colby. He could have released version 0.47(or whatever preliminary version) as an open source. It would have been fair.
Last edited by acamus; Dec 22, 2009 at 11:36 AM.
Dec 22, 2009, 11:59 AM
#13
Evolved Member
Thread Starter
I have never had anything against colby for his cables and such. The problem is promoting something as being open when it's not. That's like Mitsubishi sticking a Turbo badge on the back of a car and saying oh, we just decided to call it a an Endeavor Turbo because it looks fast enough to be a turbo.
OpenECU is a great community, but it's a for profit product. You BUY the tactrix cable and get free software to run it. Same as be BUYING an Innovate wideband and using LogWorks for free.
Everyone should get paid for their work. Sometimes I scratch my head wondering why guys like acamus devote tens of thousands of dollars in R&D time for free. Even the software (IDA Pro) cost me over a g-note. Acamus if you're running a legit copy I can send the database file to you so you could have a look. hackish@gmail.com. Shoot me an email.
-Michael
OpenECU is a great community, but it's a for profit product. You BUY the tactrix cable and get free software to run it. Same as be BUYING an Innovate wideband and using LogWorks for free.
Everyone should get paid for their work. Sometimes I scratch my head wondering why guys like acamus devote tens of thousands of dollars in R&D time for free. Even the software (IDA Pro) cost me over a g-note. Acamus if you're running a legit copy I can send the database file to you so you could have a look. hackish@gmail.com. Shoot me an email.
-Michael
Dec 22, 2009, 02:25 PM
#14
The formal documentation is in section 20.6 of the 7052 manual, and 22.5 of the 7055 manual. It's pretty straightforward to put the ECU into boot mode, upload the new program and execute it, and then switch to program mode. Reprogramming is done in 128-byte blocks, giving you an obvious boundary for checksumming. The host-side software would be trivial; the SH code for interacting with the SCI interface is probably what will give me the most trouble, plus there's some caveats depending on whether you're dealing with 7052 or 7055. I haven't even thought about H8 at this point.
I should have a bench setup for my spare IX ECU in the next month, and then we'll see what I can put together.
(By the way, I hope you don't think any of my post was directed at you; I can actually see Colby's point of view in this, but I just think he needed to man up and do what he promised, rather than quietly ignoring the issue.)
Dec 22, 2009, 05:34 PM
#15
I am going to go out on a limb here and defend Colby. I dont really care that ECUFlash is buggy, I havn't really hit any bugs - it does what I need it todo, and Colby is pretty keen to add new features...
Now after going through the X flashing code myself it is apparent that Colby has put a LOT of time and effort into getting it to work.
$169 for a cable? Not really that expensive. Especially when you pay $100 for a filter?!?! Don't forget its not just the electrical components that cost money, as Acamus has said, IDA + ISO/SAE's + TIME = LOTS!
Anyways your VE map I have listed as a AFR compensation map.
Basically the same thing - just different names.
I havn't looked at your TPS/AFR table yet..
Now after going through the X flashing code myself it is apparent that Colby has put a LOT of time and effort into getting it to work.
$169 for a cable? Not really that expensive. Especially when you pay $100 for a filter?!?! Don't forget its not just the electrical components that cost money, as Acamus has said, IDA + ISO/SAE's + TIME = LOTS!
Anyways your VE map I have listed as a AFR compensation map.
Basically the same thing - just different names.
I havn't looked at your TPS/AFR table yet..