RomRaider

For those of you that have hacked your own low level additions to the ECU, what routes did you take to recover from mistakes and dead ECUs?

From what I understand there are 2 routes:

1) ECUFlash and special Renesas boot mode using a hacked up USB-Serial cable with a FTDI chip.
-> http://www.openecu.org/index.php?title=SHBootMode

2) Simple JTAG cable and either custom software or other software I haven't found yet. Such examples exist in the openwrt world for hacked routers. This route is preferred as it should carry over to other ECUs (EVO).
-> http://wiki.openwrt.org/OpenWrtDocs/Cus ... JTAG_Cable

Those that have the knowledge or have personally done something along the lines of JTAG hard flashing please provide some insight? I'd like to detail a known working and acceptable route for those that get into ECU hacking to take when they (me) brick an ECU.

Paying ~$80 per incident to tactrix is not acceptable.

You aren't going to "brick" your ECU unless you overwrite specific routines in the ROM which would be a pretty bone-headed mistake and something that is easy to determine before you flash.

Doesn't mean it can't happen. I feel ECU hacking is held back partly because of fear, the fear of not being able to recover from a mistake.

Have you ever gone one of these routes?

Also, "brick", should I call it by a more accepted term?

None would apply to my 02 WRX. I don't think ECU hacking is held back from fear. It is held back because few really know what they are doing. I would worry more about the results of hack than bricking the ECU.

Thats your opinion. Surely you can still see value in a well laid out hard flashing thread.

Unless you have hard flashed your ECU, back on topic please. I'm looking to compile specific info here.

For someone with disassembly experience, it shouldn't be much of an issue. However, I think having information about this stuff can only help things.

Regarding the effects of hacks, an understanding of the instruction set and binary/hex storage formats should do just fine. However, it would be great if there was some more info about debugging code or running the code on a virtual CPU.

I know freon and I have made cables. I'm still having issues getting mine to work though.

I used a dlp-232 as per the OpenECU schematic, and then tried flashing with ECUflash's shbootmode flash procedure. Seems like I might have an issue with the watchdog signal, so I need to hook it up to an oscilliscope to check it all out.

I agree that someone with asm experience should generally be ok, but I like an out if the worst case happens.

A virtual CPU would be pretty cool I'm sure there is something out there.

As far as the FTDI DLP232 part, best I could find was this:
http://www.dlpdesign.com/usb/232PC.shtml

Is there a place to buy just the chip?

I sourced the LM555CM part: Any other more reputable IC stores?
http://www.newark.com/jsp/search/produc ... B100000001

Also, would you be willing to take a picture of your setup, even though you're having issues? I'm very visual.

The real problem is it is easy to corrupt the stack or screw up a jump to the wrong address. I've done this twice. :[ If you're careful, no problem, but when you're cycling revisions of your software and reassembling and rebuilding your ROM you're eventually going to forget to dot an "i" or cross a "t" and then the ECU is bricked. I adjusted my process and actually disassemble a majority of the modified ROM after I've pasted my code in to make sure it still flows through the routine correctly. When you've got another copy already disassembly it is pretty easy to go to the start of the core process loops and press "C".

I have my own process worked out for revising and reassembling code. Lots of things can go wrong so I do a lot of validation at each step. This is one of the main challenges I have in finding time to work on ASM stuff. I really have to sit down for several hours straight to really get anything accomplished. I can get exponentially more done in a 4 hour period vs. 1 hour. It also makes larger projects like RAM tune, per gear WG, etc. more difficult because they require hijacking longer subroutines. MAF wasn't even that hard because it is a short subroutine and doesn't even utilize its own memory stack, everything stays within available registers.

The KPIT Cummins toolchain download is free and I think it includes an SH CPU simulator. It is basically the Renesas HEW/IDE, but they compile the release and support it rather than Renesas (you can't download Renesas's piece directly). I never really messed with it. I purely use the ASM command line functions to assemble my ASM files into machine code. I do not have any real issues with keeping my registers and such straight. It is integrating the code into the existing base that causes issues and is easy to screw up.

I'm sure there are better ways to do it than I'm doing.

Try Digi-Key.

I bought an FTDI USB prefab board from Mouser.com. It has a 232-whatever chip (232-RL I think? it's one on the compatible list), clocking crystal, and some of the other baseboard components needed in a nice ready-to-plug package, soldered up my wires, etc.

You can get LM555 chips at Radioshack for like $2-3. Most are interchangeable for our purposes. STM, Motorola, etc. probably doesn't matter much, but you might want to check the spec sheet.

Mouser is another great store. I'm working with a DLP-USB232M-G and a Texas Instruments NE555P

+1 on corrupting the stack... I forgot to cross a t and bam.. brick. In hindsight it seems like something that shouldn't happen, but when you've been chipping away at the ecu logic for hours upon hours, it's a little different .

I'm prolly off with the fairies here, so sorry in advance, but wouldn't it be better to make/create an ecu emulator so you could all work offline and test any code/hacks in an emulated environment?

That way you don't need to try and flash anything to an actual ECU, but rather work with the emulator, which would (for all intents and purposes) appear to ECUFlash and RomRaider as an actual ECU (any ECU depending on what it is set too)?

Anyhoo, as I said, I'm prolly off with the fairies on this lol.

With a careful use of registers, you shouldn't have to mess with the stack in most cases.

I got a jump address wrong a while back when I was messing with LC/FFS with the 32-bit ECU. The tester was still able to flash the car (car wouldn't start obviously). I also introduced an infinite loop into one of my 16-bit ECU hacks when I first started messing with it but I was still able to flash (wouldn't start and no priming of the fuel pump).

But, from these mistakes, you learn early to triple check your work before you flash.

Freon, can you post which ecu pins you're using to supply the 12V, and how/if you're sharing a ground between the cable and ecu? Any pictures of your setup on the breadboard?

Well most subroutines hit the stack. Sure you may not need to touch it for your own code, but it is likely the subroutine you are rewriting pushes a value to the stack and then retrieves it before termination.

ECUs have different pinouts. You should check reference material from Subaru to find your power and ground pins.