fostytou

iTrader: (15)

You need a seperate made cable to connect to the ACD ECU.. it can't be done through the OBDII port. You need to connect directly to the unit. There is another thread on here about it, but it has kind of died off.

lan_evo_mr9

iTrader: (10)

It's a shame it's died off too. That was one thing I was REALLY looking forward to. Oh well, can't have it all I suppose.

MR Turco

iTrader: (16)

I'd rather pay money for a cable than a single flash. Maybe someday people will get interested again.

logic

iTrader: (2)

Agreed.

FYI: pins 35 (orange) and 46 (light green) of the ACD controller's C-138 connector block (MU801823) are the serial interface for the ACD ECU, per my FSM. I haven't pulled it out of the car yet to physically inspect, but I suspect one might be able to permanently wire up a connection without too much trouble, perhaps just re-pinning those two wires?

I'm back to reading through a disassembly of the ROM sba posted in this thread, specifically reading through the SCI1 interrupts; I'm curious what the native comm protocol for this thing looks like. I think I'm finally starting to grok how SCI communication works on the ECU side.

H8's address space layout seems really wacky to me. Is 0x10000 through 0x14000 just logically shadowed/replicated at 0x0? Wtf.

Looking at the board, it looks like R5 is Vpp (apply 12V for programming at your own risk ); since I haven't looked at the physical ECU yet, I have no idea if this is exposed as a pin on the harness.

(I really need to stop spastically switching from interest to interest on this car; I never seem to actually get anything done. )

MattS00

http://geekmapped.com/forums/showthread.php?t=600

I hope this helps.

logic

iTrader: (2)

I'm a dork. Look a little farther down in the diagram (this is what I get for looking at this way past my bedtime), and you'll see that it's just wired straight up to the OBD-II port, just like the SRS and the vehicle ECUs. It's interesting, I hadn't gone through these wiring diagrams before; I didn't realize they were all just directly wired to the OBD-II port, and assumed something was mediating access. Cool. So communicating with it (at a basic logging level) shouldn't be too hard.

The FSM doesn't mention anything about a programming pin being exposed, unfortunately. Now that I know where the controller is mounted, hopefully I'll have a few minutes to pull it this weekend and physically inspect it.

I wonder: if we were able to wire up Vpp on the ACD ECU to the programming pin (the little white connector) from the OpenPort cable...would we at least be able to read images from the ACD ECU with an unmodified EcuFlash by telling it that it was a 2g DSM ECU (the serial wakeup sequence should be the same, and I'd expect a generic kernel to work properly)? Anyone know if the DSM guys are having any better luck writing flashes with OP2.0 (I seem to recall they weren't able to do it with the 1.3 cables due to a voltage problem)?

SmurfZilla

iTrader: (33)

I think its a little more complicated then just getting EVOSCAN to read thru a special cable. The reason I say this is because if you look on Gruppe-S's website they talk about them being one of VERY few aftermarket companies that has the ability to flash the ACD unit. I'm no where close to being as smart as you gentleman so I digress.

fostytou

iTrader: (15)

....and ECUTek is the only thing that can flash the X right now. $$$ and investment does wonderful things.

That being said, the only thing stopping us from being able to do it is ourselves. Good find on the OBDII wire-up logic. If you contact derekste he just totalled his car... he might be willing to lend you his unit (and has been wanting to meet up with you anyway I think).

derekste

iTrader: (9)

yep, my car is down for the count. shoot me a PM if you need anything, logic

MattS00

It should be as easy as pulling out the unit and checking for continuity between the vpp pin #19 and the exterior pins on the unit. You should be able to read the rom with openecu and the proper pins hooked up. There are not very many pins that need to be hooked up to flash the chip. I would be careful though. My OP2.0 cable applied 17.3 volts to the Vpp.

More here.
http://forums.openecu.org/viewtopic.php?f=55&t=4128

Right now the only H8 processor that can be flashed back to at the moment is the MH7202, but there seems to be some bug with it. I heard of a fix in ecuflash v1.42, but it is not out for general release. The MH7203 cannont be flashed back to at the moment. For some reason it fails to erase. H8 ECU based cars are late 2g, MY 2000 3g, evo 5,6,6.5, MY 1999 VR4, and others.

logic

iTrader: (2)

What's with all the Illinois people being interested in ACD reprogramming, anyway? I thought I was in the midwest forum for a minute.

Green Meanie: I understand what you're saying. However, this kind of work is exactly how programs like EcuFlash, EvoScan, and MitsuLogger were developed, and it's how we ended up with things like Tephra's big-patches-o-goodness. There's nothing magic about any of this, it just requires time, effort, and head-scratching.

derekste, if you have the ability to pull your ACD ECU out easily, I would love to at least take a few high-resolution pictures of the mainboard from both sides. I probably wouldn't have time to do anything else with it until sometime next week or into the following weekend, though (Father's Day, I need to finish rolling the fenders on two cars, and a bunch of little stuff), and I'm sure you need to get that car sold.

MattS00: good information, thanks for that; 17V is a bit much! Yeah, this is an MH7203 (according to sba's picture; that's assuming they didn't get something different in Romania than we have here in the US), so that could be a problem, but even if it did work for 2gs, VR4s, etc, there's no guarantee that it'd work here.

(And since we don't have the source for EcuFlash, particularly the individual kernels and associated client-side protocol, we either get to wait for Colby to take an interest, or we have to re-create a bunch of effort rather than debugging what's already there. Bah. Sorry, I'll hush up now about sour grapes; that still bugs the heck out of me, though.)

Regardless, the Gruppe-S reflashes are proof that it can work, we just need to figure out how, and the fact that this is applicable to other ECUs is icing on the cake. The datasheet certainly makes this look trivial, and there's plenty of sample user program code for writing and erasing if we needed to implement something different than EcuFlash does.

Cool, it looks like Renesas has a build of binutils that targets H8; that's one less thing I need to do.

MR Turco

iTrader: (16)

This all sounds very exciting!

MattS00

IL Rep. I'm actually more interested in H8/500 reflashing, but you guys happen to have the same processor in your ACD as the one I have.

I looked the GNU Binutils that you posted, and it seems that there is no tool chain for the H8/500, but there may be a patch.

http://www.uhde.com/index.php?id=28

http://sourceware.org/ml/binutils/2000-07/msg00120.html

Those are just quick searches, but may be worth looking into.

logic

iTrader: (2)

Urg. Yeah, I just noticed that their distribution targets H8/300, not 500.

I'll see about trying to get a build of any kind of H8/500 going. I don't really care about object format (elf, coff, etc), but I'll need some kind of assembler eventually. It looked like building with a target of "h8500-hitachi" might produce something useful, but as of binutils 2.19.51, I get "This target is no longer supported in gas" when you get that far in the build.

Looks like I might have to go back a few versions to find one that'll do the job.

MattS00

This is still all over my head. I've been learning though. How would the GNU binutils be useful?

All I have used is dasmh85.exe. I can open the rom, see the pnemonics, go to the different address in the ecuflash xml, run the hex values through the scalings in the xml and see the numbers match up to the numbers on the ecuflash . However, I can only see adresses from 0000 to ffff.