OpenPort 2.0 Logic Sniffing

[scott.mohekey]

Hey, is there anyone out there with an OpenPort 2.0 and a logic sniffer, that could create some logs for me of the wires connected to the car. I'm specifically after logs of the initial flash start up phase, and the logging start up phase.

Any help would be greatly appreciated.

[BCX]

Logging start up phase uses "Five Baud Init" thats documented in the ISO9141 standard. Exception with Mitsubishi is pin 1 needs to be earthed and init addresses aren't 'standard'.

SAE-J2534 standard will explain programming requirements for using the openport.

[scott.mohekey]

Correct me if I'm wrong, but isn't SAE-J2534 a spec for the protocol/physical implementation between the computer and the flashing device (in this case the open port)? I'm looking at making a replacement for the open port 2.0.

[BCX]

Yes, thats correct. Now i know what your trying to do, i can hopefully give you as much info as i can.

basically for logging, you'll need to pull pin 1 to earth, then send a five init baud down the k-line (VR4 and most mitsubishis dont use L-line)

Five init baud consists of 10-bits:
1 start bit
8 bits - address to select what device you want to communicate with
1 stop bit

200ms between each bit will be 5 baud.

0x1 - address to select ECU
0x3 - address to select TCU

After your init, you'll switch to your normal baud rate (15625) and will recieve 2 bytes - these identify the device you are communicating to.

After that, you can send your 1-byte MUT addresses, and you'll recieve a 1-byte reply.

if you dont send any data for about 10-secs, you'll need to re-init again.

[scott.mohekey]

I think I've seen that around on the net once before, but wasn't sure where or if it was even right. Thanks for reproducing it here.

That covers the logging aspect, but do you know anything about the flashing process?

[BCX]

no idea on flashing, sorry. i would be very interested in any info you find out.

So much for ECUFlash being 'open source' when the source code hasnt been released :\

[scott.mohekey]

Yeah, its really quite frustrating, hence me asking for some logic logs.

[wintertidenz]

Wouldn't it be easier to reverse-engineer the MUT-III flash method? The OpenPort was designed using this method.

I may be able to get my hands on a MUT-III for a day as well.

[scott.mohekey]

Either or, all we really need is to know how the ecu is put into flash mode, and how to transfer the rom to it once its in that mode.

I have a logic sniffer, but no open port or mut hardware.

[Adam.Findlay]

carl has a open port 2.0 so flick him a txt im sure he will lend it to you once hes done retuning for his cams (i had it for something like 6 months before that haha)

[scott.mohekey]

Genius!

[wintertidenz]

I've got a copy of the MUT-III software at work as well, so I will see if I can find anything relating to reflashing the ECU in there.

[foxdie]

If anyone in the West Midlands (UK) has a 8 channel or better logic sniffer capable of sniffing circa +12V, message me and we'll arrange to log a flash, I can test flash both a 7202 ECU with EcuFlash and a H8/539 ECU with MMCFlash.

[BCX]

i've done a bit of digging around, seems ECUflash uploads some form of custom kernel run in RAM that allows the H8 to write over itself.

nfi what the source code for the kernel is or how it does it.

[Gatecrasher]

i've done a bit of digging around, seems ECUflash uploads some form of custom kernel run in RAM that allows the H8 to write over itself.

nfi what the source code for the kernel is or how it does it.

There are examples in the H8-539 data sheets from Hitachi (now Renesas).

As best as I know, Colby wrote his own flash kernels. Beware though. The overall procedure is the same, but the particulars are different depending on whether you're flashing a H8-539F (MH7202F) or an H8-539FA (MH7203FA). The FA variant has slightly different voltage requirements, and the layout of the various flash 'blocks' is different. That's why you can potentially brick an ECU by flashing it using the wrong memory model.