Interest in Tuning for Boost with the Stock ECU

[DDozier]

The two major things left would be to find the fuel multiplier values to compensate for larger injectors - and some custom coding to support boost (I need a turbo on my car first ). I honestly don't even know where to start with modifying the code to support boost, I know the main thing is to hold the ECU in open loop once boost is being produced. There are other things I'd like to find such as coil pack dwell time, etc.

-Matt

To modify for boost you would need to be able to do atleast the following:

1. Compensate for injector change
2. Map Sensor rescale for larger 3 Bar MAP
3. Rescale Fuel and Ignition maps for resolution while in boost
4. identify IAT fuel enrichment table and modify
5. Identify all fuel and ignition modifiers
6. Remove ECU limitation for MAP sensor input voltages, right now the ECU goes into fuel cut when the MAP sensor voltage exceeds a value higher than atmosphere, so any boost will cause a fuel cut, we use a voltage clamp on the MAP to stop this event now.
7. Find a way to force open or closed loop operation, this will be needed for tuning the fuel maps.
8. Set target idle RPM, this will be needed for blower cars


Is there a fuel modifier table that lets us set the closed loop target AFR, not likely to be there on this old of an ECU but was wondering?

Dave

 

[sr5guy]

To modify for boost you would need to be able to do atleast the following:

1. Compensate for injector change
2. Map Sensor rescale for larger 3 Bar MAP
3. Rescale Fuel and Ignition maps for resolution while in boost
4. identify IAT fuel enrichment table and modify
5. Identify all fuel and ignition modifiers
6. Remove ECU limitation for MAP sensor input voltages, right now the ECU goes into fuel cut when the MAP sensor voltage exceeds a value higher than atmosphere, so any boost will cause a fuel cut, we use a voltage clamp on the MAP to stop this event now.
7. Find a way to force open or closed loop operation, this will be needed for tuning the fuel maps.
8. Set target idle RPM, this will be needed for blower cars


Is there a fuel modifier table that lets us set the closed loop target AFR, not likely to be there on this old of an ECU but was wondering?

Dave

1. Very, very close to finding the static fuel multipliers
2. See response...
3. See response...
4. IAT fuel enrichment identified!
5. All ignition timing modifiers identified, some fuel modifiers (LTFTs/STFTs and IAT). The fuel program is very very long on this car and will require some significant time to research fully.
6. See response...
7. I have identified the status bit for open/closed loop and the program that selects on various variables (TPS, CTS, Engine Load, etc) what selects open/closed loop, as well as identifying the (separate) open and closed loop fuel maps.
8. Target idle tables (ROM) as well as current desired idle (RAM) have been identified and are obviously referenced to CTS. Also identified target idles for A/C on.

Dave,

Right now I've got #6 taken care of. I've identified the 3v (WOT - atmosphere) map sensor limit and I am able to raise it to 5v (10PSI on the stock MAP sensor) to prevent code 3 (MAP sensor electrical). I have also identified the routine that compares the map sensor against the barometric sensor to set code 5 (MAP sensor signal/vacuum). So, technically you would be able to run boost with these "caps" raised without going into limp mode and setting a CEL. BUT - the ECU doesn't have any programming to handle any voltages over 3v from the MAP sensor, which introduces this conundrum...

The trouble I'm having is with the routine that handles the map sensor calculations. The vast majority of the sensors within the ECU are 0-5v - obviously. The map sensor signal is the exception in that has it's own direct A/D conversion and is converted to an 8 bit value that represents 0-5volts (0=0volts, 255=5volts) this value is then stored in RAM. The map sensor routine then mathematically (subtracts a hard coded amount) converts this value so that it now represents 0-3volts (0=0volts, 255=3volts). So, the rest of the ECU program is calculated for the map sensor reading solely naturally aspirated 0-3v values. So, if that 0-3v value were to be modified to read 0-5v it seems it would throw the whole program out-of-whack.

My idea is to set up a status indicator that queries the MAP sensor and produces a boost/no boost flag. Then, modify the fuel and ignition map routines to include a boost table. The routine would reference the boost status flag and whenever the car is in boost it would use the 0-5v map signal to, modified "boost" MAP scalars and cause a switch to a "boost" table - effectively piggybacking the routine. This will enable extremely high resolution boost tuning. The problem I'm having with this is that the MAP sensor routine is run off of an interrupt and isn't easily accessible.

The interrupt tables and routine are hard-coded onto the MCU (processor), they aren't accessible through the external chip - YET. I am working on getting all of the ECU code - the portion of the code that's within the MCU and the code that is on the chip itself - running on the external chip. So far my results are promising but I really need the help of electrical engineer who has some experience with this old school stuff. I am able to get the program to run off chip briefly, but I believe I am having bus conflict or timing issues I simply don't have the knowledge to resolve. Attached is a schematic of the chip select signals and address lines. I need help rewiring IC404 to be active from 0000-BFFF instead of 8000-BFFF.

Heres a photo of my first attempt are rewiring for 0000-BFFF, as I said I was only partially successful.

 

[DDozier]

The trouble I'm having is with the routine that handles the map sensor calculations. The vast majority of the sensors within the ECU are 0-5v - obviously. The map sensor signal is the exception in that has it's own direct A/D conversion and is converted to an 8 bit value that represents 0-5volts (0=0volts, 255=5volts) this value is then stored in RAM. The map sensor routine then mathematically (subtracts a hard coded amount) converts this value so that it now represents 0-3volts (0=0volts, 255=3volts). So, the rest of the ECU program is calculated for the map sensor reading solely naturally aspirated 0-3v values. So, if that 0-3v value were to be modified to read 0-5v it seems it would throw the whole program out-of-whack.

My idea is to set up a status indicator that queries the MAP sensor and produces a boost/no boost flag. Then, modify the fuel and ignition map routines to include a boost table. The routine would reference the boost status flag and whenever the car is in boost it would use the 0-5v map signal to, modified "boost" MAP scalars and cause a switch to a "boost" table - effectively piggybacking the routine. This will enable extremely high resolution boost tuning. The problem I'm having with this is that the MAP sensor routine is run off of an interrupt and isn't easily accessible.

What if we used a 5 Bar sensor, the 0-3 volt range of a 5 BAR senor is -14.7 Psi to 32.175 Psi, this range would allow for boost upto 17.5lbs of boost, then we just need to work with the existing fuel and ignition tables to tune for a MAP voltage upto 3V. You would loose resolution but may still be workable without the need to re-code the thing.

Just an idea.

Dave

 

[sr5guy]

What if we used a 5 Bar sensor, the 0-3 volt range of a 5 BAR senor is -14.7 Psi to 32.175 Psi, this range would allow for boost upto 17.5lbs of boost, then we just need to work with the existing fuel and ignition tables to tune for a MAP voltage upto 3V. You would loose resolution but may still be workable without the need to re-code the thing.

Just an idea.

Dave

Because that would be too easy? I am still hoping I might find the ace in the deck when I further analyze the load routines.


-Matt

 

[JLCoolman]

I will be reading this thread at a later date.

I'm very interested in what you are doing, as I have been wondering about the tunability of the stock ECU.

Per se, someone with strictly bolt-ons that wants to have their car tuned.
What options do they have besides buying full EMSs like AEM or HKS?

 

[bikenut]

What kind of price were you thinking when it's done?

 

[whrdnsx]

Any updates?

 

[angus]

What if we used a 5 Bar sensor, the 0-3 volt range of a 5 BAR senor is -14.7 Psi to 32.175 Psi, this range would allow for boost upto 17.5lbs of boost, then we just need to work with the existing fuel and ignition tables to tune for a MAP voltage upto 3V. You would loose resolution but may still be workable without the need to re-code the thing.

Just an idea.

Dave

Funny you mention this, I just brought this up recently with a friend and I know that others have done it - I do not know how successfully, in theory you could run the thing with larger injectors and it would work to some extent although I would think you'd still need a way to tweak the injector pulse (like an AFC?). The stock ECU needs to be limited to about 2.83v so there would be even less resolution.

Also, it provides no timing control.

 

[DDozier]

Theory and Practice ?

It should work, the ECU is hardware limited it would seem for changing the actual scale of the MAP sensor so any table that would reference MAP would be limited to working in the 3v range. The ECU going in to limp mode and setting a CEL at the 2.83v issue is solved, as he has found the value for this limitation and can write that voltage limit to whatever he wants. The issue is in hardware that the tables are unable to be scaled without re-writing the processor code. (Matt let no know if I have this wrong)

So if 3v was the limit than I think the 5 Bar sensor may be a quick work around, to get things into the testing stage, but the only way to know for sure is to try.

Timing tables have been mapped and he can re-write new timing tables based on the new 0-3v range of the 5 BAR sensor.

As far as injector changes, he can write the fuel table to compinsate for larger injectors and for boost with the 0-3v range of a 5 BAR sensor. Changes in injectors often require more than just pulse width adjustments to dial in perfect but if that is all we have to play with it can be done, I would just want to run injectors that act very similar to stock in everyway other than volume, but it should work.

Guinea Pig needed? Anyone want to apply?

Dave

 

[Eddy]

Matt,

I've done some research on the 91 NSX ECU since I last wrote you on the Acura-Legend forum and I thought I'll contribute some info here.

To move the ROM address from 0x8000 to 0x0000, the MCU mode needs to be changed from from 2 to 1 or 3. Mode 1 or 3 maps the external memory directly to 0x0000. I found on the NSX ECU, R424 which ties Vcc (5v) to MD1 pin on the MCU can be cut and tie to Vss (0v) to set the mode to 1. I think you already know this.

[edit]
However, there are other problems. When your ROM memory address is mapped to 0x0000, you need a 48K of ROM memory space but without additional logic, wiring a 64K ROM to the MCU would overlap the memory space 0x0000-0xFFFF with the I/O controllers at 0xC000 and 0xE000. The combined MCU ROMs only needs 0x0000-0xBFFF.

I only gave this a quick thought but my approach to address this would be to rewire the top address lines (perhaps A12-A15) from the MCU to the decoder (IC407) to accommodate a 512Kbit ROM (64KB) peacefully with the I/O controllers.

I need to do more research though.

Btw, I made this ECU board markup recently and thought it may help.

Eddy

Ps. Btw, your info on the acura-legend wiki helped me got this started much quicker.

 

[sr5guy]

Matt,

I've done some research on the 91 NSX ECU since I last wrote you on the Acura-Legend forum and I thought I'll contribute some info here.

To move the ROM address from 0x8000 to 0x0000, the MCU mode needs to be changed from from 2 to 1 or 3. Mode 1 or 3 maps the external memory directly to 0x0000. I found on the NSX ECU, R424 which ties Vcc (5v) to MD1 pin on the MCU can be cut and tie to Vss (0v) to set the mode to 1. I think you already know this.

[edit]
However, there are other problems. When your ROM memory address is mapped to 0x0000, you need a 48K of ROM memory space but without additional logic, wiring a 64K ROM to the MCU would overlap the memory space 0x0000-0xFFFF with the I/O controllers at 0xC000 and 0xE000. The combined MCU ROMs only needs 0x0000-0xBFFF.

I only gave this a quick thought but my approach to address this would be to rewire the top address lines (perhaps A12-A15) from the MCU to the decoder (IC407) to accommodate a 512Kbit ROM (64KB) peacefully with the I/O controllers.

I need to do more research though.

Btw, I made this ECU board markup recently and thought it may help.

Eddy

Ps. Btw, your info on the acura-legend wiki helped me got this started much quicker.

Hey great markup and glad to see that info put to good use!

Yes, you are correct, on the Legend ECU board it's almost as if accommodation are made for you to change the mode of the processor! I have successfully done this by simply cutting some jumpers in the top left hand of the board and rewiring the MD0 and MD1 pins vice-versa of how they were from the factory to gain access to MODE3.

I actually had some recent success with getting the entire ROM contents to run off-MCU. I had to hack the vector tables to get it to work though, and here is why... The I/O Controller onboard can be controlled from either the processor or the BACKUP chip. The ECU, when first powered on starts up in BACKUP mode, in where the I/O controller is controlled by the custom BACKUP processor (ASIC MCU chip IC501) which contains the bare minimum settings to make the motor run (AKA Limp Home). As the processor is booted (from the reset exception vector) if everything checks out, control of the I/O controller is taken over by the processor. If any problem is detected within the program (checksum error, timing error, etc) an exception is generated and it refers back to the vector table to know what program to run. This program sets a flag that puts the ecu into BACKUP mode. All of the error-based exceptions and unused exceptions refer to this program that puts the processor in a reset loop and hands off control back to the BACKUP processor. If the problem is somehow corrected the processor will re-take control.

I wired the external ROM to be active from 0000-BFFF by using another 2-4 line decoder (74HC139) piggybacked to the existing circuitry, changed the mode to MODE3 and wired the extra address lines to the ROM. I did this on the fly so I didn't update the schematic, but if you like I could. I stacked the MCU contents and the external contents to fit into 48K size (and filled the rest of the chip with 0's) into 0000-BFFF and uploaded it to the ROM. I was disappointed to see that the processor didn't boot out of backup mode. But ahah! I was getting a live serial port i could communicate with! So, on a hunch, I changed all of the error and unused exception vectors to point to the RESET routine instead of the backup routine and it booted! I installed the ECU in the car and was able to drive it around the block but anytime I tried to accelerate quickly the engine randomly bogged out, and reset again, and other random things happened. BUT, IT RAN off the processor and that's some progress!

I think the problem is one of the following, with the first being the most likely due to the random nature of the engine running.
* If you notice in the stock form, the chip decoder circuit is 100% symmetrical. The instant the ROM is accessed the I/O controller is off, and vice versa. When I piggybacked the extra decoder chip it sent the circuit asymmetrical which could be causing a bus fight for an instant. Not sure how to make a symetric circuit from scratch though.
*The internal ROM is accessed through 16bit data bus, while the external rom is limited to an 8 bit data bus. Might the 8 bit data bus be simply too slow to run the program?
*There could be an unrecognized watch dog timer program running within the ROM. I've verified that the built in watch dog timer circuits in the MCU are not utilized, though.
*I noticed in my research that the early 90's nissan 300zx's run two 32KB rom's instead of a single 64KB ROM and use a similar processor. Why did they do this? Did the 64KB rom not exist at that time or could it be possible that the highest page switch (A15) is simply too slow?

-Matt

 

[sr5guy]

P.S. The NSX ECU uses 2 I/O controllers - the first, like the Legend - is mapped to C000-C01F and the second is mapped to E000-E01F. This is why the NSX decoder circuitry is different. I have a theory for the reason the NSX ECU has 2 (identical) I/O controller chips (of which I've only partly verified): One is assigned to LOW cam and the other is assigned to HIGH cam. The processor updates both of them constantly, regardless of VTEC engagement. When VTEC is engaged the processor simply selects which I/O controller is active and hands off control to the injectors. I think this is done so that the VTEC handoff is nearly instantaneous.

-Matt

 

[whrdnsx]

P.S. The NSX ECU uses 2 I/O controllers - the first, like the Legend - is mapped to C000-C01F and the second is mapped to E000-E01F. This is why the NSX decoder circuitry is different. I have a theory for the reason the NSX ECU has 2 (identical) I/O controller chips (of which I've only partly verified): One is assigned to LOW cam and the other is assigned to HIGH cam. The processor updates both of them constantly, regardless of VTEC engagement. When VTEC is engaged the processor simply selects which I/O controller is active and hands off control to the injectors. I think this is done so that the VTEC handoff is nearly instantaneous.

-Matt

Can the Legend Ecu be used on the NSX?

 

[sr5guy]

Can the Legend Ecu be used on the NSX?

No, the Legend ECU is missing the circuitry to control VTEC along with my explanation of the dual I/O controllers above. You could get the NSX to run minimally on the Legend ECU though since all of the sensor inputs and outputs are nearly the same. I'm sure you could even tune it to run well and implement hacks to control the VTEC, but it still wouldn't have the robustness of the dual I/O controllers.

-Matt

 

[Elite]

If this pans out, you'll have huge interest.

 

[bikenut]

How much longer and any idea on the price?

 

[TURBO2GO]

If this pans out, you'll have huge interest.

Yub...

 

[sr5guy]

If this pans out, you'll have huge interest.

How much longer and any idea on the price?

Yub...

At this point it's going to be awhile before anything is finalized enough for an end-user to tune. There are simply so many different variables and all must be cataloged, identified and defined before any sort of "final" definition could be made. My personal goal is to have something available to use by spring, once I get my car running some boost I think things will accelerate rapidly.

Thanks,
Matt

 

[Eddy]

Hi Matt,

I have spend a few nights mapping out the RESET circuit for the MCU. On the NSX ECU, the RESET line is tied to ground so when the ECU is powered on, the MCU goes into RESET and stays in RESET. There is a transistor (Q400) that ties to the RESET line which is controlled by the backup processor (IC501 pin 17) AND something else (possibly IC402, first I/O controller but without datasheet; I am not sure if it's an input line or output line on the I/O controller) that I haven't fully mapped out. When the condition is right (perhaps after backup processor or some other circuit initializes) after power on, the RESET line is pulled high to bring the MCU out of RESET and the MCU runs the RESET vector routine.

I did an experiment by removing the external ROM on purpose to make the MCU go into fault and noticed the reset loop you described. The RESET line would go low every second or so to reset the MCU (remember, RESET is active low). However, the line that triggers this reset loop is not from the backup processor (IC501 pin 17) but instead from the 2nd input which I haven't mapped out. These 2 inputs are NANDed through IC430 (quad NAND gate) on pin 12-13 with output to the RESET transistor (Q400) on pin 11. I need a few more nights to map the source of this input.

An interesting tidbit I found is that IC430 (quad NAND gates) is used for several different purposes. The first 2 NAND gates are tied in such a way to form a SR latch (flip-flop); I don't know the exact purpose of it yet but it's partially controlled by the backup process IC501 and feeds back to IC501 again. SR latch acts like a light switch; it will keep the value (set or reset) that you set it with, in effect storing a 0 or a 1. The 3rd NAND gate is used to decode MCU's A14 and A15 lines to chip enable (CE) the external ROM; active when address matches A15-A14 match 10. The 4th NAND gate is for controlling the RESET circuit I described above. It looks like Panasonic (Matsushita) changed the design a bit since the Legend ECU and used a 3-8 decoder (vs 2-4 decoder) for selecting the dual I/O controllers and a NAND gate with an inverter to select the external ROM.

I think you are right on the spot about the bus conflict. On the NSX ECU, the address decoders maps a range of addresses exclusively to each device on the bus (ROM, I/O controllers) so there is no conflict with each other. On the Legend ECU from your diagram, it's done the same way. I don't believe the data bus size would have any effect since there are several subroutine on the external ROM that the MCU calls regularly; not to mention it accesses the maps there all the time. Nissan probably used 2 32KB ROM instead of 1 64KB ROM due to cost at the time.

Since you are a 2-4 decoder, double check the decoding is mapping only to 0x0000-0xBFFF (and not something like 0x0000-0xFFFF; that could be the source of your conflict). The decoder should only be active (enables the ROM's ~CE) on the ROM when A15-A13 are these values (000-101) and doesn't include values such as 110 and 111. Maybe you can give my mod a try? http://www.acuralegendwiki.org/images/f/f9/LegendECUExternalROM.pdf

I need some more time to map out all the digital circuits. But I am hoping we can come up with an elegant solution where we put a single 512Kb ROM on a small daughter board that would sit on top of the existing ROM socket and with a few reversible modification to the ECU board, make the MCU run the entire engine program externally. With that, work can then begin on modifying the core engine assembly program to support things such as custom MAP sensors, PWM solenoids, etc.

One last thing; I noticed you put the MCU into mode 3. That enables memory segment paging; I am not sure if it has any effects on the program but I would think mode 1 would be more appropriate since it keep the memory address space the same as mode 2. But mode 3 is definitely useful later if we need to expand the program beyond the 64K memory space.

Thanks!
Eddy

Hey great markup and glad to see that info put to good use!

Yes, you are correct, on the Legend ECU board it's almost as if accommodation are made for you to change the mode of the processor! I have successfully done this by simply cutting some jumpers in the top left hand of the board and rewiring the MD0 and MD1 pins vice-versa of how they were from the factory to gain access to MODE3.

I actually had some recent success with getting the entire ROM contents to run off-MCU. I had to hack the vector tables to get it to work though, and here is why... The I/O Controller onboard can be controlled from either the processor or the BACKUP chip. The ECU, when first powered on starts up in BACKUP mode, in where the I/O controller is controlled by the custom BACKUP processor (ASIC MCU chip IC501) which contains the bare minimum settings to make the motor run (AKA Limp Home). As the processor is booted (from the reset exception vector) if everything checks out, control of the I/O controller is taken over by the processor. If any problem is detected within the program (checksum error, timing error, etc) an exception is generated and it refers back to the vector table to know what program to run. This program sets a flag that puts the ecu into BACKUP mode. All of the error-based exceptions and unused exceptions refer to this program that puts the processor in a reset loop and hands off control back to the BACKUP processor. If the problem is somehow corrected the processor will re-take control.

I wired the external ROM to be active from 0000-BFFF by using another 2-4 line decoder (74HC139) piggybacked to the existing circuitry, changed the mode to MODE3 and wired the extra address lines to the ROM. I did this on the fly so I didn't update the schematic, but if you like I could. I stacked the MCU contents and the external contents to fit into 48K size (and filled the rest of the chip with 0's) into 0000-BFFF and uploaded it to the ROM. I was disappointed to see that the processor didn't boot out of backup mode. But ahah! I was getting a live serial port i could communicate with! So, on a hunch, I changed all of the error and unused exception vectors to point to the RESET routine instead of the backup routine and it booted! I installed the ECU in the car and was able to drive it around the block but anytime I tried to accelerate quickly the engine randomly bogged out, and reset again, and other random things happened. BUT, IT RAN off the processor and that's some progress!

I think the problem is one of the following, with the first being the most likely due to the random nature of the engine running.
* If you notice in the stock form, the chip decoder circuit is 100% symmetrical. The instant the ROM is accessed the I/O controller is off, and vice versa. When I piggybacked the extra decoder chip it sent the circuit asymmetrical which could be causing a bus fight for an instant. Not sure how to make a symetric circuit from scratch though.
*The internal ROM is accessed through 16bit data bus, while the external rom is limited to an 8 bit data bus. Might the 8 bit data bus be simply too slow to run the program?
*There could be an unrecognized watch dog timer program running within the ROM. I've verified that the built in watch dog timer circuits in the MCU are not utilized, though.
*I noticed in my research that the early 90's nissan 300zx's run two 32KB rom's instead of a single 64KB ROM and use a similar processor. Why did they do this? Did the 64KB rom not exist at that time or could it be possible that the highest page switch (A15) is simply too slow?

-Matt

 

[sr5guy]

Hello Eddy!

Great progress, I was incorrect on the MODE 3, which would be expanded maximum mode ROM disabled. The mode I placed it in is MODE 1, ex. min mode, ROM disabled. The default factory mode is MODE 2 which is ex. min mode, ROM enabled. On this subject, I doubt the maximum mode could be used because PORT 6 (which would be used in max mode as address lines A16-A19) is controlling the select lines of the A/D multiplexers.

The Legend's ECU is located in the passenger's side floorboard. I am very familiar with Q400 - as it's the first thing to get knocked off the board when someones heel goes through the ECU .

Yes, and if you had replaced the chip while the ECU was still powered on it would have recovered! At the beginning of the program there is a group of subroutine calls that run one time only at reset before the normal program loop starts. I haven't timed it (its at least a few minutes apart) but as the motor is running i think the ECU may periodically reset on its own because these programs are run again.

The stock configuration with the 2-4 line decoder on the Legend ECU is that ROM is active from 8000-BFFF and I/O is active from C000-DFFF (since C01F-DFFF aren't used it doesn't matter). My circuit basically piggybacked this 8000-BFFF output from the decoder with another decoder circuit that was active from 0000-7FFF and then NOR'd them together to get the proper chip select for the 48K ROM. I will work on getting the schematic together as well as testing your method before this week is out.

There is one wildcard here and I've spoke to someone about it once before. There is an area of RAM from F800-F8FF that is referenced in the program. What is very strange is that variables are placed into this memory throughout the program (it's referenced over 100 times) but it is never read from. Also, when trying to scan those memory areas through the serial port I always get the same value for every address (#DB). The person I spoke with said that is is most likely some type of developmental debugging program but I am still not 100% positive with that explanation.

As for the daughter board proposition with reverse-ability, I have you beat! I installed standoffs on the board to be able to change the mode back to stock with jumpers and I installed a secondary socket on top of the original to make changes. I'm not sure if the NSX ECU had these same accommodations for changing the mode, though.

The mode is changed with the jumpers in the upper left corner of the board...

-Matt

Hi Matt,

I have spend a few nights mapping out the RESET circuit for the MCU. On the NSX ECU, the RESET line is tied to ground so when the ECU is powered on, the MCU goes into RESET and stays in RESET. There is a transistor (Q400) that ties to the RESET line which is controlled by the backup processor (IC501 pin 17) AND something else (possibly IC402, first I/O controller but without datasheet; I am not sure if it's an input line or output line on the I/O controller) that I haven't fully mapped out. When the condition is right (perhaps after backup processor or some other circuit initializes) after power on, the RESET line is pulled high to bring the MCU out of RESET and the MCU runs the RESET vector routine.

I did an experiment by removing the external ROM on purpose to make the MCU go into fault and noticed the reset loop you described. The RESET line would go low every second or so to reset the MCU (remember, RESET is active low). However, the line that triggers this reset loop is not from the backup processor (IC501 pin 17) but instead from the 2nd input which I haven't mapped out. These 2 inputs are NANDed through IC430 (quad NAND gate) on pin 12-13 with output to the RESET transistor (Q400) on pin 11. I need a few more nights to map the source of this input.

An interesting tidbit I found is that IC430 (quad NAND gates) is used for several different purposes. The first 2 NAND gates are tied in such a way to form a SR latch (flip-flop); I don't know the exact purpose of it yet but it's partially controlled by the backup process IC501 and feeds back to IC501 again. SR latch acts like a light switch; it will keep the value (set or reset) that you set it with, in effect storing a 0 or a 1. The 3rd NAND gate is used to decode MCU's A14 and A15 lines to chip enable (CE) the external ROM; active when address matches A15-A14 match 10. The 4th NAND gate is for controlling the RESET circuit I described above. It looks like Panasonic (Matsushita) changed the design a bit since the Legend ECU and used a 3-8 decoder (vs 2-4 decoder) for selecting the dual I/O controllers and a NAND gate with an inverter to select the external ROM.

I think you are right on the spot about the bus conflict. On the NSX ECU, the address decoders maps a range of addresses exclusively to each device on the bus (ROM, I/O controllers) so there is no conflict with each other. On the Legend ECU from your diagram, it's done the same way. I don't believe the data bus size would have any effect since there are several subroutine on the external ROM that the MCU calls regularly; not to mention it accesses the maps there all the time. Nissan probably used 2 32KB ROM instead of 1 64KB ROM due to cost at the time.

Since you are a 2-4 decoder, double check the decoding is mapping only to 0x0000-0xBFFF (and not something like 0x0000-0xFFFF; that could be the source of your conflict). The decoder should only be active (enables the ROM's ~CE) on the ROM when A15-A13 are these values (000-101) and doesn't include values such as 110 and 111. Maybe you can give my mod a try? http://www.acuralegendwiki.org/images/f/f9/LegendECUExternalROM.pdf

I need some more time to map out all the digital circuits. But I am hoping we can come up with an elegant solution where we put a single 512Kb ROM on a small daughter board that would sit on top of the existing ROM socket and with a few reversible modification to the ECU board, make the MCU run the entire engine program externally. With that, work can then begin on modifying the core engine assembly program to support things such as custom MAP sensors, PWM solenoids, etc.

One last thing; I noticed you put the MCU into mode 3. That enables memory segment paging; I am not sure if it has any effects on the program but I would think mode 1 would be more appropriate since it keep the memory address space the same as mode 2. But mode 3 is definitely useful later if we need to expand the program beyond the 64K memory space.

Thanks!
Eddy

 

[TURBO2GO]

Hello Eddy!

This is the only part of your post I understood. :biggrin:

 

[Eddy]

Hi Matt,

Just giving some comments for now. No progress made yet since the last post.

NSX ECU's MCU mode select circuit is also in the upper left corner (see the area around R424 in the diagram I posted). So I do intend to install some jumpers to mode change on demand.

I still can't be 100% sure how your additional 2-4 decoder is working (or not working). If you have the schematics ready, let me know and hopefully I can give you my 2 cents.

About the RAM, that address range (F800-F8FF) is actually not part of the internal RAM (FB80-FF7F). So my next guess would be, is there yet another external device on the bus that the MCU is talking to. It may be an output only device if it's never read from. If this is setup the same way on the NSX ECU, I will find it once I map out all the digital logic.

Will update again in a few days once I spend more time on this.

Thanks.

Eddy

Hello Eddy!

Great progress, I was incorrect on the MODE 3, which would be expanded maximum mode ROM disabled. The mode I placed it in is MODE 1, ex. min mode, ROM disabled. The default factory mode is MODE 2 which is ex. min mode, ROM enabled. On this subject, I doubt the maximum mode could be used because PORT 6 (which would be used in max mode as address lines A16-A19) is controlling the select lines of the A/D multiplexers.

The Legend's ECU is located in the passenger's side floorboard. I am very familiar with Q400 - as it's the first thing to get knocked off the board when someones heel goes through the ECU .

Yes, and if you had replaced the chip while the ECU was still powered on it would have recovered! At the beginning of the program there is a group of subroutine calls that run one time only at reset before the normal program loop starts. I haven't timed it (its at least a few minutes apart) but as the motor is running i think the ECU may periodically reset on its own because these programs are run again.

The stock configuration with the 2-4 line decoder on the Legend ECU is that ROM is active from 8000-BFFF and I/O is active from C000-DFFF (since C01F-DFFF aren't used it doesn't matter). My circuit basically piggybacked this 8000-BFFF output from the decoder with another decoder circuit that was active from 0000-7FFF and then NOR'd them together to get the proper chip select for the 48K ROM. I will work on getting the schematic together as well as testing your method before this week is out.

There is one wildcard here and I've spoke to someone about it once before. There is an area of RAM from F800-F8FF that is referenced in the program. What is very strange is that variables are placed into this memory throughout the program (it's referenced over 100 times) but it is never read from. Also, when trying to scan those memory areas through the serial port I always get the same value for every address (#DB). The person I spoke with said that is is most likely some type of developmental debugging program but I am still not 100% positive with that explanation.

As for the daughter board proposition with reverse-ability, I have you beat! I installed standoffs on the board to be able to change the mode back to stock with jumpers and I installed a secondary socket on top of the original to make changes. I'm not sure if the NSX ECU had these same accommodations for changing the mode, though.

The mode is changed with the jumpers in the upper left corner of the board...

-Matt

 

[sr5guy]

About the RAM, that address range (F800-F8FF) is actually not part of the internal RAM (FB80-FF7F). So my next guess would be, is there yet another external device on the bus that the MCU is talking to. It may be an output only device if it's never read from. If this is setup the same way on the NSX ECU, I will find it once I map out all the digital logic.

I've gone through the logic circuits on the Legend's board and not only does there not seem to be any circuit to control any such extra RAM, there is most definitely not any external address or data lines running to anything other than the external ROM and I/O controller. As a note, the vigor uses the same processor and decoder setup as the Legend but doesn't ever reference this F800-F8FF memory area.

-Matt

 

[Silver Surfer]

This is some real heavy sh!t.....you guys are from another planet from where I am....mucho respecto...Keep this up. :biggrin:

SS

 

[Eddy]

Then I think the other guy you talked to is right. It's probably debug code writing to an address that was inserted during testing but removed in production ECUs; they forgot to take out the code. The 0xDB you are reading is probably undefined value on the bus when you address it. What kind of data is being written to those locations? That may give you some clue.

Eddy

I've gone through the logic circuits on the Legend's board and not only does there not seem to be any circuit to control any such extra RAM, there is most definitely not any external address or data lines running to anything other than the external ROM and I/O controller. As a note, the vigor uses the same processor and decoder setup as the Legend but doesn't ever reference this F800-F8FF memory area.

-Matt