Interest in Tuning for Boost with the Stock ECU

[DDozier]

Most of us that have made the move to a stand alone save the OEM ECU and put it on the shelf. They are hard to come by if you need one and if you decide to go back to stock you have to have one. However, If you let us know what the process will be, and if there is a reasonable level of risk that the ECU will still be usable in the end then I think you will get a candidate.

For your first test does the ECU need to be 100% known good?

You will most likely need to find a 91-94 Manual ECU, the 95-96 ECU's are sort of a hybrid OBD1/OBD2 and were only used in about 1300 cars total. Not sure I would worry about the Auto cars either, very few were made and very very few were modded with more then headers and exhaust. Just the oposite of the Legend world.

I am very impressed at your project and the knowledge you have gained from it, I wish I had the time to play with a project like this. There are a few venders that are making "HOT" chips for the car but I suspect the only thing they are doing is changing a single value maybe the coolant table values to trick the ECU into a slightly leaner condition resulting in a little more power in open loop. Not sure if they would help or not but may not hurt to ask Mark @ Dali Racing. Also the latest round of performance shops may have a few ECU's sitting around, try calling Chris @ SOS, Shad @ Driving Ambition, or Cody @ LoveFAB maybe they can get you a few ECU's to try. I am not sure if they have anything to offer but I think Split Second was working on cracking the ECU before they decided on their piggy back box that really never worked very well but they may have some insite as well. Also check with BrianK hear on Prime, he is the fix-it guy for broken NSX electronics and may be able to help.

Very cool project, I sold my coupe to buy my first NSX, I loved the Coupe and still have a soft spot for those cars.

Dave

 

[sr5guy]

Most of us that have made the move to a stand alone save the OEM ECU and put it on the shelf. They are hard to come by if you need one and if you decide to go back to stock you have to have one. However, If you let us know what the process will be, and if there is a reasonable level of risk that the ECU will still be usable in the end then I think you will get a candidate.

For your first test does the ECU need to be 100% known good?

You will most likely need to find a 91-94 Manual ECU, the 95-96 ECU's are sort of a hybrid OBD1/OBD2 and were only used in about 1300 cars total. Not sure I would worry about the Auto cars either, very few were made and very very few were modded with more then headers and exhaust. Just the oposite of the Legend world.

I am very impressed at your project and the knowledge you have gained from it, I wish I had the time to play with a project like this. There are a few venders that are making "HOT" chips for the car but I suspect the only thing they are doing is changing a single value maybe the coolant table values to trick the ECU into a slightly leaner condition resulting in a little more power in open loop. Not sure if they would help or not but may not hurt to ask Mark @ Dali Racing. Also the latest round of performance shops may have a few ECU's sitting around, try calling Chris @ SOS, Shad @ Driving Ambition, or Cody @ LoveFAB maybe they can get you a few ECU's to try. I am not sure if they have anything to offer but I think Split Second was working on cracking the ECU before they decided on their piggy back box that really never worked very well but they may have some insite as well. Also check with BrianK hear on Prime, he is the fix-it guy for broken NSX electronics and may be able to help.

Very cool project, I sold my coupe to buy my first NSX, I loved the Coupe and still have a soft spot for those cars.

Dave

I actually need two ECU's, one that I can "destroy" - remove the processor and install it in my adapter to obtain an MCU read with. I could probably remove the processor and install an 84 pin socket so that I could re-install it - but I haven't done this before and I couldn't gaurantee that it would be successful - especially with my lack of a proper SMD rework station. I am a subscriber to the waste not-want-not school of thought so I would like to do this to an already broken ECU, then it would be simply a gamble in order to get it working properly again. Someone out there must have a broken ECU.

The other ECU I need would have to be working. I would need to hang on to this ECU for a few months in order to fully experiment with it, but I can promise to return it in working order with the addition of a socket installed. If I can get my RAM/ROM dump program working, I may not even need the above ^. I am currently experimenting with it and the results are promising. I can read the internal MCU programming one byte at a time through the serial port, but once I send it into a loop it locks up the ECU.

The 95-96 ECUs aren't viable candidates at this time. Ducaticraig sent me some pictures of the internals and they mirror the updates made to the Acura RL (replacement for Legend *snicker*) ECUs, which I've studied some. They are 100% internal MASK ROM embedded on chip with no flash available. They are also copy protected so I cannot obtain a read of them with my adapter. There are companies that can get a forceful read of the processor but it costs upwards of $200 - $300, I would need to see a real interest before investing in that. In order to "chip" them, a read would have to be obtained, disassembled, fuel and ignition maps and other variables identified. Then, an 84pin socket is installed in its place and *NEW* processor is programmed with the modified software and installed into the socket. The processor is only programmable once so this can get expensive fast.

I am a die hard Legend fan. My shop is in Bristol and we are one of a kind in that we specialize in (and love) the Legend. My claim to fame is in professionally swapping in the 3.5RL motors with the Type II parts "The 3.5 Hybrid" to alleviate the well known head gasket problem with the C32A1 and to improve performance. Here are a few pictures of my showroom loaded up from the last turkey day meet 11/28/10:

The dirty cars got their spot in the garage

-Matt

 

[DDozier]

So the early ECU's 91-94 have a 2nd chip that stores the lookup tables and the key variables needed to address fuel and ignition? Is it likely that the tables can be rescaled to handle the boost information and extend the MAP signal to the 3BAR range?

I am assuming that you will loose some resolution in the NA areas of the table as the number of columns and rows in the table are probably fixed.

So in my mind this is what you need:

Dead 91-94 ECU (will not be returned)
Working 91-94 ECU used for testing and will be returned with a modified ZIF socket installed, but will not be harmed.

I will put a link out in the General Section of the Site you will get more views there, and link them to this thread.

Major Goals:
1. OBD2 like data monitoring for OBD1 OEM ECU's
2. Flash support for OBD1 ECU's to deal with NA mods
3. Flash support for OBD1 ECU's to deal with FI mods
4. Real Time tuning/data logging via laptop to OEM ECU

Do I have the steps right?

Dave

 

[sr5guy]

So the early ECU's 91-94 have a 2nd chip that stores the lookup tables and the key variables needed to address fuel and ignition? Is it likely that the tables can be rescaled to handle the boost information and extend the MAP signal to the 3BAR range?

I am assuming that you will loose some resolution in the NA areas of the table as the number of columns and rows in the table are probably fixed.

My plans are much more in depth. The Legend and NSX both have an extra fuel and igntion map for EGR as well as an independant 16x20 EGR pulse width table. My plan is to disable the EGR and re-use those fuel and ignition maps for boost. Imagine having the full 16x20 N/A map and a full 16x20 fuel and ignition map solely for tuning boost! I also plan to rewrite the EGR Duty Solenoid pulse width program to control the wastegate. My current plans are to utilze the stock map sensors ability to read up to 10PSI to keep things simple for now, rescaling later if needed.

So in my mind this is what you need:

Dead 91-94 ECU (will not be returned)
Working 91-94 ECU used for testing and will be returned with a modified ZIF socket installed, but will not be harmed.

I will put a link out in the General Section of the Site you will get more views there, and link them to this thread.

Major Goals:
1. OBD2 like data monitoring for OBD1 OEM ECU's
2. Flash support for OBD1 ECU's to deal with NA mods
3. Flash support for OBD1 ECU's to deal with FI mods
4. Real Time tuning/data logging via laptop to OEM ECU

Do I have the steps right?

Dave

Correct, Correct and THANK YOU!

-Matt

 

[DDozier]

Sounds like you have figured a lot out already, some of us have guessed about the OEM ECU and how it acts but have never had the ability to know for sure. Can you tell us anything about the following.

1. are there seperate maps for fuel and ignition while in and out of VTEC
2. how does knock effect the timing and fuel maps
3. how does intake air temps effect timing and fuel
4. we think the ECU may have several different LIMP modes based on a sensor being out of range or undetected
5. are the fuel trims applied globally or are they stored in a table and adjusted to each load/rpm cell
6. we seem to have a cold temp rev limit below the standard rev limit, could this be used to opperate like a 2-step rev limiter if wired to the clutch switch and programmed for a lower rev limit.
7. is there data exchanged between the ECU and the TCU or is it as simple as I have wheel spin so close the throtle plate untill no more wheel spin is present.

Sorry for all the questions but when I set out to learn the AEM standalone I often asked what did the OEM ECU do under these conditions.

Thanks

Dave

 

[sr5guy]

Sounds like you have figured a lot out already, some of us have guessed about the OEM ECU and how it acts but have never had the ability to know for sure. Can you tell us anything about the following.

1. are there seperate maps for fuel and ignition while in and out of VTEC
2. how does knock effect the timing and fuel maps
3. how does intake air temps effect timing and fuel
4. we think the ECU may have several different LIMP modes based on a sensor being out of range or undetected
5. are the fuel trims applied globally or are they stored in a table and adjusted to each load/rpm cell
6. we seem to have a cold temp rev limit below the standard rev limit, could this be used to opperate like a 2-step rev limiter if wired to the clutch switch and programmed for a lower rev limit.
7. is there data exchanged between the ECU and the TCU or is it as simple as I have wheel spin so close the throtle plate untill no more wheel spin is present.

Sorry for all the questions but when I set out to learn the AEM standalone I often asked what did the OEM ECU do under these conditions.

Thanks

Dave

1. Yes, there are a total of 4 fuel maps #1=Low Cam. #2=Low Cam EGR ACTIVE, #3=VTEC Hi Cam, #4=CTS Failure Backup Map. There are a total of 3 Ignition maps #1. Low Cam #2. Low Cam EGR ACTIVE #3. VTEC HI Cam.
2. Under active research - dependant mostly on RAM dump program working.
3. Under active research, I found the desired fuel injector pulse width from the map and I'm back searching that to see what modifies that.
4. The check engine light routine and limp modes are fully reverse engineered and almost 100% understood.
5. See #3.
6. I had a 2-step program working on the Legend almost 4 years ago, this is very simple to implement, problem is that there are multiple ways to implement it. You can implement the two step to go off on detectable engine load, clutch switch or even throttle position.
7. There is data transferred between the transmission computer and the TCS unit, whats being said is still under research. I assume the NSX will handle the TCU a bit differently than the Legend as the NSX has a separate A/T controller and the Legend's is built into the PCM.

-Matt

 

[Swift]

Seems like more than $1000 worth of effort in my eyes to crack the ECU all the way. At least your ambitous. Good luck

 

[f1racr]

Yeah on some fronts you'd say this is completely pointless exercise considering there are other ECU's out there that can do all of the stuff you plan and more, but I've also attacked and achieved a project like this before when it really didn't make time or money sense, but I just wanted to do it and I got there and it's the best feeling around so I totally congratulate your efforts so far and wish you all the best !!

 

[sr5guy]

Seems like more than $1000 worth of effort in my eyes to crack the ECU all the way. At least your ambitous. Good luck

What I've learned (and still learning) from this is worth much much more than $1000. Embedded systems, assembly language, I/O Control, hex, engine control parameters and reverse engineering it all - you can't take a class on that! I've set my goals and I've been working on this project over 4 years now and I'm not quitting until it's done. In the last 4 months I've discovered more than in the last 4 years. Regardless, thanks for the post it means a lot coming from you.

-Matt

 

[DDozier]

Seems like more than $1000 worth of effort in my eyes to crack the ECU all the way. At least your ambitous. Good luck

Much more than a $1000 worth of work but in the end the effort can and will pay off for him I'm sure.

If I had a Legend or NSX (and I do) that had any type of power adder (and it does) and could tune the OEM ECU in real time without the need for any piggy back systems or changes to the factory harnesses and could be undone by a simple flash or chip replacement I would choose that any day. Not all but a good number of people would as well.

If you look at the domestic performance market Ford, GM, and Chrysler all have many companies delivering products that reflash the stock ECU with everything from simple plug in devices to complete custom tuning software and have been doing so for years. The reason they do is that there is a larger market and many of the software engineers that right the code for these platforms are busy writing the tuning software at the same time, or it is "borrowed" by an engineer and "leaked" to the tuning company. Many times these tuning companies in a rush to beat there competition release this cracked software without a clue on how to support it or what the effect of changing a given parameter will do. Talk about scary. As a result of a simple low cost tuning solution with little to no products to purchase you are hard pressed to find a drop in stand alone ECU for any of the domestic market cars. In our case with Honda having a much better security department than the other guys we are left with no other option than to replace the OEM ECU or wire in a piggy back. Now maybe given enough time and he certainly has the will we may have another option one that should be far superior and maybe ever cheaper.

But like everything else in life sometimes it is nice to just have the option of doing it another way.

Keep up the good work Matt.

Dave

 

[sr5guy]

^ Thanks!

Now, back (somewhat) on topic.

Here are the pictures that DucatiCraig sent me of the 37820-PR7-A32 OBD2 95-96 NSX ECU. The OBDII NSX ECU uses the same family of processor as the 91-94 (h8/532)- the H8/500 - but it is updated with larger ROM space and more features (H8/536). What is EXTREMELY interesting is that this ECU uses a PROM version of the H8/536 instead of the MASK ROM. This was most likely done because the NSX's limited production didn't justify the cost for the MASK ROM, and for the ability to be more flexible with running changes to the coding. After a quick examination of the chip part numbers this ECU is much much more complicated than I initially thought. It has an extra MCU, the H8/330. I have to assume that this is due to the engine being drive-by-wire. I can see how control of the throttle plate could require its own processor - it needs to be extremely fast and handle the demands of the accelerator pedal, idle control and commands from the traction control system. What is intriguing, though, is that the OBD2 ECU retains the same proprietary I/O controller as the OBD1 91-94 NSX (MN73011LAQ - the OBD1 NSX uses 2 of these I/O controllers while the Legend & Vigor use 1). This means that the processor is running in expanded mode (with the address and data bus live) in order to address this chip. This ECU also uses many more surface mount components than the OBD1.

What type of interest is there in modifying this ECU? Do the 95+ owners convert back to a cable throttle when using an aftermarket EMS?

This picture clearly shows all of the part numbers for the main chips on the board.
Upper Left IC901: HD6473308CP10 (H8/330 Processor @ 10mhz)
Center IC402: MN73011LAQ (Proprietary ASIC Input/Output controller - identical to the one used on 91-94 NSX and 91-95 Legend)
Right IC401: HD6475368CP10 (H8/536 Processor @ 10mhz)
Lower IC805: HD63140CP (Hitachi Universal Pulse Processor)

The small piece of foil stamped underneath the part number is the internal ROM revision #.

Here is the RL ECU for comparison. I wont spend much time explaining the RL OBD2 ECU because it is less similar to the NSX OBD2 ECU than I initially thought. The ECU's had similar updates in that they use more surface mount technology but most of the similarities end there. The RL got the updated H8/536 but it is the MASK ROM version and is running in Mode 7 - single chip mode with no outside address or data bus active, and it doesn't use the proprietary I/O controller. Also, on the RL, the automatic transmission controls are integrated on the same board, the lower H8/532 processor is for the A/T.

I also took a picture of the home made MCU reader thats used to read the ROM on the processor.

-Matt

 

[DDozier]

Most guys with the 95-2005 use a AEM FIC for fuel and ignition control and a OBD2 scanner for viewing fuel trims.

Looking at the production numbers I would think the priority would be as follows:

1. 91-94 MT Cars 5038 units made
2. 97-05 MT Cars 1998 units made
3. 95-96 MT Cars 1146 units made
4. 91-94 AT Cars 507 units made
5. 95-96 AT Cars 142 units made
6. 97-05 AT Cars 118 units made

Honda shows 3 part numbers for the 91 ECU's, the 92-94 share two of the part numbers with the 91's. The 95-96 cars have two ECU part numbers. The 97-05 have at least 10 ECU part numbers so without a bunch of pics to see if they are physical or programming changes through the years these may be difficult to support if they can be read at all.

Anyone have any 97-05 ECU's they can take detailed pics of? Next time I have the interior out of my '04 I will take pics for you.

Dave

 

[sr5guy]

Most guys with the 95-2005 use a AEM FIC for fuel and ignition control and a OBD2 scanner for viewing fuel trims.

Looking at the production numbers I would think the priority would be as follows:

1. 91-94 MT Cars 5038 units made
2. 97-05 MT Cars 1998 units made
3. 95-96 MT Cars 1146 units made
4. 91-94 AT Cars 507 units made
5. 95-96 AT Cars 142 units made
6. 97-05 AT Cars 118 units made

Honda shows 3 part numbers for the 91 ECU's, the 92-94 share two of the part numbers with the 91's. The 95-96 cars have two ECU part numbers. The 97-05 have at least 10 ECU part numbers so without a bunch of pics to see if they are physical or programming changes through the years these may be difficult to support if they can be read at all.

Anyone have any 97-05 ECU's they can take detailed pics of? Next time I have the interior out of my '04 I will take pics for you.

Dave

Wow, great info. So the 91-94 must be the most popular to "mod". I would assume that the 97+ have some type of flash programmable micro (h8/539?), similar to the 97+ RL's. Figuring out the protocol to use for this would be the hard part, but would be possible. Question is with those production numbers would it be worth it?

I'm going to stick with the 91-94 ECU research but if there is anyone seriously interested in reverse engineering the newer OBD2 ECUs just let me know. I'd need a sacrificial ECU to get the ball rolling.

I have an assortment of 91-94 NSX external ROMs on my computer here. From comparing them it appears that they used the same internal ROM code version within the microprocessor. This means the only changes and updates are in the external chip. This is great because we only need one internal MCU read to decode all of the ECU's from 91-94.

-Matt

 

[DDozier]

In the 91-94 ECU we would need to replace the 2nd data chip with a socket and a new chip that has its own COM port or something that would allow for data read and write, hopefully real time data changes and not a single flash type chip.

I assume the 91-94 are single layer boards and should be easy to install a socket to hold the new chip.

Will these modifications fit inside the OEM ECU housing or will that need to be modified?

What are the estimated hardware changes going to cost? Your best guess.

Dave

 

[sr5guy]

In the 91-94 ECU we would need to replace the 2nd data chip with a socket and a new chip that has its own COM port or something that would allow for data read and write, hopefully real time data changes and not a single flash type chip.

I assume the 91-94 are single layer boards and should be easy to install a socket to hold the new chip.

Will these modifications fit inside the OEM ECU housing or will that need to be modified?

What are the estimated hardware changes going to cost? Your best guess.

Dave

The Ostrich is what allows real time changes. I am currently running it on my Legend. The Ostrich takes the place of the external chip and emulates it. It's usually located externally to the ECU but it could probably be de-cased and installed inside of the ECU. Updates to the running engine are done in tunerpro and can either take effect immediately or multiple changes can be made and uploaded at once. The ostrich can take the place of the chip 100% as it's NVRAM. I've thoroughly tested it - any parameter can be changed within the ECU while the engine is running and the change is noticeable instantly.

The serial port is actually quite simple. The TX and RX lines directly from the processor are routed to a communications header on the circuit board. You use a TTL-RS232-USB adapter cable and most importantly a custom written serial communications program. Without this custom program, there wont be anyway to communicate with the ECU. The ECUs stock datalogging protocols aren't understood - if they even exist.

-Matt

 

[whrdnsx]

The Ostrich is what allows real time changes. I am currently running it on my Legend. The Ostrich takes the place of the external chip and emulates it. It's usually located externally to the ECU but it could probably be de-cased and installed inside of the ECU. Updates to the running engine are done in tunerpro and can either take effect immediately or multiple changes can be made and uploaded at once. The ostrich can take the place of the chip 100% as it's NVRAM. I've thoroughly tested it - any parameter can be changed within the ECU while the engine is running and the change is noticeable instantly.

The serial port is actually quite simple. The TX and RX lines directly from the processor are routed to a communications header on the circuit board. You use a TTL-RS232-USB adapter cable and most importantly a custom written serial communications program. Without this custom program, there wont be anyway to communicate with the ECU. The ECUs stock datalogging protocols aren't understood - if they even exist.

will this serial cable output be similar to say an OBD2 data/plug? basically allowing a scan tool/HKS Camp 2 to be fitted for real time monitoring?

 

[sr5guy]

will this serial cable output be similar to say an OBD2 data/plug? basically allowing a scan tool/HKS Camp 2 to be fitted for real time monitoring?

The data outputted is similar to an OBD2 car, but the protocols to communicate with it aren't. I doubt you would ever be able to hook up an OBD2 scanner directly, but a custom program can surely be made that mimics all of those functions. There are data logging capabilities built into the stock software but I'm not sure how they work. There are many factors - baud rate, data framing, parity, input and output commands, etc that would have to be reverse engineered.

Right now I am using a custom program that outputs one data value directly from RAM. You punch in the RAM address you want to view into the program, upload it with the Ostrich and the serial port starts transmitting the current value instantly. This value is the current raw hex of whatever sensor you want to see - TPS, CTS, RPM, IAT, etc. Each of these RAM addresses has to be painstakingly hunted down within the code, documented, searched and labeled ONE AT A TIME! The benefit is that once they are labeled the code starts making a LOT of sense . The second hardest part after you find each one is to figure out how to calculate that raw hex value into a real world number on the fly.

I currently have the following RAM addresses documented for the NSX:
Raw MAP
Calc MAP
F&R o2's
Speed
RPM 8 &16bit
Current Fuel Cut RPM
TPS (multiple)
Battery Volts
CTS
IAT
PA (baro)
EGR Lift
EGR sol. active
ITA (ignition timing adj.)

Status Bits/Switches:
Clutch
Power Steering
Nuetral
Brake
Starter
A/C Request
Fuel pump sol.
A/C Clutch
EVAP Sol.
VIS Sol.
FPR Sol.
o2 Heaters

-Matt

 

[sr5guy]

Still in search of a 91-94 NSX ECU for the test bench!

-Matt

 

[sr5guy]

Santa came a few days late!!!

Much thanks to Hasdrubal from Washington state for sending in this ECU for analyzation. Part number 37820-P04-A04. I think it's from a 5 speed 1992. It had a Dinan Stage 3 chip previously installed - pretty old, I think that was the first company to make chips for the NSX and Legend.

Here's a quick video of it running on the bench with the Ostrich installed and Tunerpro running on the laptop. The top 6 lights on the instrument cluster are the fuel injectors. Left turn is the EVAP solenoid right turn is the fuel pump solenoid. Remember, this bench was designed for the Acura Legend and the NSX ECU was nearly plug and play. I still have to wire the VTEC solenoids and a few other things for it to run without a CEL.

The trace feature of the Ostrich is active in the video demonstrating pseudo datalogging on the 1st ignition map x and y axis - RPM and MAP load. As the map sensor voltage is increased and decreased you can see the fuel injector pulsewidth increase and decrease and the current cell on the ignition map move left and right.

I didn't have the time to get the datalogging header hooked up, that will come soon. This ECU is a good unit - I am still looking for a broken ECU, but I may not need it if I can get my dump program working.

<object width="480" height="385"><param name="movie" value="http://www.youtube.com/v/5NdiMXzOLvY?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/5NdiMXzOLvY?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></embed></object>


Here are some pictures of the Vigor, Legend and NSX ECUs next to each other. You can see the similarities in each. Notice that the Legend ECU's board part number is E2281A, while the NSX's is E2282A. Only one number off! The vigor ECU uses an updated style board with a lighter coloring, this is also reflected in the 93-95 Legend ECU's.

From left to right 94 Vigor, 92 Legend, 92 NSX

94 Vigor

92 Legend

92 NSX

Thanks again for sending in the ECU. More to come as soon as I get some free time.

-Matt

 

[Matz]

Hi there, I have already sent you a PM, but I just thought of something and wanted to post up here in case anyone else had a similar question.

I just looked into the Ostrich device, which looks very cool. I see in your photos that you have it plugged into a socket, which from what I can recall is where the flash was installed. I can't remember the part number but I think it was a 256k part. Anyhow, in your posts you're referring to RAM addresses, and I just wanted to confirm that you're not actually modifying data in RAM in the MCU itself, but are modifying the values in flash/EEPROM via the Ostrich, which the MCU then reads. Is this correct?

Have you determined whether there is enough free space in the flash/EEPROM to get high resolution tables? Without modifying the code in the MCU itself, it seems impossible to make use of non-contiguous blocks, but I'm not positive. Hondata used a logical trick for this problem before they scrapped their NSX development. I'm not sure if they did the same sort of thing in their other Honda ROMs.

 

[sr5guy]

Hi there, I have already sent you a PM, but I just thought of something and wanted to post up here in case anyone else had a similar question.

I just looked into the Ostrich device, which looks very cool. I see in your photos that you have it plugged into a socket, which from what I can recall is where the flash was installed. I can't remember the part number but I think it was a 256k part. Anyhow, in your posts you're referring to RAM addresses, and I just wanted to confirm that you're not actually modifying data in RAM in the MCU itself, but are modifying the values in flash/EEPROM via the Ostrich, which the MCU then reads. Is this correct?

Have you determined whether there is enough free space in the flash/EEPROM to get high resolution tables? Without modifying the code in the MCU itself, it seems impossible to make use of non-contiguous blocks, but I'm not positive. Hondata used a logical trick for this problem before they scrapped their NSX development. I'm not sure if they did the same sort of thing in their other Honda ROMs.

Hello!

Thanks for your interest, I almost thought this thread was completely dead!

Yes, you are correct. The ostrich is modifying the ROM. The ostrich also has a trace feature that is basically a feedback to a program (tunerpro) of what address in ROM the MCU is currently reading from. The RAM is read from the serial port.

The NSX has 3 ignition maps and 4 fuel maps all contiguous. For N/A purposes they are about as high resolution as you are going to get. 16x20 loadXrpm = 320cells of resolution per map. I also have a logical solution to this when used for tuning for boost, I don't plan on loosing any resolution 0- actually doubling it.

The NSX ROM is really hard pressed for free space - even for small add-on programs - never mind another map - but, I am working on this as we speak. I think I may have found a way to add up to 16K of free space if I can get the chip addressing and enable signals figured out. The Legend, especially the 93-95, have a bit of free space.

I am actually working on getting the (large) portion of code that is inside of the MCU running 100% off chip on a 64K ROM (or the ostrich). From what I'm seeing so far, it's probably not really going to be necessary to run the ECU that way but it would help with the reverse engineering process and I enjoy the challenge.

-Matt

 

[DDozier]

Thanks for the update, sounds like you are moving in a direction, since programming is not in my knowledge base, I hope it is in the right direction.

Best of luck.

Dave

 

[stuntman]

Very cool! I have a lot of respect for what you're working on. Great job, keep up the good work/us updated!

 

[Flexer]

sr5guy you see this:

http://www.nsxprime.com/forums/showthread.php?t=145614

 

[sr5guy]

Thanks for the update, sounds like you are moving in a direction, since programming is not in my knowledge base, I hope it is in the right direction.

Best of luck.

Dave

I am working diligently on this project, I hope to have it somewhat completed by mid-spring.

Very cool! I have a lot of respect for what you're working on. Great job, keep up the good work/us updated!

Thank you, and I will!

sr5guy you see this:

http://www.nsxprime.com/forums/showthread.php?t=145614

I looked it over, looks like someone is selling a socketed ECU? *IF* there is a tune on the chip that supports boost without any type of add on - SAFC or rising rate FPR - and that adjusts for larger size injectors then it may be useful. That is the goal of my project - tuning for boost with the stock ECU WITHOUT any add-ons.

-Matt