pgmfi.org

Hello,

I dumped the code on the MCU from a 1992 Acura Legend Transmission daughterboard (its inside of the ECU). I have no way to verify that the dump was successful as I have no knowledge of ASM (or any other programming language). I would like to know if you think the following .bin file and the associated, disassembled .txt file is corrupted or not.

The MCU is a Hitachi H8/532. HD6435328. Its an original design of Hitachi's based off of their H8 and specifically 500 series lineup. The chip is 16-bit CMOS microcomputer with 1K-byte high-speed RAM on-chip.

H8/500 disassembler http://other.ditcorp.com/legend/DASMH85.EXE

h8/532 manual/datasheet http://other.ditcorp.com/legend/datasheet.pdf

Official programming guide for the H8/500 series
http://other.ditcorp.com/legend/programming.pdf

(thanks, Beav for the above info)

If the dump was successful, I will not feel so bad about possibly destroying a perfectly good engine computer in order to get a dump off of the other ENGINE COMPUTER MCU. The ECU uses the same exact microprocessor with a different ROM code on it. Thank you for your anticipated assistance.


Sincerely,
Matthew Wallace

Also, if the above is succesful and if I get a successful dump of the engine computer MCU, would there be anyone here that would be willing to help out with our project?

This is the entire, EXTREMELY long thread: http://www.acura-legend.com/vbulletin/s ... 37&page=58 the last page shows my important recent findings, basically WHY the 27C256 ROM is divided into two parts.

This is the fuel/ignition map editor program, Beavedit 2: http://www.acura-legend.com/vbulletin/s ... hp?t=91542

This is the MCU info: http://www.acura-legend.com/vbulletin/s ... post748022

This is my hardware thread with datasheets for the individual components, I am adding quite a bit to it very soon. http://www.acura-legend.com/vbulletin/s ... hp?t=91516

Beav made a program that edits the fuel and ignition maps, so we're all set with that. Basically, the reason I am inquiring is to identify some of the more obscure features.

We are trying to find a way to:
1. Disable closed loop operation
2. Enable the data logging header
3. Find out where in code the ECU interprets the MAP scalars so that the stock ECU can support boost

Thanks again!
-Matt

Damn! Just to clarify.. I just need someone to LOOK at the file and give me an OPINION on if it is corrupted or not! I'm not 100% sure the read was correct.

Thanks,
Matt

#1 - potentially tricky. this is generally fairly complex code to turn this on/off - a simple disable is a godsend not a given.

#2. Have you seen the stuff about the stock OBD1 datalogging protocol? I wouldn't be at all surprised if your computer uses a variant of the same protocol.

#3. Have to see how fuel/ignition tables are indexed. If you've already found the tables, this shouldn't be TOO hard.

Good luck, happy hunting.
-D

Thanks so much for replying!

#1. I understand this, on the other hand, I had an idea... If I fool the ECU into thinking the motor is cold all the time by putting a resistor of the proper value into the ECU's temp sensor, would this be a suitable (ghetto) way to tune in open loop? I know that the EGR solenoid only comes on at part throttle in closed loop, so that can be an indication as to whether or not it is in closed loop.

#2. Wow, I was under the impression that you needed to activate it in ROM. Thanks alot!

#3. Yes, the locations of the fuel and ignition maps are discussed in the C Series forum, specifically in All Py3/Pr7 I have Found So Far (look under poster, Beav) My thread on top right now explains why the rom is broken in two sections. Could you have a look-see and point me in the right direction?

Thanks!
Matt

Read your post - seems to explain the ROM structure perfectly. You may want to read up on past posts re: PGMFI RTP for more examples of creative uses for address pins.

I'm not sure what look-see you are looking for but...

In order to figure out how your table indexing works, start with your table addresses. Disassemble the ROM and figure out everywhere those tables are referenced.

Look at the routine referencing the tables. It almost certainly is going to be coming up with a "pointer" value, i.e. byte/word to fetch = table start + "pointer"... This is ususally done with a DPTR+X addressing command. This also explains why a lot of tables are limited to 256 bytes (8 bit "X").

Good luck.
-D

Blundar:

Thanks again for the info. As stated above, I have absolutely no knowledge of assembly programming language. Would you be willing to look into doing this for the Acura-Legend.com forums? I am sure we can set up a group buy type of deal to compensate you well for your time. Obviously there is no rush. If you do not have the time, maybe you can refer me to someone that is knowledgeable in this area. There is a gentleman with a turboed' Legend that can test it out. Let me know in PM or email, I'm sure we would all appreciate your assistance.

Any thoughts on the ghetto open loop mode?

Thanks!

we'll talk.

I sent you a PM.

I just got my hands on an .XDF file for TunerPro for the Legend from Peluca If this helps!

-Matt