Ok, but how does it actually WORK?!?

[stugray]

This is still somewhat related to the OP:
1 - When the ECU boots, I assume that it transfers the software image from Flash Memory to RAM, then begins executing from RAM - Yes?

2 - Once the ECU SW is running, the CAN bus monitor may request data by asking directly for memory addresses from RAM? I have a tactrix cable (waiting on definitions) and an ELM327 OBDII monitor. So when the OBDII monitor is requesting data, is the ECU actually just reporting memory contents?

3 - I read some of the "AccessTUNER_HelpFile_Subaru" manual from COBB tuning. The way it reads, it sounds like the manual is suggesting that you can make modifications to parameters in the MAPs (obviously in RAM, not flash) while the engine is running. Is that the case?
If not it seems like having to reflash for every tiny adjustment would be a huge PITA (not to mention a risk to the ECU having to do it too often).

Am I close?

[FirestormFRS]

Originally Posted by arghx7

They don't leave very good documentation and concentrate it in the minds of a core group of team members. Remember that there is limited turnover in Japanese companies so they can count on those individuals sticking around for a while.

That's so far off base. Because they do a better job of controlling documentation than other companies doesn't mean they don't document every single bit of information about every single step of the manufacturing process. The most impressive part of working for them is the level at which you learn to document every single thing.....twice.

Those guys are the kings of crossing your T's and dotting your I's.

[arghx7]

Originally Posted by stugray

This is still somewhat related to the OP:
1 - When the ECU boots, I assume that it transfers the software image from Flash Memory to RAM, then begins executing from RAM - Yes?

I'm not an expert on the minutiae of how that kind of low-level handling of data occurs on a production controller (stock ECU that comes on your car). On a $10k prototype ECU, yes that's true for the most part. There are external RAM modules that plug into a modified ECU. And that's why you can make realtime changes to anything that would normally be stored in ROM. On a stock ECU, only small portions run in RAM at a time. It would be WAY too expensive (in the mass production sense) to have the amount of RAM equal or exceed the amount of flash memory on you mom's minivan.

2 - Once the ECU SW is running, the CAN bus monitor may request data by asking directly for memory addresses from RAM? I have a tactrix cable (waiting on definitions) and an ELM327 OBDII monitor. So when the OBDII monitor is requesting data, is the ECU actually just reporting memory contents?

Again, I don't know every detail of how all that is handled on the lowest level of the system and how it varies with manufacturers. What I can tell you is the ECU is sending a ton of messages across the bus in its normal operations. When you send a request through a normal OBD II, you are communicating through a standardized system for requesting data. You are intrusively asking for something; you're not reading RAM values with some tool you can get off ebay. You're reading whatever the ECU chose to report, at whatever speed it decides to give you based on its prioritizing of the bus.

IF you have the right commercial tools, you can read the "real" CAN signals that are already going on the network. Probably the most common commerical tool is Vector CANalyzer. This includes things like vehicle yaw rates, steering angle, turn signal commands, and torque requests from various modules. It's all (or some portions) a bunch of hexidecimal nonsense unless you have access to the CAN .dbc file from the OEM.

3 - I read some of the "AccessTUNER_HelpFile_Subaru" manual from COBB tuning. The way it reads, it sounds like the manual is suggesting that you can make modifications to parameters in the MAPs (obviously in RAM, not flash) while the engine is running. Is that the case?
If not it seems like having to reflash for every tiny adjustment would be a huge PITA (not to mention a risk to the ECU having to do it too often).

If I run a standalone ECU like an AEM EMS, for the most part I can change any important value in the ECU in real time. If I have a prototype stock ECU (which is very very expensive) and all the right resources I can move all the ROM values into an external RAM module. From there, I can change anything I want in real time and record at a very speed.

With an Accessport (and a few other tools out there for various applications), Cobb has cleverly managed to use built-in RAM on the stock ECU so that some realtime changes are possible. So when you tune a WRX with AccessTuner, you get a small list of "realtime maps" which include primary fuel and spark, boost control, rev limiter, etc. This is a tiny portion of all the normal ROM values, but it's all you need for most tuning activities. These values will stay active as long as the battery isn't unplugged. You have to flash the changes to the stock ECU (just like a dealer tool would) to make the changes permanent. The final result is a much easier tuning process for most things in an affordable and usable package.

Some things can be very very difficult or at least time consuming to tune in a vehicle when reflashing is the only method. MAF and injector scaling is a big one, and boost control. IMO, that alone is worth the money for going with Cobb over Opensource on a DIY tuning project if you have a WRX/STi.

Originally Posted by FirestormFRS

That's so far off base. Because they do a better job of controlling documentation than other companies doesn't mean they don't document every single bit of information about every single step of the manufacturing process. The most impressive part of working for them is the level at which you learn to document every single thing.....twice.

Those guys are the kings of crossing your T's and dotting your I's.

I'm not referring to manufacturing. That's something the supplier deals with. I am referring to information on what all the maps in the ECU do and how all the values are calculated. I am referring to information on what tables to modify in what order to actually make useful changes.

Now, are some polished information about controls given to government regulators to satisfy certain questions of OBD and emissions? Of course.

[stugray]

Originally Posted by arghx7

With an Accessport (and a few other tools out there for various applications), Cobb has cleverly managed to use built-in RAM on the stock ECU so that some realtime changes are possible. So when you tune a WRX with AccessTuner, you get a small list of "realtime maps" which include primary fuel and spark, boost control, rev limiter, etc. This is a tiny portion of all the normal ROM values, but it's all you need for most tuning activities.

Thanks for the detailed response.
The systems I work on give direct access to the running SW via a JTAG or serial "terminal" access.
Either of those give access to the RAM and you can manipulate memory or registers directly. However there is an OS that gives terminal access. JTAG is in hardware so it works even without code support running on the ECU

So I looked at the SH7058 manual and there IS a AUD (Advanced User Debug) port that allows direct read/write access to the system RAM while the code is running.

I thought that might be how Accessport was manipulating system parameters while in operation. You just need the correct header file for the ROM and you would have access directly to MAP data, assuming any MAP data is stored in RAM during operation.

Do the stock ROMs store any MAP data in RAM?
If so the AUD port could be used to manipulate it (Assuming it is brought out to a header or test points)

[arghx7]

Originally Posted by stugray

Do the stock ROMs store any MAP data in RAM?
If so the AUD port could be used to manipulate it (Assuming it is brought out to a header or test points)

Certain learning tables are populated in real time, for knock control, fuel feedback, etc.

[Ralph Spoilsport]

at the idea that Japanese auto manufacturers and their vendors (e.g. Denso) are not documenting the shit out of their control system software.

"Unintended Acceleration", anyone?

No, I'm not an industry insider and so of course, I'm speculating.

But if *you* were running Toyota, would you be content with a "brain trust" and scanty docs? If you were a part of any .gov DOT, would *you* be content with this?

[arghx7]

Originally Posted by Ralph Spoilsport

at the idea that Japanese auto manufacturers and their vendors (e.g. Denso) are not documenting the shit out of their control system software.

"Unintended Acceleration", anyone?

No, I'm not an industry insider and so of course, I'm speculating.

But if *you* were running Toyota, would you be content with a "brain trust" and scanty docs? If you were a part of any .gov DOT, would *you* be content with this?

There's a difference between documentation that Matlab spits out, basically boilerplate block diagrams, and documentation of how it actually works. In a usable "how to" form. You can reverse engineer anything, and in a global company sometimes you have to reverse engineer your own products. I realize that sounds absurd, but in global companies there are lots of divisions that don't talk to each other or trust each other for that matter.

As for the brain trust, it's part of Japanese business culture. Many Japanese companies are paranoid about corporate espionage, especially from companies in developing countries.

[qoncept]

Originally Posted by arghx7

You can reverse engineer anything, and in a global company sometimes you have to reverse engineer your own products.

There's a huge difference between understanding high level source code picking through assembly code in an embedded application.

Documentation for each of the ECUs processes most certainly exists. I've never heard of or even considered such a thing to be publicly available.

[mad_sb]

Originally Posted by stugray

This is still somewhat related to the OP:
1 - When the ECU boots, I assume that it transfers the software image from Flash Memory to RAM, then begins executing from RAM - Yes?

2 - Once the ECU SW is running, the CAN bus monitor may request data by asking directly for memory addresses from RAM? I have a tactrix cable (waiting on definitions) and an ELM327 OBDII monitor. So when the OBDII monitor is requesting data, is the ECU actually just reporting memory contents?

3 - I read some of the "AccessTUNER_HelpFile_Subaru" manual from COBB tuning. The way it reads, it sounds like the manual is suggesting that you can make modifications to parameters in the MAPs (obviously in RAM, not flash) while the engine is running. Is that the case?
If not it seems like having to reflash for every tiny adjustment would be a huge PITA (not to mention a risk to the ECU having to do it too often).

Am I close?

Your talking about real time tuning and that is a ways off to say the least.

[stugray]

Originally Posted by mad_sb

Your talking about real time tuning and that is a ways off to say the least.

This thinking is what led me to believe that a Unichip just might be a tuners friend.
You could install the unichip, then tune (in realtime) the timing & MAF scaling.
Then remove the unichip & incorporate those #s into the maps.
Then continue the standard tuning with flashing.

Seems it might save some time and a few flashes to the ECU.

Would that be much of a benefit?

[FrX]

With Unichip, you will constantly be fighting against the ECU itself. It will notice that things aren't happening the way it was wanting and start to apply learning compensations.

[bdanisi]

wow this thread was not inteded for fucking casuals like me haha ill just leave tuning to the pros

[stugray]

Next question(s):

1 - Does this ECU use a RTOS?
I saw this thread (http://www.ft86club.com/forums/showthread.php?t=50251) about the toyota acceleration issue and it mentions: OSEK
http://www.edn.com/design/automotive...s-consequences

OSEK Open Systems and their Interfaces for the Electronics in Motor Vehicles

So does the BRZ use a RTOS? (real time {embedded} Operating System)

That would completely change the way that the ECU code is reverse engineered.

2 - In this thread: http://www.ft86club.com/forums/showthread.php?t=47113 (Advance Mutiplier resetting on restart?) it seems that the ones that reverse engineer the code that makes this stuff go would be able to answer that question by just looking at the code.
Why cant the code monkeys answer that question for them (I am not an IDA expert, so I am not volunteering).
I just seems that if you have rev. engineered the code to determine what all the maps mean that you should be able to tell what the ECU does at boot.

I am still wondering about the state diagram that just takes this engine from: ECU Off -> ECU On -> Engine start requested...

Still learning

[arghx7]

Originally Posted by stugray

I just seems that if you have rev. engineered the code to determine what all the maps mean that you should be able to tell what the ECU does at boot.

What the maps mean and how values are calculated for engine operation are pretty different from some low-level hardware stuff. The controls are handled by the guys tuning the car, and the ECU supplier handles the low level stuff. When it's reverse engineered, often you have a guy who is good at IDA and digging through assembly code who might not be as strong in automotive controls or actual tuning methods.

Reverse engineering for tuning purposes is all about finding which "knobs to turn" to get close enough to a desired final results. Here's a perfect example: Cobb really doesn't know how ignition timing is calculated on the R35 GT-R. They found some maps though that if adjusted, will change the final ignition timing value in the intended direction.

Knowledge of those three things: how the low-level hardware and software work so you can break into the ECU, what the maps generally affect, and what to change to get the desired final result are really all separate. You can know a little bit of each, or be an expert on one or two out of three. On the OEM level, there are entire teams often within separate companies for each of those functions.