Open Source S1 RX-8 ECU Reverse Engineering, Data Logging, and Tuning - User's Guide
 

Hi folks, just wanted to start to write some stuff down publicly all in one spot about the work that's been done to be able to read, write, modify, and patch the OEM S1 RX-8 ECU in the last few months.

I'll start this multi-post "guide" with describing a purpose, limitations, some history, and some explanation of terms. I will then go into how to install and use some of the programs, though there is a ton of better information already on the internet that can aid you. Other posts will get into what I personally have found to be the ECU logic for things like, ignition timing, fuel injection, knock control, etc. That info is made to help you understand what you are modifying when changing tables/calibrations in the ECU software.

Important Terms
ECU - In this context, I tend to use ECU/ECM/PCM all to mean the RX-8 Engine Control Unit/Engine Control Module/Powertrain Control Module. This is the main brainbox that runs the engine
Definitions - Also know as "defs", or "ECU defs". This is the metadata that describes ECU tables/calibrations/things to modify. It's essentially a map of the ECU that tells the value editor program where specific signals are in memory. These are the files we create while reverse engineering the ECU software in order to be able to have something to modify
ROM - Term typically used to describe the software that is read from the ECU or written to the ECU. This is software that Mazda created to run the engine in our cars. It can also be called the "binaries", "tune", "calibration", "software".
RX8Man - Program for reading and writing flash memory (ROMs) on the S1 RX-8 Controllers. Can be found here: https://github.com/Rx8Man/Rx8Man/releases
RomRaider - Open source editor and logging program that has been used for years for various ECU modification. This is the program that intakes the ECU definitions, and alongside a ROM to be edited. You can find more information on the RomRaider forums here: https://www.romraider.com/forum/
ECU ID - Identifier baked into the ECU software that tells us what version/contents exist inside that specific released software/hardware from Mazda

What is the purpose for an open source ECU tuning solution?
Open source tuning is made to be highly accessible, constantly updating and change, and free from any sort of regulation. My opinion has always been: You bought the software, go play with it. While that is a bit more philosophic, the fact of the matter is that open source tuning is just made to use already existing hardware, to accomplish the goals of the user to when modifications are done to an engine, to suit a race car better, or just to play around and learn.

Does this cost anything?
No, however you will need some hardware to accomplish anything. You will need a J2534 device (Tactrix 2.0 is the most supported device, I would very much recommend it), a small (Windows) computer, and the desire to play.

What ECUs does this apply to?
This info applies to all 04-09 (03-08 globally) S1 RX-8 ECUs. Most of the effort I have made has gone into the USDM 6 port ECU, though there are definitions for some other ECUs, as well as MANY similarities in the other ECU software's that would make creating definitions for your desired variant fairly easy to make.

What does this allow me to do?
At a high level? Anything! At a practical level, this software set will allow you to modify the ECU tables for things such as: Ignition timing, fuel injection, oil injection, knock control, DSC control, check engine lights, variables for supporting new fuel injectors and new coil pack, etc etc. It's anything and everything you'd want to change. There are also a few patches for disabling the immobilizer, adding fast RAM logging, and whatever else comes in the future

Is this legit? How do you know what these table are?
Yes! RomRaider has been being used in various car communities (predominantly the Subaru community) for almost 20 years, and the tables have been reverse engineered by using a decompiling software to back calculate the ECU logic. More info in a post called "Reverse Engineering the ECU"

Limitations
This is not a full and polished suite to be able to be used without some level of curiosity. The defs are still a bit of a mess, and units definitions are still not fully put into the current definitions. If you have questions, feel free to respond or PM myself. The definitions that do exist, and are well defined are typically known as good and proper, but you should always understand that there is no gaurentee what you are modifying will change what you believe it to change. They will constantly be updated as time goes on when more information is understood. I am happy to answer questions via replies to this post, or via PM!

What this guide is NOT
This guide is NOT a guide in HOW to tune/calibrate your car. This is simply a guide in how the software works, and how to get setup to be ABLE to tune your car.

Supported ROMs (This list is NOT all inclusive)

60E0G500

• NZ3HEC 2004 EU 6 Port MT
• N3ZGEC 2004 EU 4 Port MT

60E0FB00

• N3Z2ET 2004 US 6 Port MT

60E0FC00

• N3Z2EU 2004 US 6 Port MT

60E1A300

• N3K1ES 2005 JDM 4 Port MT

60E1A500

• N3K1EU 2004 JDM 4 Port
• N3H3EV 2004 JDM 6 Port

60E1B900

• N3ZBEH 6 Port US MT

60E1D300

• N3J1EL 6 Port MT

60E1D400

• N3J1EM 6 Port MT

Alright, let's get into it:

Getting and Using RomRaider ECU Editor

To get started, first download the latest RomRaider release the RomRaider forums. As of writing, that can be found here: https://www.romraider.com/forum/view...hp?f=2&t=20940

You will also need a 32bit Java install in order to use all of the features of RomRaider, which can be found using your internet search tool of choice.

Once that is installed, you will need the RX-8 specific ECU definitions. I keep a running repository on github, and they can be downloaded here: https://github.com/equinox311/RX8Defs
You will only need to care about the XML files in the RomRaider folder. In that folder there is a file called "rx8_defs.xml" and "logger_rx8_defs.xml". These are the definitions files we will need to use in order to be able to modify the RX-8 ECU.

rx8_defs.xml - This is the ECU defs for editing the RX-8 ECUs, we will point RomRaider ECU editor to this file once it is open.
logger_rx8_defs.xml - This is the logger defs for describing logging variables to RomRaider logger. More on this in a bit.

Once you are able to boot the program up, and have the definitions downloaded we will point the program to that file. On the top menu bar click on "Definitions" and then "Definitions Manager". It will bring up a window.
Next, you will click on "Add ..." and browse for the rx8_defs.xml file you downloaded. If selected properly, it should something look like this:


https://cimg8.ibsrv.net/gimg/www.rx8...bb7801f7f7.png

Now we just need an ECU ROM to open, and we can start this journey.

The simplest way to get a ROM is to download a stock ROM that has been uploaded. I have provided the few that I and other members of the community have provided here: https://github.com/equinox311/Mazda_...ter/Stock_ROMs

If you download the file named "60E0FC00.bin", this is the ROM from the USDM 6 port ECU that will have the most support for it currently.

Alternatively, if you have the ability to download the ROM from your ECU (read: If you have a Tactrix cable and a car handy), you can boot up RX8Man and download your ECUs ROM. More on that under the section "Reading and Writing a ROM"

To load up any ROM, it's as easy as hitting the blue Folder icon in the top left, or using the top menu by clicking: File>Open Image ...

From there select your ROM, and let it load.

If your ROM does not load due to this Error, that means there are no currently created ECU defs for that EDU ID. Feel free to post in this thread if your ROM is not supported, it would be great to be able to get more ROMs to be able to define!


https://cimg1.ibsrv.net/gimg/www.rx8...ba5dd38249.png

If you get any sort of warning like this, do not worry, and just click "OK". It effects nothing, and I just need to modify a few things to get those to go away.. sorry!

https://cimg1.ibsrv.net/gimg/www.rx8...6353340d9e.png

Once the ROM successfully opens, you should see a menu list on the left side similar to this:

https://cimg4.ibsrv.net/gimg/www.rx8...a45e1430dc.png

Congrats, you can now play with and edit the software on your ECU! Select tables by opening the folder, and clicking on something that perks your interest. To save the files, it's as simple as modifying the value and then saving as a ROM file. You can then upload this modified ROM to your ECU!


https://cimg5.ibsrv.net/gimg/www.rx8...b3f32b8058.png



Reading and Writing a ROM

There are a few different way to write a ROM to the controller. The first and simplest way is to flash via CAN with a J2534 device, in this case a Tactrix cable. The other way is via the Renesas processor's BOOT mode. I will go into that later.

NOTE: This program is extremely basic. It only looks to see if your ROM is the correct size, and nothing else. You can VERY easily flash incompatible software on your ECU and brick it. Use carefully and ask questions!

If you are just trying to get your stock ROM from your ECU, or your are trying to write a modified ROM, you will need to use the RX8Man program, and a Tactrix cable.

First start by opening the program, it should look something similar to this. It may differ depending on your Windows install.


https://cimg4.ibsrv.net/gimg/www.rx8...c7aea3f422.png

On the top menu bar click "Vehicle>Mazda RX-8 S1 (2002-2008)

Next click on "ECU" and depending on what you'd like to do, select that Menu option. I'd highly suggest before doing anything, seeing if RX8Man can identify the ECU. This just helps you figure out if your Tactrix is connected and talking correctly.

From there, either click on "Read engine control unit" or "Write engine control unit" and the subsequent action will occur.

If you have read the ECU, RX8Man will tell you were it put that file, and the name of the file. This file can be used in RomRaider to modify!

Boot Mode

Let's say you have reflashed your ECU, and now your car won't start. Oh boy. Not great... but don't worry! BOOT mode is here to save the day. This is basically identical the Subaru shboot mode, though with a different pinnout.

First things first, you'll need some software. The Renesas Flash Development Toolkit is what we need in order to talk to the CPU properly. You can download it here: https://www.renesas.com/en/software-...dy5_Vc0Eez2wPN

The software is free, but you will need to make an account to download it.

Next, you'll need a USB to serial adapter. Any type will do as long as you have an RX and TX output. I like to use these:
Now we need to do a little soldering and circuit building.

You will need to build a small circuit, or buy a device that can do a ~150Hz 50% DC square wave to continue to satisfy the MCUs watchdog timer. If it doesn't get this signal, the MCU will continue to command a reset in order to try to save itself from staying dead. There are good circuits online for 555 timer ICs, or you can just get this handy gadget for cheap:

Now, near the backside of the RX8 ECU there is a 13 pin arrangement labeled CN400. Connecting to these pins will allow us to set the module up on a power up to be in BOOT mode ready to accept commands.


https://cimg5.ibsrv.net/gimg/www.rx8...a860b76bb3.jpg


https://cimg2.ibsrv.net/gimg/www.rx8...71dd6ea925.jpg

The pinnout is as such:

Pin 3 - WDT - Watchdog timer - 5V 150Hz 50% DC Square wave signal
Pin 5 - FWE - Flash Write Enable - Needs to be set to 5V through a pull up resistor (1k-10k is probably fine), this tells the MCU that it is ready to accept a flash write
Pin 7 - MD1 - Mode Select 1 - Needs to be get to ground through a pull down resistor (1k-10k is probably fine), this is one of 3 mode select pins (the other 2 are already wired correctly) to put the MCU into BOOT mode on power up
Pin 8 - TX - Module transmit - Connect to the RX pin on the USB to serial device, a 1k inline resistor should be used, but in my experience isn't necessarily required. Mileage may vary.
Pin 9 - RX - Module receive - Connect to the TX pin on the USB to serial device, a 1k inline resistor should be used, but in my experience isn't necessarily required. Mileage may vary.

You can solder on directly to the through holes, or on the backside, there are some pads to affix wires or whatever you'd like to:

https://cimg5.ibsrv.net/gimg/www.rx8...b37c09fa55.png

Here is a schematic as well:


https://cimg4.ibsrv.net/gimg/www.rx8...f6954412ab.png


Once you have your circuit wired up. power up the module (Use the RX-8 wiring diagram for battery power, ignition power, and ground on the ECU main connectors) and boot up The Renesas Flash Development Toolkit and create a new Workspace.

A window should pop up that says something similar to "Choose Device and Kernel"

Search for "7055" and select the flash kernel as such:

https://cimg7.ibsrv.net/gimg/www.rx8...fd951bc256.png

Hit "Next" and it should bring you to a window asking to point the program to the USB to serial device. Select the appropriate COM port for the device you have.

If you don't know which it is, unplug it, hit next, then hit back, and whichever COM port no longer appears is the one you need to select. Plug the device back in, hit next, then hit back again and select the proper port. Hit next.


https://cimg8.ibsrv.net/gimg/www.rx8...0b11da5c70.png

Use the default settings for the next 3 windows:


https://cimg6.ibsrv.net/gimg/www.rx8...1c8076ea55.png

https://cimg1.ibsrv.net/gimg/www.rx8...e7ff89de7e.png

https://cimg3.ibsrv.net/gimg/www.rx8...17682bf7a4.png

And then hit finish.

On the left, in the main project screen, right click on whatever you named your project, and hit "Add Files..."


https://cimg7.ibsrv.net/gimg/www.rx8...d7b7416a8e.png

Here, you will add in the ROM you are trying to flash to the MCU. Select the file you'd like, and then right click on it and click "Open"


https://cimg0.ibsrv.net/gimg/www.rx8...6b8d7f221a.png

You are now ready to connect to the device and flash the file. On the top bar click on the icon called FTD Connect. This will attempt to connect to your MCU and flash in the reflash kernel we selected earlier.

https://cimg6.ibsrv.net/gimg/www.rx8...be713c4b54.png

If you are successful at connecting, in the log window it should show something similar to this:

https://cimg1.ibsrv.net/gimg/www.rx8...d682ace547.png

Next, you're going to right click on your file and click on "Download File"

https://cimg5.ibsrv.net/gimg/www.rx8...2c910577ad.png

If that goes well, you should see your file being uploaded to the MCU similar to this:

https://cimg1.ibsrv.net/gimg/www.rx8...28e9726c1f.png

If FTD fails to connect to the ECU with the following error:

This means your ECU is a HD64F7055S (a revised 7055F) and you need to select the "Generic boot method" during project configuration

https://cimg0.ibsrv.net/gimg/www.rx8...ab4cbcb7a8.png


The write will take some time, and you can also select in other settings to do a verify afterwards.

Once it's completed, you can disconnect all of your circuitry, and use your ECU like you would normally!

Logging Using RomRaider Logger

NOTE: THIS IS EXPERIMENTAL ONLY, FEATURES BARELY WORK RIGHT NOW GUIDE WILL BE UPDATED AS TIME GOES ON

To be able to log the RX-8 ECU using RomRaider logger, we have to go through a couple awkward steps similar to the post above, but a bit more nuanced.

First, we need to download a custom version of RomRaider that I specifically compiled for RX-8 Logging. I have hosted the Windows version here https://github.com/equinox311/RX8Defs, filename: RomRaider1.0.0JAN112025-windows.zip

I will post my source code once I am able to sort of repositories a bit better.

You can install this version over top of the official RomRaider release, or in a different folder to be used separately. I recommend the latter.

To open up the logger, we click on the top menu "Logger>Launch Logger". This will bring up another window that will look similar to this:


https://cimg8.ibsrv.net/gimg/www.rx8...063e268b0c.png

Before we can log, we need to point the program to our logging defs and described in the post above. To do this click on "Settings>Logger Definition Location" and browse to where you downloaded the "logger_rx8_defs.xml" file.

Once that is loaded, we need to set the protocol properly to tell the program what type of vehicle it's logging. To do this, on the menu click "Settings>Select Logging Protocol Options". A window will pop up, and it should look like this:

https://cimg3.ibsrv.net/gimg/www.rx8...cdb5752bb2.png
Under "Mazda" click on CAN bus, and then "Select" or hit enter.

Once set, it's as easy as plugging in your J2534 cable (Tactrix), selecting the variable you want to log, and then hitting the green arrows to go online (my values are all basically nothing, because my test ECU is sitting on a bench not connected to a car)


https://cimg5.ibsrv.net/gimg/www.rx8...24a6b9d324.png


To take a log, click on the "Start Log File" button, and it will create a .csv log of the selected variables until you tell it to stop. You can define the output file location in the menu settings.

For any more info on this, checkout the RomRaider forums: https://www.romraider.com/forum/index.php

Reverse Engineering the ECU

If you're wondering how any of this information came to be, this post is for you. I will go into a high level on how these tables and ECU logic is found and unerstood. For any more deep analysis into reverse engineering, I suggest doing a bit more of your own research as this topic can get technical extremely quickly.

Useful Files and Programs
Ghidra - Open source and free to use decompiler and reverse engineering tool provided by the NSA. Download and user guide can be found here - https://ghidra-sre.org/
USDM 6 Port ECU Decompilation Ghidra Archive - This is essentially an upload of all of my personal effort to reverse engineer the USDM 6 port ROM. Easiest way to get into seeing the ECU logic. I will constantly be updating this file, and can be found here: https://github.com/equinox311/Mazda_...hidra_Archives

There is a ton of information on the RomRaider and OpenECU forums about how to load up a ROM into a decompiling program of your choice, so I won't get into that in this post. Quite frankly, if you're just looking to get your feet wet, the easiest way is to just open up the archive above.

If you are looking to start reverse engineering a different ROM other than the USDM 6 port ROM, the key things you need to know to get a Ghidra instance going is this:

Microcontroller - Renesas SH7055
Instruction Set - SH-2A

With Ghidra open and ready to rock, you can see the decompiled Opcode, and recompiled (best guess at least) C code. In the screenshot below, you can see some logic I have already labeled about the Leading Timing Base calculations.This is essentially how this logic is understood and figured out.


https://cimg7.ibsrv.net/gimg/www.rx8...c8a165c213.png


A typical non understood section of code looks like this, and through working back logic, working back I/O of the module, and assuming some stuff, we can figure out the way the ECU operates in order to define the tables in the ECU defs.


https://cimg3.ibsrv.net/gimg/www.rx8...2728d95863.png

This is a super basic and shitty explanation of this, but I can add more information on how to get working on this if there is interest.

ECU Strategy

The point of this post is for me to try to spell out how some of the systems work in the ECU. This will be updated as time goes on, and more information is had.

Should also note, that just because the info isn't in this post/thread doesn't mean the logic isn't understood.. it just means I haven't had some time to spell it out.

Ignition Strategy

In the ECU there is 3 types of timing categories, Leading Ignition Timing, Trailing Ignition Timing, and Timing tables/values that apply to both leading and trailing. For the most part, both leading and trailing timing strategies are the same, and just make use of separate tables to drive each coil as needed, so I will only describe the timing strategy in terms of "ignition timing" and not Leading or Trailing when the logic is common.

I've tried to breakdown the timing strategy into smaller subcategories that describe individual aspects that go into creating the final timing value that is sent out to the coil driving software bit. Within these subcatagories, there is also multiple sets of logic driving each, which breaks down as such:

• Base Timing
  • Idle Base Timing
  • Main Base Timing
• Timing Compensations
  • Coolant Temperature Compensation
  • Intake Temperature Compensation
• Idle Speed Compensation
• Cranking Angle Timing
• Knock Retard
• DSC Timing Derates

The end result the timing value sent to coil driver is:Breaking those components down below.

Base Timing
Timing CompensationsIdle Speed CompensationCranking Angle Timing Knock RetardDSC Timing Derates
Fuel Strategy - Open Loop

For open loop fueling, there are quite a few different tables, though we mostly only care about a couple. The other tables are typically for diagnostics, or sensor faulted conditions. I have spent a little bit of time to try to understand, and define them, but most of the effort lies within the tables that would be used during normal operation.

Open Loop Fueling breaks down into these subcatagories:

• Normal Open Loop Fueling
• Safe Mode Open Loop Fueling
• Implausible Coolant Temperature Sensor Fueling
• Cat Warmup Fueling **NOTE: This is more or less the same thing as cold enrichment, but it seems to deal with a catalyst temperature model, thus the naming

There is quite a bit more involved in this, but I am still working on getting these figured out, so these are the categories I can explain with confidence.

It's important to note, that all of these values described below are in units of Lambda, and are in the tables in the form of the decimal part of Lamda. Due to ECU logic, these values get some math done to them for computational efficiency, where they essentially get a value of 1 added to them at the very end of the math chain to calculate a fuel volume. To make life easier, I've subtracted 1 from each of the tables just so that it's easier to understand and to tune. More on this discussion will be added in during fueling compensations, but I figured I'd put that information in there, because it did confuse me for a while.

Normal Open Loop FuelingSafemode Open Loop FuelingImplausible Coolant Temperature Sensor FuelingCat Warmup Fueling

Thanks for sharing.
To add my inputs so far. For me, the bin files on GitHub didn't work with Rodraider.
After balming the issue on the version of Java I had ( I did try the bin files and Rodraider over 6 PC and my laptop, none of which work)
Did read my own ROM file, and suddenly, the Rodraider started to work. I have those errors on loading that.
I had to put back Versatuner to "stock" as the RX* man file was unable to read ROM.
https://drive.google.com/file/d/1MNT...usp=drive_link
Unfortunately, my car had a mini-map by a local rotary specialist with Mazdaedit; hence, I put stock in quotation marks.




https://cimg7.ibsrv.net/gimg/www.rx8...282cae4d3d.png

FYI, I've noticed some 32 bit java installed fail to populate 1D tables in the defs... I'd advice people to try out the 64 bit experimental build of RomRaider if they are having these issues.

Updated main post to show how to use the Renesas BOOT mode for reflashing a controller!

hello equinox.
I have several questions about several items written.

1. Can the boot mode be used for reading the rom as well as writing it or only for writing it ? - I don't own a Tactrix OP2 ( I have serial com, mongoose, obd link sx, and would like to avoid hoarding more tools)
2. Can RX8Man used with other tools than Tactrix. Are you the man behind it ? I would be happy to support financially the expansion to other universal ones.
3. Could we mod a Versa or ME tune reading it with rx8man or boot mode, or that doesn't provide any value in practice ? asking because of "flat shift" function from VT for example.

RX8Man software only has default Mazda security key and epifan / mazdaEdit security key, but not the VersaTuner one. I have this key if it would be useful, but it would need to be added to RX8Man software (or the binary patched so it tried this key instead of one of the other two hard-coded keys).

This is amazing work! Thank you for sharing!

I too am curious if RX8Man works with ELM327 cables instead of J2534, as that is what I'm working with now. My plan would be to try tomorrow and report back.

It also sounds like I may be able to use ROM Raider to make small changes to the ROM and see if I can't figure out how the ROM checksumming works, since it apparently fixes that up for you (or we wouldn't be able to flash it successfully and have the car run).

@Rot13 would be great if you could share the key... I cant even test it on my car as I have VT on it at the moment.. would like OS for mods like @ciprianrx8 provided for full time closed loop. If nothing else I can return the car to stock and continue tuning using RomRaider... (would probably be much smarter)
Would assume boot mode is a good solution / alternative for tactrix, it should be able to read it (I would assume at least based on working with other ECU's using K-tag for example).

I have the mongoose (versa tune ver 3 HW) which is also a J2534 device.
need to try to connect to the car and see what works or not.

1. No, boot mode has flash protection, so it will do an erase before you are able to read any flash memory. This method should really only be used to recover a module that the bootloader cannot handle. If you already have files from your module though, there's no reason why you cannot flash it this way.
2. Not entirely sure if the program is specifically grabbing a tactrix driver, or just any J2534 device. I don't have another J2534 device to check. I am also not the one who created the program/kernel, and the person who did would like to keep everything closed source. There is a link where you can support the creator financially both in his repo, and mine.. however I don't know if that will translate to feature adds.
3. I have no intentions of discussing ways to use other for-profit company's methods for free. If you find those features useful for your application, you should be more than happy to compensate those entities for that feature. That is all I will say on this matter.

The module doesn't REALLY use checksums from what I can tell. Also, that is handled entirely by RX8man, so I've also never had to deal with any checksumming issue.

Like I mentioned above, I have no intentions of turning this into a discussion about other for profit company's methods, or ways around them. On that note though, I do have a build environment setup for a specific ROM and I have a FlexFuel patch that is operational. I'll have more info on this in a different post as it's a bit different of a topic.

Patches for various features are definitely something that is possible, and I will be doing. I do have an immobilizer delete patch, and a few other things too. Nothing for release publicly yet as you can do more harm than good without understanding what is being changed.

My intention is not to steel anything, but rather expand on it. Ie I have a license for personal and I also have their pro license, and the tool. All is paid for fully so I would like to combine that with other items such as ones mentioned here.
Flex suel sounds awesome as well :) (sadly can utilise it as no high e fuel over here..
Good to know for boot mode / reading.. on other ECUs that is the only way to read full memory/rom and create a full backup.. Other devices read only partially.

Understood, but by asking for keys, dumping software, and trying to use their components, you are incentivizing that for others. So I just want to be clear that this entire open source toolset is made to be used separately from anyone else's products.

Since it sounds like sharing the key may be frowned upon here I'll refrain from doing so, but I'll mention that the RX8Man software already has the mazdaEdit key built-in, so allowing users to dump that but not other third party ROMs doesn't seem entirely consistent. I figured since mazdaEdit key was supported, likely reason for not included VersaTuner in RX8Man was not having that key, since it doesn't seem philosophical at that point.

For users like motodenta and MilosB who have apparently purchased mazdaEdit or VersaTuner, allowing them to work on top of mazaEdit tunes but not VersaTuner tunes seems arbitrary if the idea is to distribute knowledge and give us useful tools.

That being said, I'll respect the decisions being made with other peoples software.

On the checksum, you can see some other discussions at https://www.rx8club.com/series-i-aft...ing-ecu-81801/ , but I wasn't able to find the same bit patterns they mention in the ROMs I looked at (including the Stock ROMs folder on github).

Calculating checksums over the whole file (the post mentions skipping a header) in the most straightforward way results in different checksums for all the files which isn't what I would expect if the algorithm was correct.

RX8Man definitely doesn't support ELM327. There is nothing anywhere suggesting it did, I just kind of hoped against hope that it had support (magically). RX8Man does use the Tactrix openport driver, op20pt32.dll, so I'm not sure other J2534 devices are supported either, unless they use that same driver.

I really like this project to develop open source patches that can be mixed and matched, and I'd be especially interested in how interesting entrypoints are discovered and repurposed (e.g. CAN message handlers as in the Flex fuel example).

I'm also working on resurrecting the ELM327 ROM dumping code I had, and hope to release that soon as well.

would it make sense to use a different J2534 device and just rename the driver ?

I can't totally speak for mazdaEdit because I have not used it, but I do know that Versatuner does NOT allow you to do any sort of modification outside of their provided interfaces for modifying the flashable file. So going down that route regardless is not worth it. You will not be able to use anything on top of that.

Entrypoints are discovered just by reverse engineering the software. I have my files hosted as a good starting reference for anyone looking to port things to their ECU ID.

In theory, this should work. I've done this with various service tools requiring proprietary interface devices.

yeah, there is no real point in using Versa besides romraider.. ..
Do you have direct contact with RX8man ? could you ask him for additional device support ? since he keeps it closed source :) I rather support that financially than buying another device, so we have more devices compatible, than just one... (Mongoose plus ISO can3) :D
if not ill have to order one, but that will take some time.. its like they use pidgeons to carry mail over here.

Just trying to understand here. Are you saying the VersaTuner license does not allow modification outside of VersaTuner or that there is some technological limitation which would prevent it from being used with ROM Raider (assuming the correct definitions were also created)?

If there are technological limitations, I'd be curious to understand how those would work, since after all once you have the ROM you can change any of the functionality at all, including, presumably, whatever technological limitation was imposed.

On a personal level, I believe people should be able to tinker with things they buy, and in some places, they are actually guaranteed a right to repair which would override any other restrictions provided via license agreements.
Again, just the same, I don't want to discourage the work going on here, so I'm happy to abide, but I would like to understand the parameters we are attempting to work under since as I mentioned before it didn't seem entirely consistent.

There is no point on maintaining use of VT as you cant edit anything outside of what they predefine. Ie you cant define your own tables on there even with a pro license
So only benefit of reading a versa rom would be to keep the modification implemented for the flat shift and thats it.
VT won't even allow you to edit all of the DTC (you can only disable MIL, not the detection) for example.

Another very interesting item to use would be RAM memory. if Im not mistaken, COBB was able to use ram for "live tuning".
we would "only" need to have ignition timing there and/or AFR. I dont believe much more is needed to be adjusted "live".

I think this is kind of the problem I'm discussing, but I may be misunderstanding. You can't do any of that in their native interface, but there is no reason to believe you can't modify those things directly, by modifying the ROM directly and re-flashing it.
A similar issue might be someone that gets a car second hand and has a third party ROM on it. Without support from some tool to dump and write flash that had security keys for that third party ROM, it isn't clear how they would return to stock (Ford/Mazda WBS/GDS, RX8Man, and other similar tool all require getting security word access to flash from my understanding, which is why the RX8Man software carries the default "MazdA" security key in addition to the one for mazdaEdit).

It's okay if we would rather not have that discussion here though. I didn't see it disallowed in the forum rules, and there seemed like there might be other material subject to copyright or other problems in some jurisdictions already on the forums under the spirit of knowledge sharing, so I'm genuinely trying to understand what is desirable and acceptable. (e.g. Confirming whether using the tool as-is for the dumping and loading mazdaEdit tunes via RX8Man would be okay but others might not be, or it would be preferred if none are). Given that I'm hoping to release at least a dumping tool for ELM327 users, this is particularly relevant.

I think you can overwrite any ecu file, you just cant read it. I might be wrong on this..
Yes, that would be my argument pro use of any ecu..
I purchased the tune for the car or as you say I purchased a car with the tune already done.. if I want to continue to use it, i dont need to be obliged to use the same as someone else did before me..
When i tune for others as service I never lock my tunes.. they can open tem and do what ever they would like.. I even explain all the changes done and reasoning...
They paid for it, not for some locked file that noone can use..

I thought that was only in BOOT mode that had the flash protection in the write. So yes, you can flash it, but you need to bench the ECU which doesn't sound like a whole lot of fun (if this isn't something you otherwise want to do).

When I said you can't read/write the flash, I meant via an OBD-II cable (ELM32 or J2534 via UDS or XCP) but I should have specified. I also might be wrong on this, in that I know how it might be done via security access (which requires the pre-shared key to use with the seed given by the algorithm to craft the response), but it might also be possible to do in other ways.

I will once again say this is not a thread to discuss ways to use other company's tuning solutions, nor ways to crack into them.

This is all I will say on this matter to answer questions and hopefully stop the conversation:

Versatuner uses encrypted binary files for use with their modification tool, and uploads them to the module using the standard bootloader. The only thing they change in the flashing interaction is the secret key to unlock the module for a reflash, which I believe is hashed based on the license you are given via Versatuner. I have cracked the Versatuner seceret word (you can too, it's not difficult), for at least one license, and uploaded a Versatuner ROM via UDS. The only time you will ever see the compiled binary in it's unencrypted forum is during download to the module.

None if this information will ever be shared publicly by me, and there is no benefit in having this information given the vast availability to information, patching, and uploading/downloading a program given the information I have provided for use (for free, mind you).

If you want to make a patch for a ROM, I have uploaded my current Flex Fuel patching environment that anyone is welcome to poke at: https://github.com/equinox311/RX8_FlexFuel

If you have any questions on that, I am happy to answer, but I really don't wish for this to turn into anymore discussion about using other people's paid services for a use case they were not made to be used for.

As far as being able to return an ECM to stock, you can use the vendor's tool to return the ECU to stock, and you will be able to use it just as you would have before, and then use the open source tooling. If you don't have access to the vendor's software due to buying a secondhand ECM, BOOT mode works just fine and I am hoping to gather a full collection of OEM ROMs in order to assist anyone hoping to start with a known factory starting point.