ECUFlash - Getting close!

[Td-d]

The best way, really, is through disassembly of the rom and a thorough trawling. Is there something specific you are looking for?

[AdrianG]

I'd like to see the address for defogger, or something simple to use as a trigger for OP2 logging...

I'm curious about the tools you use for disassembly.. is there an IDE that someone like me could get their hands on to learn more?

[ztan]

Originally Posted by Acree

Is there any way to discover CANbus definitions/addresses/data using the OpenPort or ECUFlash?

As Td-d said, disassembly is best, but makes your head hurt.

I also tried USB sniffing (with any sniffer or logic analyzer you care to use) with Techstream which uses Toyota OBD mode 21, currently unsupported by OpenPort standalone:

http://www.romraider.com/forum/viewt...8475&start=285

ECU requests are made with 00 00 07 E0 and ECU responses are 00 00 07 E8.

Within Mode 21, I think Defogger sits at CAN ID 22, Byte 12.

Techstream also lets you interface with VSC module (00 00 07 B0) which gives you back stuff like wheel speeds, steering angle, G force data and yaw rate.

[ztan]

Originally Posted by AdrianG

I'd like to see the address for defogger, or something simple to use as a trigger for OP2 logging...

I'm curious about the tools you use for disassembly.. is there an IDE that someone like me could get their hands on to learn more?

I'm new to this also, from a non-technical, non-NASA background.

Get the Renesas 72531 user manual, SH2 and SH2_A software manuals from the Renesas sites.

Have a look at NSFW's RomRaider posts on IDA usage:

http://www.romraider.com/forum/viewt...hp?f=25&t=6303

and HEW usage:

http://www.romraider.com/forum/viewt...hp?f=25&t=7680

A fully functional HEW with SuperH tools is obtainable from:

http://www.kpitgnutools.com/index.php

All are a bit of work to get to understand, and the memory and processor settings must be right for HEW to work well, but once it works, you have a fully functional simulator and can look at all the registers and memory as you step through code, seeing how each instruction works on the chip. Doing this also helps you understand the SH2 manuals more easily.

[Td-d]

There's also a great simulator called SimSH which is very useful in stepping through the code to see exactly what's going on. I've used it predominantly on patched roms (with additional functionality added), but very useful none the less.

[Td-d]

Once all the logging parameters are bedded down, I'd like to start a conversation here on using Matlab or Octave to crunch the numbers. Excel is fine for the slower logging solutions out there, but the sheer volume of data that is produced by the OP2 will easily overwhelm most spreadsheets. I used a script on Matlab that was posted years back by a user to crunch the MAP compensation maps (the dreaded STI stumble issues) - Excel took 2 hours - Matlab took 26 seconds.

[stugray]

Originally Posted by Td-d

Once all the logging parameters are bedded down, I'd like to start a conversation here on using Matlab or Octave to crunch the numbers.

Explain in a little more detail what you would like to do.
Using Ruby is dirt simple (if you dont want a lot of graphics) and very powerful.
I have written number crunching scripts that dealt with multi-GB files.

The only problem with Matlab is someone would need a license to complie the code into an executable (maybe we can find someone with access to Matlab and some smart people at work....)

[stugray]

Re: my problem writing a pulled ROM as a *.bin.
I uninstalled & reinstalled ECUFlash with the BRZ Beta install.
Same issue: will not write as bin even when *.bin *.hex is selected.

Tried it with a fresh install on a windows 8 machine and it worked.
While saving it did give me the warning that it would have to pad areas of the ROM with zeros.....
Then the file showed us as *.bin.

No idea why it wont work under XP.
And in both cases (XP & Win8) the OP2.0 driver package that came with the BRZ Beta install did not work. ECUflash could not communicate with the OP2.0.

I had to pull the driver package from tactrix:
op20_drivers
And then the OP2.0 would work.

[Td-d]

Originally Posted by stugray

Explain in a little more detail what you would like to do.
Using Ruby is dirt simple (if you dont want a lot of graphics) and very powerful.
I have written number crunching scripts that dealt with multi-GB files.

The only problem with Matlab is someone would need a license to complie the code into an executable (maybe we can find someone with access to Matlab and some smart people at work....)

Well... not me personally, since I don't have a BRZ

Most of the open source tuning tools - i.e. MAF calibration, MAP compensation tables (those two in particular), speed density VE tables - that are available (see here: http://www.romraider.com/forum/viewforum.php?f=32) are in Excel. Excel is a dog for crunching files that are hundreds of Mbs large (which the OP2 in mode 23 logging very easily can generate).

Ruby makes sense - I mentioned Matlab or Octave, since that what the scripts put up were coded in. I just think it would be worthwhile to pool the collective programming / engineering brainpower on here to create utilities that can do the same function, but obviously much quicker than spreadsheets.

[Td-d]

Originally Posted by vgi

@Td-d quick Q: i think the RR has MAF scaling functionality in the logger. So why is there a need to use the spreadsheet? I haven't used (or even looked yet) either one so sorry if the Q is kinda stupid (eg ss works on existing logs vs rr is a process along side of rr logging).

Not a stupid question at all - the accuracy of the MAF tab in the logger as a means of MAF scaling in the lower parts of the scale is sketchy. After the low pulse width compensation tables were found, one hypothesis is that these compensations skew the readings low down. I think the best way to scale is to actually run the car in open loop completely, removing the effect of all the (numerous) closed loop compensations.

[Td-d]

I've always used the Badnoodle one - http://www.romraider.com/forum/viewt...hp?f=32&t=4863 - can be used for both open and closed loop. The other much used spreadsheet is the MRP comp spreadsheet by Airboy.

[mad_sb]

Originally Posted by xjohnx

interesting tuning note from the thread over on romraider
"For those of you tuning boosted setups, the AF Learning Max value is 60, so if you want to disable AF trims affect on boost OL values, then change the 5, 12, 20 values to something like 5, 18 and 60.1 and no more issue with OL learning trims

The other software guys appear to be using the AF#1 Learning Limits to limit learning to 3% and it is definitely 'capping' the tunes from their true potential."

So, I tried this out today. Sadly it did not seem to do the intended. AF Learning C / High still got set on my way home from work today. And from what i could see on the wideband the set value was applied during WOT. I need to dig into this a little deeper while im still NA. My avg fuel trims are very low, both short and long.. but the AF learning values are not.. I would assume that AF Learning a-c are the same thing as long term trim low mid and high but the LTT values dont seem to jive with the AFL values...

[ztan]

RAM address for (commanded) Port/Direct injector ratio:
A01C: FFF8A0F4
A01G: FFF8A070

This value is the return from the Port/Direct injector ratio table lookup routine. It does not necessarily correspond to the end Port/Direct ratio used.

[glorydays]

So... is this option ready to use for the average noob or is this still a developer only type of deal... OR is it one of those "if you have to ask" type of situations?