RomRaider

After looking at the source of RomRaider and reading several specs it seems to me at least that RR is not too far from having its own flash utility? I mean right now RomRaider sends PassThru messages via OP2 (I see there is the RAW message format and then there is support for using the official J2534 interfaces) which presumably means one could use it to write to memory directly to upload a flashing program and then send messages to that program to do the dirty work of flashing the ROM MATs. I have SH7058 so according to RENESAS specs one can flash a program to RAM and then program an address for the ECU to start executing from.

I realize that RR is tied to ECUFlash for the grunt work but is there any interest in changing this? There are features that aren't in ECUFlash that I would like to see (namely programming the FKEY to lock out a map). But I'm just interested in the project because it sounds like a lot of fun.

The only thing I don't get right now is what development environment do you need for all of this? I can't use the ECU in my 08 since that's my DD. There is the KPIT tools I think that include a simulator - I have see if it simulates more than just the CPU but also any onboard perpherials like the HCAN controller.

Btw, I am assuming when SSM commands are sent via RR for logging, that's over CAN and this generates CAN interrupts?

Hope I am making some kind of sense....

There was THIS thread a while back about implementing a ramtune feature for RomRaider but it seems nothing is happening with it any more - maybe another dev who understands what is needed and has the time to implement it is all that is required

There is also THIS thread that is a dev startup guide and should get you on your way.

If you pull the whole source tree from the SVN repository (see the "Getting Started" link to the left), you'll find a text file, Building_RomRaider.txt. I collected some old information and tried to consolidate it, with a bit of explanation. As I look at it now, I see it's pretty sparse, but it should get you started with RR.

Your real question seems to be about developing the ability to write to the RAM, how to do so without bricking the ECU on your daily driver. That, I don't know. I haven't done any embedded systems development in a while, so am not of much help there.

I did a little refactoring of the source to make it simpler to add new tabs and windows, but haven't had time to add any of the new features _I_ want to see. If only the people who pay my salary were more accommodating of my hobbies ...

Thanks guys....

A couple of items:

- The Dev guide is great if you are just talking about RR which is sort of self explanatory. I have downloaded it perused some of it (especially the OP20 stuff since I was like, wait, its a DLL how are you invoking....then I learned about JInvoke which is the equivalent of dlsym(), dlopen(), etc. etc). Unfortunately as lizzardo points out its not really meant for embedded development.

- Would you guys be open to converting the project to an Apache Maven build system? I find it utterly annoying that if I'm building on one platform I have to pull down all of these binary jars. There is an Eclipse plug-in (actually two) that makes dependency tracking and project management much better than using a pure ANT style build. I'm more than willing to do this (I have two patches).

- About flashing:

Well....the way I understand the specs and I have read A LOT of specs in the last 2 weeks. The CANbus is a glorified serial bus with N nodes that also incorporates a simple priority based arbitration for packets on the bus (to deal with multiple nodes talking to each other since serial is typically p-to-p). The OP2 is a FTDI USB->serial chip that provides an API for you sent raw pkt data, i.e. to implement the passthru spec J2534 I think its called (I bought a copy).

SSM (Subaru Select Monitor) is a simple application protocol over CAN that provides logging. Right now as I understand it, RR uses JInvoke to send CANbus raw SSM pkts to the ECU to perform logging. I noticed that currently I think RR is formulating them manually instead of using the abstractions in J2534....I don't know why, perhaps there is an issue with OP20 implementation of it??

The J2534 mentions that there is a PassthruWriteMemory and ReadMemory. This would seem to me that I can read and write raw memory addresses so presumely I could write a small flat binary to run in RAM that waits for commands (maybe via a mailbox protocol) from RR to flash the MATs. The SH7058 guide has all the register definitions and workflow but I still some small questions that woudl be answered if I was able to do it in a clean environment.

So I have 08 but I can't flash it. I'm on a Cobb tune which is OK but I liked to move to RR. However, I also like to go SD since I'm above 400whp with a FMIC and I feel I will benefit from this then screwing around with MAF.

Anybody have any idea what test environment people use? I mean I suppose if I could find a used ECU and then figure out a way to apply voltage to it and then figure out a way to connect to it via OP20 I could start trying to develop something.

Thoughts on all ofthis?

you would be reinventing the wheel. We can already flash with Ecuflash, including the CAN models (ex. 08 and later Imprezas with the OP 2.0). Going through a process to figure that out with potential bugs along the way that could brick someone's ECU just so you can flash in RomRaider makes no sense. Colby of Ecuflash already offered a command-line version of Ecuflash so it could be added to RomRaider in the past. I think gabedude was looking into that at some point in time. That would be a much better option.

Well...Merchgod with all due respect do you not find it odd that RR is completely dependent on a non-open source flash utility that can GO AWAY any day now? You may think that's far fetched but I've seen it happen on many projects where at the time, it wasn't even thought of (there is reason why we have X11.org and 4 BSD variant OSes).

All I'm saying is wouldn't it be nice if RR was a complete suite of tools including a ROM flasher? I agree its not an easy task and I also agree that there will be bugs. But in the meantime folks can still use ECUFlash which is stable and currently free.

Moreover, why use RR when ECUflash does the samething and YOU provide the ECU defs for both?

I'm not trying to insult anyone I'm just trying to understand the perspective by your above comment. Btw I'm not knocking Colby or ECUflash as its a nice utility and he has put in a lot of work into it. However, to me its like GCC relying on a closed source RTLD to actually execute an ELF file. It makes absolutely no sense.

Well, that is a possibility. If that were to happen, then it would be necessary to develop flashing for RomRaider.

However, if you feel you have the knowledge and skills necessary to do it, then by all means, don't let me stop you.

Thanks. OK. I believe I have MOST of the skills needed minus familiarity with this embedded environment. So I suppose without buying an extra ECU to play with I'm pretty SOL or is there some kind of simulated environment for the SH7058 processor+peripherals....I just need to be able to boost strap and then potentially reset to factory (or reprogram a factory ROM).

My guess is I need a JTAG setup to access the in-core debugging features on the core. I got some more research to do...I never used JTAG before. If anyone knows of a kit or some kind of development/debug environment for the SH7058 (or family) of processors, please speak up?

Question, how do you inject code now Merchgod (and friends!)? I'm assuming you use limited table space to do some trickery (hackery) on table lookups? I mean the RAM tune thread suggests that you could make more use of the RAM area for real-time tune features? Just curious on the work flow, I'm still learning the tools and some of the code.

[I will be the first to admit sadly that I just RECEIVED my OP20 cable]

There are unused portions of the ROM. You insert a hook in the factory code to execute your own routine or you modify the existing code, depending on what you are trying to accomplish.

I'll take a look at Maven. I'm pretty satisfied with tools from the Apache Group. If you've got patches, I'll look at those too. Can you describe more of the benefits of incorporating Maven?

The reason that all jars are included is that the build automation is intended to produce the distribution, i.e. installers for all supported platforms. I've got eclipse set up using their Java Builder, and I allow that, plus the Run/Debug configurations, to handle everything when I'm developing.

- Dependency management

Right now the workflow for a developer who wants to use a third-party JAR is they have to download the jar into their build tree OR it comes with the source tree causing massive bloat (source revision is for source not binaries). Maven provides an automatic way to track dependencies and download them as needed (and cache them). The source tree would be a lot slimmer.

- Bundle management

You can have Maven do alot of the heavy lifting regarding creating bundles on a per platform basis (I see most of that is hand done in ANT which is fine but tedious when things change)

- Eclipse build and dependency management via plugin

The build instructions require the developer to manually add or at least configure the Eclipse project options to include the necessary JARs in the build CLASSPATH. All of this could be automatic.



Again, ideally it would be nice to bring only what you need....i.e. if I never build an installer why should have a copy of it in my Eclipse environment? Its side-artifacts that can confuse someone not in the know.

Just food for thought...I started to do it then I figured I would ask first...then submit patches...etc.

jmo, but I think resources would be much better spent on developing, or porting if possible, a ECUflash integrated logger and tweaking the existing editor. However, afaik, ECUflash isn't quite "open" as it seems.

It might upset some, but I would never trust a java program to flash my car.

It doesn't have to be Java but that really isn't the point (doesn't matter since flashing is just sending commands to write to address the following set of bits, whether its Java, Cobol, Scheme, ML of NJ, or C/C++ or even a combination of both doesn't really matter). As Merchgod said, I would advocate a CLI tool anyway that RR would just call directly after writing out the edited ROM image.

Man Renesas HAS so many tools I can't figure out which one is most appropriate, they have ICEs (usually really expensive), they have a development environment, and they EVEN have flash cable that allows you to play around with the existing flash protocol on the SH chip. Got to look at this some more...

Btw I apologize, I realized that this thread should be moved to RR Development not ECU analysis. Sorry.

I'm glad to see someone new looking at the source code and coming up with some ideas. Assuming you're serious I'd be happy to give you commit access to the repository to create a new branch and have a play with your ideas.

Maven is not my forte so if you or Steve want to look into it further and develop an alternative build system that's fine by me too. I like the dependency management of Maven, but am not yet totally convinced by its build system - feel free to convince me however!

Note that ALL new experimental work (especially any flashing related stuff!) needs to happen on a branch so as not to pollute the current head with test code - there's enough of that in there already...

Anyway, let me know if you're serious and I'll get you setup.

Ecuexplorer is released under GPL v2 (HERE). I realise that it is oldish code, but it incorporated an early version of ecuflash which could read and write to the ecu.

Just download the source for ecuexplorer and then go through the read and write code. It should all be there hopefully. It'll get you on your way and give you the code for something that can at least read and write to the ECU.

Then hopefully all you'd need to do is add it into RomRaider.

Just a thought