I've created this thread as a 'newbie friendly' resource for compiling knowledge specific to tuning the VH ECU, and for those who are experimenting and tuning with this stuff to provide updates & info as discoveries are made.

What we have available to us at present is something like over 30 different EEPROM bin files from various VH45DE ECUs, and an address file that categorises some of the hex tables into recognizable and editable fields in specific rom editing software.

Here is a list which I will update as people add info in posts, of various programs & equipment used for editing eeproms. Please contribute suggestions & info:

Software:
- Live Edit
- Rom Editor
- NIStune
- Tunerpro & Tunerpro RT (for real time tuning)
- Flash n Burn (for the Burn1 chip burner)

Diagnostics/Consult Software:
- Nissan Datascan
- NIStune
- ECUTalk (one of my favorites)
- Calumsult
- OBD Scan Tech Nissan

Hardware:
- Pocket Romulator - emulates eeprom chips and allows realtime editing.
- Pocket Programmer - burns eeprom bin files onto 28 pin chips for use in ECUs.
- Ostrich 2 - emulates eeprom chips
- Moates Burn1 - burns a BIN to the 27SF512 EPROM.
- SST 27SF512 - rewritable EPROM chips will hold 2 32K BIN programs, easy to modify to allow you to switch between the two tunes.

Oh... and hands up who has a NIStune kit?

Thanks,
Nick.

Software:
Tunerpro & Tunerpro RT (for real time tuning)
Flash n Burn (for the Burn1 chip burner)

Diagnostics/Consult Software:
ECUTalk (one of my favorites)
Calumsult
OBD Scan Tech Nissan

Hardware:
Moates Burn1 - burns a BIN to the 27SF512 EPROM
SST 27SF512 - rewritable EPROM chips will hold 2 32K BIN programs, easy to modify to allow you to switch between the two tunes.

The stock ecu is fantastic in that it provides sequential injection, coil on plug, sensor fail safes, diagnostic feedback, and pretuned maps. Swapping in larger injectors/afms and dealing with boost is no problem once the basic concepts of how the ecu works are understood.

As far as drawbacks the only thing I've run into is the lack of knowledge about the actual code processes. Until someone is able to disassemble the code it's impossible to know 100% what the ecu is doing or how it can be modified. Unless you need to go to a map sensor (without using an adapter) or you're looking for some custom inputs/outputs this isnt a problem for most people.

The q45 and z32 ecus (at least the early models) are both based on the same design. There's quite a bit of information regarding the tuning and operation of the z32 ecu that can be applied to the q45 ecu.

Amirite in assuming everyone's just using this address file:

Q45_VH45DE_256_E_ADDRESSES.adr

Hmmm and it seems this address file is going to be useless with the VH41 ecu bin that I have too.

What are your thoughts on running the JDM VH41 on a VH45 ecu? Will get more details tonight.

Street Dynamics Racing
jetaylor@vt.edu

Shane is working with Moates to try to determine what may be going on. I also wanted to let you know that I communicated with Matt at NisTune and he indicated that his customers have successfully tuned VH45 ECUs with the Ostrich2 and NisTune - I'm taking this at face value.

He did mention this:
"One thing we noticed Emutility does is change the vendor ID from 0 (default) to 3 which may cause some issues. We had to add a 'reset' option CTRL-SHIFT-V to reset this back to 0 in order to use the emulators with NIStune and Nissan ECUs"

Not sure if this could cause the issues you experienced or the ones Shane and soon I (I got an Ostrich2 for Father's Day) are/will, but I thought I would let you know.

Thanks,
Nick,

I'm using Tunerpro, not Rom Editor. I have much more information than what's on that ADR file. Also, I found some errors on the .adr file and fixed them. I assume the one you are using is the one I have that I corrected.

Here are more addresses than you will know what to do with. Merry Christmas I even have your VTC on/off points Mettler

http://www.c4caraudio.com/tech...s.JPG

Tunerpro is much nicer to work with than Rom Editor but if anyone want's my edited ADR file let me know.

If you have Nissan Data Scan here are the addresses to use Map Trace with the 90-93 Q45 ECU

Primary Timing (No Knock)
RPM MSB 140B, Map Address F800
RPM LSB 140C, TP Scale Address FB10
TP MSB 148C, RPM Scale Address FB20

Primary Fuel (No Knock)
RPM MSB 140B, Map Address FD00
RPM LSB 140C, TP Scale Address FAF0
TP MSB 148C, RPM Scale Address FB00

When my wife bought mine for father's day she bought the socket booster as well, so if it works for you I should be set - yeah

Let me know what you find out and thanks for working on this!

Thanks,
Nick.

Does she have any sisters?

Over on the eccs.hybridka.com forums I posted a schematic for a ka24e nvsram implementation. This configuration will work on any 6303 based 8 bit nissan ecu.

What needs to be done is to confirm the pinout of the 4 pin header (known as F/C1, but may not be labeled) next to the eprom socket. This 4 pin header should contain A15, E, and R/W from the bus.

Once those pins are found, and the nvsram adapter board is built, a non-volatile sram (simtek 16c88, dallas ds1230) can be used in place of the eprom.

Ive looked over the q45 code and I can add additional consult commands including write-to-ROM with ease. If anyone is willing to work out the hardware (implementing it onto this platform), I will write the code for it.

This not only provides a native real time solution (turning the ecu into its own emulator) but also opens up gobs of usuable high speed sram that can be used in the program. This provides an extra bit of flexibility when writing custom program code, and improves memory performance overall (access time < 45ns, vs 120+ns eprom or emulator)

EDIT: What software is used to write to this? How about a summary of how it works? I found your thread on the subject and copied all the diagrams, etc. I'll look at the 4 pin pad tonight. I've seen it used by some other products and with other ECU' but I haven't looked at it very closely. If it's not labeled, what's the process to trace them?


Modified by qsiguy at 5:16 PM 6/19/2008

The command protocol would be open, first of all, so anyone can write software to use it.

Initially what I would do is write up an emutility like "wedge" software that would work independently of the rom editing software. This can be made up in as little as a couple hours, as I already have the .NET routines for it.

Ive been tight-lipped about it, but I also have complete ECCS tuning software solution I have been working on for about a year or so, similar to Nistune. It still needs some finishing touches (ie. wideband support) but it offers complete 2d/3d rom editing, pinpoint map tracing, and real-time update all-in-one.

I dont have the time to properly market the software/hardware solution and am seriously considering making it free for download. You can expect to see it in the next couple months.

The best way to go about identifying the pinout of the 4 pin header is to trace it back to either the 6303 or the companion processor which are both on the memory bus. If I recall correctly, the companion processor used on the q45 has a datasheet available. Both it and the 6303 should have A15, E, and R/W in the pinout.

Pin 9 of this chip is R/W and should lead to one of the pins on the 4 pin header.

Trace all 4 as far as you can, they should lead to the 6303/63140 at some point. Note the pin numbers they go to, ill dig up my datasheets later on to see if we can figure them out.

Here are the chips. Just above the EPROM socket is the 63140. To the right of the EPROM is one with a HD63C03YCP. Is that the other one you are talking about?

Yes, that's looks like the companion microprocessor for the ECM.

Here's the datasheet: http://www.datasheetarchive.co....html

Thanks,
Nick,

Remove the diagnostic pot bracket and mount the pot in the hole sticking out of the ECU.

Before, the socket booster would hit the potentiometer.

After, plenty of room

Also I had to move the daughterboard over. I just drilled new holes in the edge of the PCB where there was not any circuitry and I have a strip of electrical tape along the underside of the edge in case it want's to touch the case. Without moving this board there isn't enough clearance to get more than the slim line socket and one chip or the Ostrich, it would hit with the socket booster added.

Thanks for your hard work on this.

Nick.

The pinout of F/C1 (4 pin header pad) would seem to be the same as the ka24e. They are both labeled similarly and are of the same vintage and JECS manufacture. I can tell just from looking at the pictures that along with R/W being silkscreened, it can be seen on the top side of the board that pin 1 leads to E on the 6303.

Assemble the nvsram adapter circuit on some protoboard, buy a simtek stk16c88, and program it with your favorite .bin. Let me know when you have it running (as ROM) and I should have some code ready by that time.

It would seem the daughterboard relocation would be necessary with a home-brew nvsram board, as it would be difficult to build it with that low profile. Eventually I will have some pcb's made up , but the 8bit adapter board is so simple, it can be made easily with prototype board and a few common parts.

When I say 6303 I am referring to the HD63C03YCP. This is the main core handling all fuel/ignition mapping and other essential tuning variables. It also handles the consult-1 communication.

The HD64130 is the "companion processor" or more appropriately called UPP (universal pulse processor). It is on the same memory bus as the 6303 and performs some core I/O functions and also is the onboard ADC and I think some sram. It takes all of the analog sensor voltages and converts them to a digital 10-bit word, it stores them in sram (on the same memory bus as ROM) which the 6303 uses as input variables to its fuel, ignition, and other routines.

The other large IC's are unknown in-house programmable logic device or micros with built in resonators and unreadable ROM. They also handle various I/O like CAS decoding/seqential output control and some memory bus control as well.

So its a multi-core system, but only whats going on in the 6303 is of interest really.

Im new to factory ecu modification itself, so i dont know how similar the vh and vg ecus are or arent.

devious, I'll get to work on the nvsram. Can I program the stk16c88 with a normal 28 pin EPROM burner like the Moates Burn1? Also, Why do you need the STK16C88 to make this work? I assume a 27SF512 isn't compatible with this mod but why? Can you elaborate?

On another note, I just received the Moates socket booster card today so I will try it out tonight and see if it solves the problem with the Ostrich 2.

EDIT: I ordered the STK16C88 as well as the other small chip today. I should have them a few days I guess, never ordered from this company before.

Modified by qsiguy at 11:29 PM 6/23/2008

I needed to remove the potentiometer bracket, move the daughter board over and install a low profile 28 pin socket to make it all fit inside the ECU.

Here's a shot of the socket booster with the Ostrich ribbon cable attached and the pot bracket removed. The pot is just mounted to the case of the ECU now with the knob sticking out.

The question to ask them is if the burn1 will support ds1230 programming without any special adapter board. The chip itself does not require any high programming voltages (like eeproms), but the pinout is laid out more like an sram.

All willem programmers I have used support the ds1230, and stk16c88. That is what I have here to program mine.

Non Volatile Sram is like the blend between an sram and rom. On startup, the nvsram chip takes all data that is located in its internal eeprom and places it in sram. During shutdown, the reverse process occurs where all of the sram is automatically stored back into the internal eeprom.

Running the program from sram allows us to manipulate any data or program bytes in real-time using the microcontrollers own built in machine instructions. Originally this is not possible, as the program/data is running from ROM.

Normal sram chips cannot be used because they lose all data when power is removed. The nvsram takes care of this problem.

29C256, 29F040, 27SF512, 2732A (Read Only), 27C128 (Read only), 27C256 (Read only), 27C512 (Read only), J3 Ford Adapter, J3 Ford EEC-IV Reader, J3 Ford EEC-V Reader

I sold my Willem dual power unit since I could never get it to work. Is there another Willem that works better?

I got my chips in so I'm ready to fab up the board. What socket/adapter do you use for your board to attach it to the ECU? Looks like most of the STK16C88 terminals line up but not all. Looks fairly simple but do you happen to have any other photos of how you did yours, top/bottom of the board?

The nvsrams do not require any special voltages for erasing/programming. Simply power up the chip (5v) and write the data, power it down and done.

From my experience and the feedback I have gotten from others is that just about every willem version will do the nvsram chips without error. Personally I use the willem enhanced, which seems to be obsolete now, but I have heard from a user that the dual-power version programs the 16c88 without problem (I know there are all kinds of versions now, so I cannot offer an exact recommendation).

People seem to have a lot of problems with the willem programmers when trying to program the SST 27sf512. Back in the day when everyone used to use the atmel at29c256 instead, there were very few problems. I wouldnt let 27sf512 experience sway you so much when (re) purchasing a willem programmer, for the price it cannot be beat, it can program a lot of different types of chips and microcontrollers. From my experience the 27sf512 is the most troublesome.

Ill get back with you on the example adapter board, need to borrow a camera. I actually designed the adaptation about 3-4yrs ago, but have only recently deciphered and re-written the code to make use of it. All of my pictures/info on the board are that old, so updates are in order.

From what I remember the Zemulator is a decent editor with real time update (romulator), but it lacked proper maptrace.

They used an external ADC device (labjack) to input sensor values and formulate a TP. Like the bikirom, highly inaccurate, with proper firmware this data can streamed through consult properly, without any external device.

Any update?

I'm disassembling the vh45 code now. Going to strip it back to try and free up some extra space.

http://datasheets.chipdb.org/H...Y.pdf

For the temp scaled tables this isn't a problem as the engine should not be running past the extreme ends of the tables. However for rpm and tp based scales it may be worth considering under some circumstances.