pls_pressY4pie

I've been working on a little project lately that has lead me down a path of requiring to tweak the RX8 ECU tune. I was pretty upset to find out that there are no options for doing this without giving someone $250. in my particular case, i am planning on swapping to a 6 port from my existing 4 port engine, this means swapping to a new ECU which means i'd be giving mazdaedit no less than $500 to set the idle speed in my tune 250 RPM higher which is absolutely absurd. Anyway, that's how i'm justifying it.

so i read this getting started post from gooflophaze and am picking up where he left off. After a bit of research and a couple days of coding, i've managed to dump out the ROM from one of my ECUs. As i understand, a few people have managed to accomplish this task. I'm not here to put anyone in particular on blast, but i'm a pretty big open source enthusiast, and was pretty upset to find that despite a few people having roms, there wasn't any open source (or even functioning) projects out there that could do this seemingly simple task yet. I took it upon myself to build it. I posted over on RomRaider, you can find an exe there or on my GitHub.

I would love to know if anyone else is interested in this sort of project. I have a wealth of information that i'd love to share and get something together that allows people to DIY their own tunes.

ciprianrx8

Having ditched already some good $$$$ into mazdaedit, i'd say it is hardly worth its money but it is a neccesary evil. By the time you map out all the maps in all the calibrations, then gasoline might have already ran out...

If you really want to improve upon existing software, then feel free to search for new maps such as AFR enrichment during cold startup.

pls_pressY4pie

finding the tables is not something i find particularly interesting or difficult, just a thing that must be done. I combed thru some of my rom dumps and pretty quickly spotted a bunch of tables in there. I haven't spent much time on that at all yet because it's meaningless if you can't upload the rom back to the ECU. Which i've finally managed to accomplish. The code is still in need of much cleanup, but the protocol is pretty easy to understand once you take a peek at it.

After the key exchange, the TLDR of the upload process is as follows:

7E0#04 B1 00 B2 00000000 enter bootloader mode
7E8#03 F1 00 B2 00000000 ack from ECU
7E0#100934000040000034 request download
7E0#2107 F8 0000000000 size=0x07f800 (522240)
7E0#1 401 36 <data> transfer data(0x36) framesize=0x401



so the trick here, is that there is some internal checks for the size of the payload, and it does a check when the SBL uploads and fails if the bootloader isn't compatible. I'm still searching for that but i don't think it's an unsurmountable. just need to spend smore time on it

wcs

iTrader: (2)

booo hoooo

pls_pressY4pie

I'm still working on the ability to write a rom back into flash. it works on one of my ECUs, but it seems to be keyed to the calid somehow. i have to go trolling thru the SBL to see what kinda stuff it uses in the original rom and see if i can hack it out. feels easy, just running low on time for now.

in the meantime, i've implemented the ability to dump out the contents of RAM from the device. This is handy for.. .well i don't remember why i wanted this at this point, but it was fun to build anyway. Here's an example dump of RAM. It's got some interesting stuff in there, VIN, CALID etc.
One thing this does allow is for creating a live logger of the ECU. this should be much faster than OBD2 logging. I might play more around with this idea in the future. For now it's back to getting the ROM to upload.

ciprianrx8

I might toss my $0.02 that will come in useful later on in your project if you ever get to uploading a ROM file.
Here is how (some) data is represented inside the ROM, as I've found them and had to approximate or guess at times:

uint8 to afr (from Open loop fuel tables)
-0,000000220948560*[x]*[x]*[x] + 0,000160007839136*[x]*[x] - 0,055199890084811*[x] + 14,687952883191700

afr to uint8
-0,2936*[x]*[x]*[x] + 12,861*[x]*[x] - 207,36*[x] + 1201,2

uint8 to timing
[x]/2-50

timing to uint8
[x]*2+100

uint8 to timing retard(such as knock tables)
([x]-128)/2

timing retard to uint8
([x]*2)+128

uint 8 to closed loop load limit
[x]*0,3922

closed loop load limit to uint 8
[x]/0,3922

uint8 to tps
[x]/2

tps to uint8
[x]*2

uint16 to afr(cold start correction like)
(([x]-10000)*0,0001)*14,7

afr to uint16
(([x]/14,7)/0,0001)+10000

uint16 to torque(from desired engine torque table)
([x]-32766)/128

torque to uint16
[x]*128+32766

Where [x] is a value of 1, 2 or 4 bytes(8/16/32 bit int/int/float). As far as I know at this point, there are no signed values used.
Table axis are USUALLY floats.... but uint16 at times too ! The order is columns axis, rows axis, then data(collumn -> row).
To determine what representation to use, look for the start of the next table and see how many bytes you need to cover. Though at times this fails as no meaningful data is found at all, just some axis floats.
Tables are of different sizes, numbers and locations depending on calibration variant, market, year and powertrain variant. Thus, every calibration variant requires remapping, from at least 20% to 100%(nothing fits from another calib).

Some of the most interesting maps I found(but didn't validate any does what I guess they do)


Anyone wants to chime in and point out what these might do ?