Yeah, but we're looking to reverse engineer the firmware and hardware of the ECU. Basically attack the problem from the other end of what he's doing. What we know so far - combination of my work and others -
- the ECU contains two MC6801 chips on 4.0L, each with its own 4kB onboard mask ROM which cannot be modified after manufacture
- it also contains 2kB of SRAM and 8kB of EPROM storage that are used by the main MC6801 for engine and vehicle specific firmware and data storage
- one 6801 is dedicated to realtime operation of important engine subsystems, the other controls overall EFI strategy, peripherals, and comms
- I think I've already posted the info I have on the ECU connector part numbers.
I can't really give much more info as we are still working on it and I haven't had time to poke at it in a week or two now, but I'm approximately 1/4 of the way through disassembling the main MC6801's onboard mask ROM contents by hand. So far it looks like the reset handler and I/O configuration/setup and I'm 99% sure the part I'm working through at present is the serial comms handler.
My hope is to help answer any unanswered questions as to what sections of the serial comms output data means for the REM project and ideally improve RENIX tuning availability, though it will almost certainly require ECU modification as the 8kB EPROM is an OTP type (One Time Programmable) which means it will have to be desoldered and replaced with a socket or EEPROM device on any ECU that is to be tuned. There is a tiny chance that the 2kB SRAM can be used for small amounts of tuning patch code... but don't cross your fingers. I would like to crack this thing wide open and allow full tuning (HONDATA style - mod your ECU hardware, write whatever tune you want to it) and possibly add better diagnostics features to the ECU, for example broken sensor/wire detection, stored codes, etc etc. The ECU only has 32 bytes of nonvolatile RAM and I'm not sure how much of it is used by the existing codebase, so stored codes may be an impossible pipe dream, though I haven't found any use of the nonvolatile address range yet.
I won't speculate further until we have more solid information, and I'd like to thank Mark Nelson and Chris from Christuned for the opportunity to help work on this. Last time I got to reverse engineer something like this was far too long ago, it's fun.
That. sounds. awesome! I'd love to chat sometime about your work if you're interested. I've been doing tons of work decoding the data streams lately, but I'd love to know what else is hiding in those chips.
Would love to discuss it once we have better data. The last thing I want to do is mislead anyone with preliminary information that may be entirely wrong.