It seems you got the same link for both of the above


Did the very last of your instructions get cut off?
"confirming that the iginition"

Maybe a max chars per post thing?

Thanks again.

So I downloaded the ROM from my car (ZA1J700C).
It seemed to work fine.
However when I try to save the ROM Image, it doesnt matter if I select "Structured ROM files (*.srf)" or "RAW ROM Files (*.bin *.hex)" it always saves in *.srf format.

I dont want to try to write until I have saved off my stock ROM (just in case).
Is this expected?
I assume that I need to save it in *.bin or I would not have any hope of restoring it in the future.

I compared the 'read_image.srf' to a stock_rom.bin for the ZA1J700C that I downloaded from the RR thread with hex editor.
They appear to be exactly the same except the *.srf file is missing the 0x0000-8000 padding.

I tried saving as both *.srf & *.bin thinking they might just be backwards in the pulldown menu.
Both times (to different paths) the files showed up as *.srf
I tried to attach the *.srf file, but it says "Invalid file".

I'll reboot everything and try again.

I have read all 25 pages of that thread more than once. I didnt memorize it.
Yes I use: File -> Save As, and in the pullup I select "Raw ROM Files (*.bin *.hex)"
It saves it as:read_image.srf
If I select save as *.srf, it saves it as a *.srf

When you say it works: So the file gets saved as 'read_image.bin"?

Here is a video of my trying all of the options:
http://s366.photobucket.com/user/stu...55606.mp4.html

I guess I'll try to reinstall ECUFlash.
This is on an XP machine BTW

Ai yai yai... anyhoo, with the pissing match now over ;) I'll just add that the words 'Alpha' and 'Beta' are there for a reason.

Remember guys, this is open source - all of us do this in our spare time, after our day jobs. And trust me, I could also 'earn' all the donations I've received in 2 years for the 100+ definitions I've posted, and all the ecu analysis work, in a morning - it's not why I do it.

Moving right along - thanks VGI and Stugray for putting that how to up. Just a heads up, I was requested to move the BRZ definitions with the OFT LC/FFS tables into their own branch (OFT) (here: https://github.com/TD-D/SubaruDefs/tree/OFT)

If you're looking for the Ecuflash definitions, look here: https://github.com/TD-D/SubaruDefs/tree/Alpha/ECUFlash - you will also need the updated 32bitbase.xml - here: https://raw.github.com/TD-D/SubaruDe.../32BITBASE.xml

The easiest thing to do it to download the entire repository, and then point Ecuflash to the Subarudefs directory. Even better, albeit more of a learning curve, is to set up a local Github repository, and then point Ecuflash to that directory. That way, you can update the entire directory regularly (easily, using Github with a GUI) and you'll have whatever new and exciting stuff I've added recently ;) Granted, Github is a bit of a ballache to get your head around initially...

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

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

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?

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.

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.

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.

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.

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....)

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.

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.

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.

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.

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...

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.

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?

It's one of those "if you have to ask" for the moment, but it won't be long before it's ready for the masses :happyanim:

i've been working on this for a while, in ruby.. pm me and i'll send you my email lol.

Is there a clear understanding of the algorithms the ECU uses to control injector firing? How about cranking?

I asked similar questions on this thread:
http://www.ft86club.com/forums/showthread.php?t=49231

I would even like some simple state diagrams that show OFF->START->RUN_cold->RUN_warm->CLosedLoop->OpenLoop.

As they say "you can figure it out if you just read".:bonk:

Fuel system status:

A01C: FFF8DC0E (Colby gave me that one)
A01G: FFF8D2E2

returns an 8 bit parameter;
1=OL, not up to temp
2=CL
4=OL or decceleration fuel cut
8=OL due to system failure

Injection mode:
The parameter I defined above works:
1=Port injectors only
0=Direct injector only
Anything else = Port/Direct injection ratio

Note that this does not exactly tell the true story as it is the value before compensations/thresholds are applied.

You can also use the injector pulse width parameters to see what the port/direct injectors are doing (same for both A01C and A01G ROMs):
Port PW (before latency added):FFF887C8
Direct PW (I think): FFF887F0

injection mode should be 1==port only 2==di only 3==combined.

I wish you the best... I wish I knew enough about that stuff to contribute more.

Do you know which RAM address is pulled for that? I saw the mode switch in Techstream but haven't found where that gets put in RAM.

The benefit of using the port/direct ratio RAM value is that you can see when your port/direct fractions change from 0 to 35 to 50 to 100%.

It's absolutely necessary for FI (or any time you change maf and injectors).

i have ida pro and know some assembly but not enough to be useful. i think i still have my tactrix cable laying around somewhere...

Fuel sender level

That is one of the problems with this ratio: there are some compensations added afterwards and you will still get some fuelling values in an injector set when the table lookup suggests that you should be running none. The second and third value are the first IPW + latency added. The logic behind direct/port control is actually quite complex and a real snarl to try to work out from the ROM.

Changes with voltage and MAP - will usually be around there.

I got Colby's ecuflash beta, updated the firmware in my OP2 and recorded some stand alone logs yesterday (01C factory rom). It all appears to work and it's quite fast, yay!

Are there RR logger defs available yet? I want to try the "learning view" equivalent I understand has been added to RR.

Been quite swamped at work, so unfortunately have not had much time to do heavy duty trawling for parameters, will try when I get a chance. Romraider logging alpha is up and running - but OBD parameters in mode 1, so much slower. Also learning I believe is not yet functional for the BRZs.

http://www.romraider.com/forum/viewt...p?f=14&t=10284



Sent from my iPhone using Tapatalk

is anyone else going thru hell trying to get the beta to run on a Windows 8 laptop?

I have installed and used the official release ECUflash on my bothers WRX and got clued into downgrading the .netframework to 2.5 compatible to make the OP2.0 work in windows 8, but I can't get the BRz Beta Ecuflash to open on my laptop ATM...

Any brilliant ideas (already tried all compatibility settings for installer and installed program...as well as run as admin on both counts....)

Question:

If you pull an old ROM that has no ECUFlash definition and save it as a 'stockROM.srf', can you flash it back on the car?

I see in this thread: http://www.ft86club.com/forums/showthread.php?t=58399

where:
It seemed to work for FRS-AZ.
That would be great news, but I didnt think that would work and I dont want to "experiment".

Which older Rom CAL id is it? It's trivial to put together a flashing XML for Ecuflash - let me know the CAL id, and I'll pop it up on Github.

The only difference between srf and bin is that srf deal with sparsely populated roms, as opposed to raw files. Only Ecuflash can read those now, unfortunately. I'm hoping Colby will implement the Ecuflash kernel code soon that replaces the OEM bootloader, will be much quicker and I suspect dispense with any of these flashing issues.

Thanks for the offer. I had ZA1J700c on until very recently.
The dealer updated me to ZA1JA00c about a week ago, but that is far as they would go with the older car.

No problem.

Anyone have a rough eta on when this and romraider will be polished enough to tune with?

The romraider definitions are well defined, in fact the OFT guys are using them now. DSchultz also just managed to get his hands on an ecu, which will speed up the integration of (ODB) logging into the Romraider logger. As to when Ecuflash will move out of beta, not sure - but it is all usable as we speak.