Morning guys
Just to answer some of the questions in the thread:
Quote:
Originally Posted by SkullWorks
(Post 1228909)
Is it only the Beta version that will interface the BRZ or will the release candidate 2 out currently work? Guess i need to dust off the OP2.0 again.
|
Ecuflash will allow both the editing and flashing of the Roms onto the ECU, whilst RR is an editor, logger and more recently has learning view capability incorporated (though not yet for the BRZ, the logic will need to be reviewed to see if there are changes, and the Ram addresses identified). I already have a good deal of the extended (4 byte) parameters defined, still digging through the logic to fully define, since the structure of the SSM array table is different in these new roms.
On reading Ecutek roms - the ones I've seen seem to be locked / encrypted. And
Quote:
Originally Posted by shiv@vishnu
(Post 1229522)
There is no "deciphering" of ecutek tunes. They use the same map addresses as the stock tune. And we read an ecutek rom using the standard read protocol used to read stock roms. We won't even bother trying to crack the ecutek security because, IMHO, it's not necessary or even worth doing given other (better) options.
|
echoes my sentiments exactly.
On the issue of the various CAL IDs, I've seen the SADM and USDM roms, and as soon as Colby releases the beta, I'll be able to pull a local (South African) rom, which is the EUDM version. From what I've heard, there are little differences between the territories (generally the US roms are more anal about emissions). In any case, once one rom is defined, it is pretty straightforward to define the others using a set of of templates that speed up the disassembly process. Colby has also mentioned that he will assist with software that he developed that will auto define most of the roms once the initial table template is set up, which will speed things along.
Quote:
Originally Posted by SkullWorks
(Post 1244820)
Rom Raider actually has many more defined tables...and since td-d actually knows what he is looking at/for, ALL of the CEL tables have been Identified and defined. Looks highly promising...just waiting on the beta of ECUFlash now....
|
Since I was already stuck in, I thought I'd finally define all the Alpha parameters that I've pulled out over the past 1-2 years. I've been avoiding it since it's tedious work and time is constrained - especially when it's for over a hundred tables and parameters :D
I've defined about 70 odd 'new' tables for the BRZ, of which ~30 are specific to DI, the other 40 are previously defined 'Alpha' parameters, a lot of which were identified through COBB's implementation on the forced induction platforms (I've never denied that ;) ).
There are still quite a few new tables to be incorporated into the definition, just need to find the time - hot restart, knock sensitivity, idle throttle, the remainder of the tau tables (transient fueling) to name a few (and I need to also trawl the logic to see whether others exist, like cruise/non-cruise map blending).
Once we have a fairly comprehensive solution going, I intend to work with Merp (if he has the time) to see if we can port his work to the BRZ platform (FFS, LC, map switching, Knock CEL flash, High EGT CEL flash, amongst a host of others). Otherwise, I need to start boning up on C## and the Renesas HEW environment...
