Having successfully inserted a jump in to the ECU code and inserted my own routine to change a single RAM variable in response to a requestID, the next step is to consider how to implement real time mapping.

The comms protocol is I suggest the place to start.

We need a method of reading and writing to RAM. To do this we need say:

One byte that is a command such as read or write
Four bytes to give the address (or maybe two if we are always in a 64 kilobyte range)
One, two or four bytes for the result of the read or the value to write

So really we need to send and receive packets. We need three write and three read commands to work on byte, word (2 bytes) or long (4 bytes). We need all of these lengths, because mapped values to change can be either byte or word. Addresses to relocated tables will be long.

A good protocol THAT IS SIMPLE, worked out now will pay dividends later.

This is I think the most difficult part of getting real time mapping going. It is fairly easy I think to relocate tables to other addresses by simply using a vector table in RAM that tells the ECU where to look - either the original ROM or in RAM.

Writing a protocol from scratch would be a pain and buggy! Hijacking something already there would be good. Bez's mods allowed the request ID to write out two bytes, hopefully we can modify it to do up to 8, and also receive up to 8.

I'm fairly happy to write the routines to process these packets I think. I'm using the Lauterbach monitor for assembling snippets, although I have to work out the offsets to read variables manually(!) and I then have to manually transfer the hex into the ROM using a hex editor.

Discuss...

 

Hi

Fairly quite on this thread! This sounds exciting and I guess you'll be looking for people with past experiance and ideas on how this could be acomplised. I'm sure there will be one or two here with the credentials to get involved.

I found the disasembly thing much much harder than the hex searching, so I guess I'm not culed up enough to offer help.

Ley me try to get the concept straight Is idea the that you alter the code in the ECU to read the data for say timing, from an area in the ECU RAM, rather than the ROM flashed part, you can then, via the laptop, alter the value in the ECU RAM, and thus change the timing while the engine is running. Once the tuning has been done, the values for the tune can be entered into a normal map and flashed back into the ECU.

Not quite a disscusion, but I've increased the post count from 1 to 10 (Ok it's a lame joke, but what the hell)

MB

 

Yes that is the idea

 

JCS -- What would be the practical applications of real time mapping (is this tracing)? I would rather have an application that took into consideration all of my modifications, how my car was running, and then adjusted boost, fuel, and timing curves to optimize power (in real time)...

 

Ecuteck already has live map trace

Its very helpful to pin point exact map areas to adjust

Al

 

Oh thats good!

From the work you've done with the map switching, getting the ECU to read from RAM, is not that hard, and there is enough spare memory to alow you to put a whole 19x19 map with each value 8 bits long. It's getting the PC to comunicate with the ECUs RAM to change the value in a given location that your after ( this is the protocol).

Now your probley thinking, "I just said that !" or at least I hope you do! Well it's a thread bump until MJ or someone like that turns up.

MB

 

cij911, DynoFlash, this isn't map tracing, it is live map editing like a standalone. Map tracing just needs load and RPM, it is a form of logging.

MB, yes you've got it.

 

sounds like an interesting concept.

Like you said, the protocol would have to very simple. I could see it done in a 3 byte header <real time prompt> <command> <data size>. The data block could then have it's own sub command and data associated with it.

With a variable data size format we could easily read/write the data serially using the MUT table as a jumping place to put the code into the correct ram address.

 

Thanks Chris, I wondered about even using a couple of unused request IDs like IIRC E0, E1, E2, E3, E4, E5 to trigger my six commands.

Sending these request IDs would transfer control to my custom routine, then I could find a way to say that the next x bytes were "mine" before giving back control to the normal MUT 1 byte request, echo reply, result reply.

I also wondered about using higher level commands to send to the ECU, but that would need more assembly and work on the ECU side, and I think we should let the PC take the strain, minimise communications and keep it simple?

What do you think?

As well as allowing maps to be moved in and out of RAM, it could also switch between maps, and log any address you wanted without further mods to the ECU.

It seems that the RAM (or at least parts where things like the octane number are stored) stay live as long as you don't reflash the ECU, disconnect it or pull the battery...

 

Yes - similar to Cobb Access Port - they do live flash tuning as well

Its a very helpful tuning aide to speed up the tuning process

Live tuning CAN bite you in the *** IF your not careful as the changes are immediate as in BAMM

Good work !

 

Good point, I suppose if you suddenly block change the fuel map and it runs lean it might not be amusing.

One commercial package I used to use would corrupt the ROM you were viewing when it map traced on occasion. If you saved that ROM without noticing odd things could happen. Needs serious concentration!

 

On that note there would need to be a way to handle a sudden loss of communication from the PC. Like if some of the "next" bytes expected in your routine didn't come down the cable, jump out and run as normal. I know this is kind of obvious, but also VERY important so I thought I would mention it.

Also, what about the need to write a series of values? For instance, if you change a table value drastically and need the values "around" it to be changed in order for the initial change to be safe. I guess you could always do incremental stepping of values...

Also, if this routine takes too long to execute, would that affect the program's ability to manage the engine?

Not trying to be negative, just curious.

 

Good point galvitron. I think read/write a series could be done with the individual requests in order, which like doing continuous datalogging wouldn't upset the engine as the comms is scheduled or interrupt driven.

 

JCS -- Sorry for the noob question, but why would real time mapping be better than the current process? I can see how it may save 30 seconds, but given the risk and time associated to get the application to work, I just don't see the need.

Don't you think tracing would be more beneficial to the Evo community? People could understand what the ECU was doing during certain conditions (e.g. 5th gear boost or after a certain amount of knock whether MWGDC table 3 is engaged, etc.). It seems folks are working on the major components of the ECU right now, but nobody has a complete view of how the entire system works.

 

You could already trace if you log RPM and load, all it would need is work on the PC side to display your map and highlight the 2x2 section you're reading from.

I think we have a pretty good idea of how it works except for the knock filters and the boost map selection.

The boost map selection depends on sometimes just one bit in a status variable that isn't described. It APPEARS that there is gear judge stuff in there but it is disabled in normal use.

Tracing every ROM or RAM location that is accessed would be easily done if you had a hardware emulator as you could with the old EEPROM based ECUs.

Real time read/write to RAM would open up the ECU much better to tell what tables are being accessed though.

Additionally, it can help in tuning MIVEC or ignition timing in particular because you could change it much more frequently than the hassle of cooling down the car, turning off, reflashing, restarting and getting the temps normal again and relogging.