How does initating a new flash work?
 

I'll admit that I haven't put in a lot of reading time yet but after watching videos like this where they make logging look really easy, I'm wondering why I can't take a similar home made setup to interface with the ODBII and modify it as a tuning device. Is there something inherently complicated about initiating the reflash? It seems like the available hardware has come a long way since people started tuning the RX8 and that It should be VERY cheap to accomplish this kind of tuning solution. I'm a open-souce linux guy so maybe I'm just being too optimistic with my lack of ODBII experience.

This exists already.
MazdaEdit + OpenPort

I am familiar with that combo of products. I'm talking even cheaper than that. What is the MazdaEdit software or OpenPort adapter doing to initiate the reflash? Why does there need to be a processor on the adapter if we can do everything cheaper on either a laptop or a micro computer like the Raspberry Pi. Integrating with a small computer could open up the possiblity of a very cheap tuning solution as well as other neat functionality like sending logs to your network computer/server automatically when it connects to wifi when you get home. You could also interface the Pi with your stereo and use it for music... which could be loaded via wifi.

What it comes down to is ODB "hacking" and I can't seem to find detailed info about sending a new map to the ECU. Is Mazda doing something in the ECU that is making it more difficult to use or have we just not had enough ODB nerds look at it? Have the people at COBB and MazdaEdit completely reverse engineered the hex data from a proprietary protocol or something?

Here is a list of ODB protocols in Mazda cars. Anyone familiar with this kind of stuff?

ECU Reflashing - DeepThoughts Engineering

The Mazda ECU file has a certificate of sorts that must be submitted before it will allow a ECU dump / upload.

Peeps like epifan (mazdaedit) and Cobb (accessTuner Race) figured out how to crack Mazda's code.

Trust me, its far easier to just pay the money for a copy of MEP and an open Port.

I already have an accessport so It's not about easy at this point. After the crappy driver/firmware support from cobb and there being only one other popular option(mazdaedit), I'm in it for the movement. I dunno, Maybe I'll lose interest in a week or two but I'm pretty confident that If I could figure out the certificate/CAN communication stuff somehow, I could throw together a linux solution for the rest. We're talking $10 dollars for a ODB-II adapter and free software to get reflashing capabilities. I could put together a Raspberry Pi Carputer with the bluetooth adapter for under $100.

I guess I'm a fan of the open-source business model where the product is free and you pay for support.

I'll add this:

It has absolutely nothing to do with OBD2. OBD2 is easy. Hell, even CANBUS is easy.

How about a Raspberry Pi running the as an ECU replacement on a Mazda flash???

A VM ECU to "flash" would then be possible, and if we could get the ability to run a virtual ECU on a live engine,"hot swapped" it would be awesome.

Then... a virtual-box laptop running your car and switching live control of the engine between virtual ECUs and the car ECU for different performance modes .

I will love to see this going somewhere as well as find a way to reprogram the TCM which I need right now for the High Performance AT I'm getting built for my 20B Rx-8. There is TCM software for a lot of cars around including Mazda 6 MPV but not for Rx-8 which is frustrating. Same with this ECU issues that the other brands have already resolve and had left us behind.

In the short term I think we just need to compile existing info about the RX8 ECU. Hell... Any ECU for that matter. What hardware and software is required to accomplish something like this? Is the Raspberry Pi even powerful enough? Does it have the right IO requirements?

I'd imagine if we could figure out the ECU, the TCM wouldn't be that hard to throw in. Do you have any info on what other people have done?

I imagine we could use portmon if under the covers the OpenPort presents itself to Windows as a COM port.

In doing so we could record a couple flash sessions through MEP and see the data going across the wire.

The AccessPORT likely does similarly.

In my MEP logs you see it:

1. Erase firmware
2. Request Challenge from ECU
3. Challenge ECU
4. Upload the new firmware in chunks

Good idea ShellDude. I'm going to try portmon and see what I can find.

Also, I found this thread to be somewhat informative: openecu.org ? View topic - RX8 Flash Protocol
Here is another one: http://www.romraider.com/forum/viewt...hp?f=25&t=6303

Down the rabbit hole I go!

nice to see oltmann active over at openecu.org

You might want to try sending him a PM... here or there. He knows his shit about our ECU.

Yeah, I've noticed that you and oltmann have been involved in most of the ecu/carputer type threads here, I really appreciate the content. I've been doing a lot of reading since I started this thread and to no surprise, I've mostly just continually grown my list of things I need to learn. I'm working on compiling a list of known ECU and CAN info for the RX8 and I'll probably edit the first post to contain info if this goes anywhere.

One really promising thing is that I've come across some projects that seem to imply that you can turn a micro-controller running linux into J2534 protocol compliant pass-through device which is what does the flashing. For example:

https://github.com/jeremyhahn/ecutoo...r/pass-through

This would replace the need to buy a pre-built device like the openport.

I'm not a C programmer yet but I'm going to look into it as much as possible. Unfortunately I have a lot of work to do before I'm familiar enough with any of these protocols to make something worthwhile.

Can anyone provide known protocols/electronics that we are dealing with on an RX8?

Flashing Passthrough: J2534
CAN: ?
ECU: Hitachi SuperH processor by Renesas
SH7055 "64F7055F40"

Yup it is built into Linux. That's how the CBT works.

Sorry, can you elaborate? Why are people paying for J2534 cables if they can just load linux on a laptop? Are we talking about the same thing?

Just because it is supported it doesn't mean anything is in place from an application stack to process it...

Look at it like basic serial port level support.

I'm aware of that. The point is that it's possible for a small cheap carputer to do flash tuning on top of whatever else you want it to do if an application is written for it accordingly.

Yup... Look here....

http://www.canb.us

Hmmm...

http://www.elecfreaks.com/estore/can-bus-shield.html

Yeah man, that looks pretty cool. With all of these devices that have become available in the last few years... I really think we're missing something.