MR2 Owners Club Forum banner

2GR-FE ECU Tools and Techniques

72K views 242 replies 21 participants last post by  rahhal81 
#1 ·
This is a thread for gathering information on working with the ECU, i.e. editing its contents. It is not a tuning thread per se although this information could be useful to anyone who wishes to tune their car. Emphatically, this is NOT a thread on EFI or general theory of operation of a modern ECU. Rather the intention is to help people of different backgrounds to come up to speed on the hardware and software aspects of our specific ECU, just as I am trying to do. There is momentum gathering about this as more tools are becoming available and more information is being published. I'd like to acknowledge the work that Marc (Gouky) has been doing with this. All of us driving 2GR-swapped MR2's owe him a huge debt. Part of the intention with this thread is to give him some support in what he's been doing mostly single-handed so far. Some time ago Marc planted the idea of getting people to share information and collaborate on the ECU. Maybe this thread will give a push in that direction. Personally I have zero background or training in firmware, embedded systems, or electrical engineering. I am definitely not an authority on the subject. Every day of working with this I am reminded that the little knowledge I have is incomplete and inaccurate. I'm approaching this as a challenge and a learning opportunity. I'd like to invite anyone else who has information or knowledge in this area to join in contributing to the thread and help to make it more useful. If you know something, please make corrections and suggestions. How is this different from the other threads already here? This thread will have a focus on hands-on tools and techniques and how to use them. This thread will also attempt to catalogue information more systematically, as compared to the progress reports that are given elsewhere.

I'll use this first post as an index/table of contents for the topics that will come later in the thread. The index and the topics will evolve and develop over time. Here's a proposed TOC that might or might not be followed. These topics might not necessarily be addressed in the order listed:

1. Architecture
2. Communication protocols
3. Tools
4. The calibration file
5. Maps
 
See less See more
#4 · (Edited)
This section is for tools available to work with the ECU. I'll be filling it in as we go along.

1. Tactrix Openport 2.0



This tool allows communication between the laptop and the ECU through the OBD2 port. It is of interest because it is the suggested tool for use with I0tech software which can be used for editing the ECU's binary files. I'll add more info about I0tech as it becomes available. Tactrix Openport requires use of software to manage the communication. The suggested software for communicating with Toyota ECU's is PCMFlash.

-------------------

2. Toyota/Lexus ECU Flasher

Rectangle Gas Bumper Laptop accessory Audio equipment



This tool supports reading and writing to the ECU. Reading the bin file is done through the JTAG port on the ECu's circuit board. Writing can be done either through this same port or through the OBD2 port. This tool has dropped steadily in price now $750 which is not much more than Tactrix plus software. See Marc's user notes on this tool in Post #8 below.

--------------------

3. Elmscan Toyota

Runs on your Android phone or tablet. Download from the Google Play store. This diagnostic tool gives access to the proprietary Mode 21 PID's, which are generally not available in consumer-class scantools and software (like Torque). For the price this is amazing. I wrote some notes about it here. I recommend this very highly. No brainer.

---------------------------

4. Torque Pro.
This is possibly the gold standard of consumer-class OBD2 scantool and logging software. Runs on Android. It is severely limited and inaccurate but it serves its purpose for most people. You do not use this for any serious application but for driving around and keeping an eye on engine parameters it does fine. Elsewhere on this forum I've dug deeply into why this tool is not to be trusted blindly.

---------
5. Techstream
This is a Toyota proprietary tool. With this tool you can perform all Toyota-approved functions for modifying the ECU, including flashing new binaries, editing vehicle settings (like whether your doors ding or whatever), programming keys to the immobilizer, running diagnostic tests, et cetera. For most people this tool is available only in various hacked/cloned versions offered on eBay by Chinese sellers in complete violation of US copyright law. If you work at a Toyota dealer you have access to a licensed version. I have nothing else informative to say about this.
 
#5 · (Edited)
The calibration file is a proprietary file format that Toyota uses to upload data into the ECU with the Techstream Calibration Update Wizard (CUW).

Detailed information about the calibration file is in this 2014 whitepaper titled "Adventures in Automotive Networks and Control Units" starting on Page 75. The authors also provide a set of tools for manipulating the calibration file that can be viewed here or downloaded here in zip format.

Toyota calibration files are of interest because they can be easily obtained for example from Toyota's Technical Information System (TIS) and used for study. A calibration file contains all of the maps that are used for tuning the ECU. The calibration file is a good way to get hold of the original maps without opening the ECU. The maps can be edited then flashed back into the ECU through the Data Link Connector (DLC) aka the OBD2 port - again without opening the ECU. This will be covered in detail.

As noted in the whitepaper, calibration files are encoded in a standard format called Motorola S-Record. This is to facilitate transfer of data. The encoding makes the file appear as gibberish if viewed directly in a normal calibration file editor like WinOLS. Here is what a calibration file looks like in WinOLS.

75823


This was a sample calibration file that Marc shared a few years ago [1]. The header is recognizable but nothing else is recognized as a map because it is in encoded S-record format. You can see how all the records follow a pattern starting with the letter "S."

Also as noted in the whitepaper, the file header includes a key for the file (TargetData) that is used by the Calibration Update Wizard to enable flashing. If it were possible to hack this password then in theory it would be possible to upload modified non-original Toyota calibration files into the ECU with Techstream. I don't know if this can be done. However I will cover other tools needed for flashing the maps back into the ECU successfully.

In order to look at the contents of the calibration file it's necessary to use S-record decoding tools. For example Srecordizer is a visual editor that decodes and edits S-record encoded files.

75824


The limitation is you'd have to know exactly what to edit.

Other s-record decoding tools, for example Srecord, run under Windows XP. (If you don't have Windows XP you get Oracle VirtualBox and install an XP disk image as a virtual machine on your system). Then you can run Srecord from the command line to convert the S-record encoded file to an un-encoded binary file. For example the following command converted the file name test.cuw to a binary format with the output going to test.bin, with some errors reported on the first 34 lines of the file, which make up the header.

75825


Next we try to view the binary file.

[To Be Continued]
 
#41 ·
In order to look at the contents of the calibration file it's necessary to use S-record decoding tools. For example is a visual editor that decodes and edits S-record encoded files.


The limitation is you'd have to know exactly what to edit.


[To Be Continued]
How were you able to open the .cuw file in srecordizer? I am not able to select the .cuw from the open menu. If i select all files, it gives me an error.
 
#6 · (Edited)
This is a rundown of maps that are known to me. I will add any contributions from others. At this point all the credit for finding and documenting these maps goes to Marc. My renderings are based on the 4G00 Rav4 ECU binary linked in Post #9.

1. Accelerator Pedal Map and Torque Demand Maps.
The ECU uses these to determine the throttle opening in response to the pedal position and load. It takes the pedal position at a given load and applies a transformation. In linear algebra this is known as a convolution. [PS. Convolutions like this are useful for making calculations in the curved and non-uniformly stretched geometry of space-time. So you could say that our ECU's operation is based in part on Einstein's General Theory of Relativity.]

75827


2. VVTi Intake and Exhaust Maps.
These set the target for the cam advance angle based on load and rpm. The advance angle is PID controlled with feedback from the cam sensors with the OCV duty cycle as the driver.

75828


3. Fuel Map.
This is Marc's rendering of the map. Even with this input I have not been able to find this map in WinOLS. This is a perfect illustration of how WinOLS can miss significant maps.

[https://frankensteinmotorworks.com/2GRFE/tunes/New2GRAFRChart.jpg]
this image has been deleted by the author and cannot be recovered
 
#8 ·
I haven't found a cheap tool yet, but when they dropped the price of this from $1050 to $800 i purchased one because my setup here was a complicated disaster for programming these and it works great: http://ecutools.eu/chip-tuning/toyota-lexus-flasher/

all the tune editing I'm still doing by hand with a hex editor. there are a few tools advertised out there now and frankly they are all crap. I've purchased a few of them to see if they can make my job easier and they are all developed in eastern europe and the focus there is diesel engines so they seem to be off on several things on these gas engines and i also don't think they've ever actually seen a 2GR-FE. this includes the bitedit tool advertised on the same site.

The flasher tool also integrates the checksum algorithm so it's everything you need to get files off and back on the ECU, also all the ECUs i've sold still have the JTAG port soldered on so it's easy if you go that way.

I'm still using a custom home made programmer for the immobilizer stuff because i'm using a low voltage programming mode to avoid powering up the rest of the ECU without needing to desolder that chip. I'm sure something off the shelf would work but i'm happy with my setup and haven't looked further.
 
#12 ·
yeah, i just use the free winOLS also just to find addresses. i use hex workshop to do the edits manually.

keep in mind many of the tables it finds aren't actually tables. it's also missing some tables that do exist but winOLS does find the vvti tables and the timing tables.

I'm actually not sure what table you're looking at there. it does certainly look like an RPM vs load table but that's an odd pattern inside of it.
 
#13 ·
Hey Gouky,

Have you seen anything whilst investigating these ECU ROMs which might explain the weird 6th gear safe-mode that I get ?
I know these are just tables of data as opposed to the algorithms that are in use so we might not have the complete picture to work it out.

Gavs
 
#16 ·
Frank,

If you want to find the VVT-I tables in that map look at 0x00FB45 for the exhaust and 0x00F6CA for the intake.

the addresses i'm giving you are actually a little bit in the table so your addresses will be a bit earlier in winOLS but it should get you really close.
 
#17 ·
Marc, thanks for your help and support with this. I did get a bunch of tables tagged yesterday. I see what you mean about WinOLS finding some things but not finding others and this is also mentioned in the WinOLS tutorials. Interestingly WinOLS did automatically tag the vvti exhaust map but it did not tag the vvti intake map. For anyone interested, there's a tremendous series of video tutorials on using WinOLS available free on youtube. It does have some outlandish "continental" nomenclature and it is oriented to Volkswagen/Audi (VAG) Ecus but most of what's covered does also apply to Nippon Denso.

So what I was thinking of doing as I get the main maps identified and figured out is to produce a listing or specification of maps or map candidates with address, dimensions, and scaling factors. I'm not quite there and there are some things that are baffling me like perchance did you slip an 8000 RPM rev limit into this file? LOL. There is one table which unlike all the others has 8000 as the maximum on the rpm axis. Also some tables go to 6400, which is what I expected, others go to 6200, others go to some other number. This will take me some time to figure out.... There is one thing I will not "address" and that is the immobilizer, for a few reasons, the main ones being a. it is way above my pay grade so I don't think I could present anything useful there, even if I wanted to, and b. unlike the other info it is not accessible with publicly available tools and techniques so I don't have access to it anyway and that's fine.

Then there are also the other sections of the TOC on architecture, tools, com, to complete so I have enough to keep me busy for a while.
 
#18 ·
That file is 100% stock and the rev limit is 6400RPM. the rev limiter is really frekin' hard to find until you know a few things:
1) the rev limiter is stored in units of 1.28RPM for reasons of i don't know why.
2) the rev limiter is actually a cut and restore RPM that are right next to each other.
3) the cut and restore RPM in these stock tunes are always the same number it seems
4) the data format in this file is all little-endian.

I'll tell you what the address is of the rev limiter but i'm curious if you can find it with that information first.
 
#20 · (Edited)
I'm getting there slowly but surely and I stumbled upon something useful which is the "table storage format." This is important because if you follow the winOLS tutorial the Bosch VAG format is explained there but the Nippon Denso format is different and it actually makes sense if you've ever watched a Japanese student doing math or taking notes in math class.

Taking the vvti exhaust angle map as an example:

75831


This is viewed in 8-bit decimal. The table is highlighted in blue. The outlines in light blue on the top and to the right are the x-y axis values. The dark blue square is the z-axis values. The dimension of the table 10x18 is in the upper right hand corner right above the table.

So.... if this holds generally which no reason why it shouldn't this should be useful for chasing down and confirming other tables.

Ok so there are other things where gaps in my knowledge leave me perplexed and where in Arthur C. Clarke parlance I assume you relied on divine inspiration or magic like how and why in the heck did you map 11010 to 95% as you did in the Torque Demand and Driver's Wish combo. LOL.

PS> Practical note for anyone wondering: you don't have to squint, you right click on the image and select "View Image" from the drop-down menu to get it at full-size.
 
#21 ·
yeah, I wrote a program to find the tables like that before winOLS and i actually prefer my way a bit more. The number of columns is reliably there but for some reason the number of columns isn't always there but i don't count on those values. to find these 8 bit tables i just look for a list of values that are incrementing which gives me the column headers then with the column headers i can look for the row headers and see if those increment. if i find something that is at least 3x3 in size and meets the incrementing columns and row values i flag it as "likely a table" tables can be smaller but it returns a ton of bad tables if you do that.

another check after the table is found is to see if the table seems to be "smooth" that's a manual process because teaching the computer what looks like a table and what does not is tricky.

1D tables are pretty similar but i have a minimum cut-off of 6 values because i only have column headers and no row headers to verify the "tableness" of the data.

individual values are just tricky and lots of trial and error. you'll notice there are "groups" of data in the file. the timing tables are all close together except one of them (at least that was the case on the highlander) and if i remember right the oddball was the one i think is used for catalytic converter warm up so it makes sense to be part of a different structure.

as for figuring out what values go where, it comes down to a lot of testing. for the throttle i just override the table with a single value and use an OBDII tool to see where the throttle is at. reprogram with a different value, read it again. and a third time to establish the scaling is linear.

and then there's the "cheating" stuff. the speed limiter took a damn long time to figure it out, i never actually figured it out that's when i found bit-edit and that's one of the things they had. but at that they had it as an 8 bit value which maxed out at 255kph which is annoying because the car will actually get there with a 2GR. sure you'll need a bit of distance but probably less than 2 miles so it is attainable at the top speed events they have here and there across the country. I know from persona experience in a 1 mile run from a standing start with the 2GR you can hit a hair over 145mph so from there i had to dig to see if the value was actually 16 bit instead of 8 bit as they flagged it. obviously doing a 165mph run to test it wasn't going to happen so first i set it to 30mph go drive the car to confirm the limiter hits at 30mph then set the 9th bit to 1 and check again. if the limiter hits at 30mph that bit isn't watched. if it does not then that bit is very likely adding 256kph to the top speed. set all 9 bits to 1 and the limit is very likely 512kph (320mph) and nobody will hit that with a 2GR running the stock ECU so there's no reason to check the further bits because for all i know some of those bits are flags for other behaviour.

So there's a ton of trial and error by loading it on a car for this stuff. you'll quickly get to the point where you need to load it on a car to check stuff.

I've also got some JTAG debugging stuff i've been digging into for the fuel injector scalars but that's all fruitless at this point.

Another thing to consider is the unintended acceleration report really goes into lots of details if you read between the lines. it also confirms the CPU core despite being white labeled as a denso chip but it does not mention which part it actually is and there are none that match the exact pinout so we can get the instruction set but not the internal peripheral map so it's damn hard to decode the code.

decaping the CPU chip may reveal some stuff. the first cheap step would be to send it to a place like this to see if there are two dies inside there: Dangerous Prototypes it's also possible they just have dummy pins to throw us off. but the resolution of that service isn't enough to really figure out what chip it is on it's own if it's a single die. and yeah, i could also use my mill to put a well in one of these chips and then use nitric acid to decap it myself. but that gets more complicated because nitric acid is hard to purchase so you have to make it. I have some 15kV power supplies to generate the arc and you just bubble that air through water and you'll get your acid if you wait long enough but you can easily see how that's a very deep rabbit hole with no end in sight and that still does not account for all the equipment needed to properly photograph it. I already have a trinocular microscope but i don't have a camera for the camera port and i only have a 10x objective lens on it which likely isn't enough for this.
 
#32 ·
Another thing to consider is the unintended acceleration report really goes into lots of details if you read between the lines. it also confirms the CPU core despite being white labeled as a denso chip but it does not mention which part it actually is and there are none that match the exact pinout so we can get the instruction set but not the internal peripheral map so it's damn hard to decode the code.
Why not ask Renesas? Last year I downloaded some of their tools:
https://www.renesas.com/en-us/software/D3017597.html

I got a software registration and followup email and there was a human who was willing to answer my questions. I wouldn't know what to ask. This stuff is way above my pay-grade.
 
#23 ·
yeah, there's a ton of code in there and so much of it is for the automatic transmission. that's why i'm personally waiting a bit until i get this MKIII stuff going and i have time to try again on the 2AR-FE ECU. it's a manual transmission ECU from the factory so all that stuff should not be in there. that ECU should have significantly fewer tables and a lot less code.
 
#40 · (Edited)
I purchased the Tactrix in anticipation to use it on my 2010 Tacoma Xrunner with the Iotech software from OVT. It hasnt been released yet. In the mean time I used it with techstream and it works well and fast. I do have a file for the supercharger cal that I am probably going to flash using the .cuw file through the calibration update wizard. I was told my current calibration, 30458000 could not be used with the OVT handheld or software because it is a factory file. So I asked if I flashed the supercharger file would it then work? OVT said yes. I couldn't find the .cuw file so I asked OVT and he was nice enough to link me to it. I have not flashed it yet. The Tactrix open port 2.0 did work great and even has an SD card for logging on board. Let me know if I can run any tests or help understand some of this stuff. How can I try to read the ecu?
Sorry I'm late to respond, I wasn't notified of any reply here.
 
#31 · (Edited)
Added some known maps.

Added Elmscan Toyota for proprietary Mode 21 PID's.

Also added short notes on Torque Pro and Techstream.

PS. If there are any questions, like for example,
What... is your quest?
What... is your favorite color?
What... is the capital of Assyria?
What... is the air-speed velocity of an unladen swallow?

Just ask and I'll do my best to find answers or just bounce them off to Marc. LOL.
 
#35 ·
If there are any questions, ... Just ask and I'll do my best to find answers or just bounce them off to Marc. LOL.
I've found in WinOLS that you can right-click on the identified potential map section and select "display map optimally" which arranges output in the dump by column/row. You can also turn on the height colors which can you give you a rough color map on those potential maps as well. Nothing earth-shattering but it could be helpful when looking at the data for a general idea.

One thing I was trying to understand related to the VVTI intake map that's identified is that WinOLS has the map at 10x18 but the map Marc has screen captured references two additional rows (10x20). I looked all over the data around this table but I didn't find anything related that indicated where these rows might have come from?

Did you ever find the rev limiter based on Marc's clues?
That file is 100% stock and the rev limit is 6400RPM. the rev limiter is really frekin' hard to find until you know a few things:
1) the rev limiter is stored in units of 1.28RPM for reasons of i don't know why.
2) the rev limiter is actually a cut and restore RPM that are right next to each other.
3) the cut and restore RPM in these stock tunes are always the same number it seems
4) the data format in this file is all little-endian.

I'll tell you what the address is of the rev limiter but i'm curious if you can find it with that information first.
So far, I only got:
1. 6400x1.28 = 8192 (if this meant what I thought.. I didn't think I was supposed to divide by 1.28).
2. seems simple enough that the numbers would repeat somewhere in the dump (I did find areas where 8192 repeated but they didn't make much sense to me as there were higher values in the same potential maps)
3. I assume this would mean 6400 (8192?) since this is the limiter as he mentioned.
4. I read up on this a bit; I get this in conceptual examples on the pages I've read but I've not a clue on how we should be applying this to the dump file.

I've been looking at this for quite a few hours but I'm just not getting it....
 

Attachments

#33 ·
I've already tried that with no success. i did not expect success though. the people working the tech help desk don't know the stuff and if they pull up the documents it probably says "customer confidential" all over it so there's no way they are sharing that info. That document also probably does not say "based off of xxxxyyyy, instead it just describes the peripherals in the chip as if it is any other chip they sell so there is no quick answer to give us without getting that entire spec document.
 
#36 · (Edited)
@ali3baba, welcome to the wonderful world of WinOLS.

First of all I'm curious what version are you using? Mine is WinOLS 3.85 Demo. I don't know if it has all the same features, for example I don't have height colors. Is yours a demo version or licensed copy?

For your comments and questions:

Displaying maps:
You can also double-click on the potential map label and this will optimize the display of the map in the hexdump. If you double click on the map axes in the hexdump or if you double click on the map in the left side-bar then this opens a dedicated window for the map.

The VVTI maps:
I have 11x18 for the exhaust and 10x18 for the intake in this RAV4 binary file. The "blue map" 10x20 is from a Camry binary I believe. So apparently different 2GR-FE binaries have different structure.

Data Organization:
Little Endian refers to the overall data organization in the file. You have the option to flip the organization in WinOLS from LoHi for 16-bit data (that I take to mean Little-Endian) to HiLo by clicking on the corresponding icon in the top toolbar and you get some right nonsense if you do.

The rev limiter:
First a general comment about RPM's. The binary file utilizes two different number representations, 8-bit and 16-bit, and they are intermixed. Some of the maps are in 8-bit format. Others are in 16-bit format. In the 8-bit maps (for example the VVTI maps) the RPM# is represented as RPM/50. In the 16-bit maps the RPM# is 0.78125xRPM or RPM/1.28, You can toggle between the 8-bit and 16-bit views by clicking on the corresponding icons in the top bar of the WinOLS window. I don't know the rhyme or reason for mixing 8-bit and 16-bit in the same binary file.

So to find the number 8192 first you put the hexdump in 16-bit representation then you go to "Find > Byte Sequence / Text" from the top drop-down menu and you enter "8192" in the search field with "Decimal" selected as the character format. Then you use the search arrows to jump from one search result location to the next. There are not all that many 8192's in the file - at least not in the top part of the file where all the maps seem to reside.

Adjacent occurrences of 8192 occur at
0AAE8 a bunch of adjacent 8192's
14FC4 two adjacent 8192's

At 0AAE8 if you apply scale factors (0.625, 0.005245, 0.390625) for (x, y, z) - and note that 0.390625 is one half of the usual RPM scaling of 0.78125 - you get an interesting map but I really don't know if this has the structure of a rev limiter.

75832

As a bonus I've included two extra maps, one that has the general shape of a ignition timing map, and another that resembles an injector opening map.

These maps are just candidates, I have no idea what they really are.

I've found candidate maps for other functions, for example there is a group of maps that appear to be shift point maps. By trial and error I've also figured out how to define maps that were not found by WinOLS- this is very useful to be able to do - but I've not yet been able to find some of the very useful maps that I've been looking for like the MAF calibration or AFR target and so on.

i'm hoping to get more clues after I get an update of the I0tech software from ovtuning that I purchased but which I've not been able to use successfully. Another option is BitBox/BitEdit that I may give a try if things don't work out with I0tech. I've been in contact with support at BitBox, they seem responsive and helpful, they've confirmed that they have files and definitions available for 2GR-FE. It is understood that these may not be complete or correct but they might be a source of more clues. I'll be adding a note on BitBox/BitEdit in the "Tools" section.

PS. Reviewing earlier posts I've realized that my candidates for timing maps fit the description in post #21 so I'll go ahead and post them here for review and comment:

75833
 
#37 · (Edited)
Frank, not to discourage you but I've purchased bitbox and it does have some data but their bread and butter is diesel engines and they really don't have a heck of a lot for gas engines and most of it is missing proper scaling factors or worse, has incorrect scaling factors. Also, WinOLS finds a bunch of maps that look like maps but once you understand things better they are actually code regions. It also somehow misses maps that are very clearly maps. The larger maps are more likely to be real because it's much less likely for a pattern like that to show up randomly. The bigger issue here is that "denso" mostly means "subaru" and subaru stores maps differently than toyota does so all of the map finding assistants i've checked out so far don't work very well on these Toyota ECUs.

*edit* i am pretty sure OVTune has good data but nobody will ever accuse him of good customer service. Personally I'm over two months in after purchase and still do not have a working product.
 
Top