Memory dump of ECU

[racerx9146]

This is my favorite thread of all time. Great Stuff!

Just to chime in with my 5 cents. I have been using Select Monitor with this TTL converter for about 1 month with Phil's parameters. My ROM ID is 722525 I have a Dash mounted touchscreen and a computer permanently mounted in the Truck (92 SVX motor in a Vanagon Syncro Doublecab) I use select monitor every day and it works pretty flawlessly. My converter is right next to the ECU and is powered (12V) off the same power supplied to the ECU via the main relay when Ignition is turned on. Maybe I have a lucky ECU but I rather think you maybe onto something with the voltage discovery. How are you powering your self-made TTL converters?

John

[Calum]

Originally Posted by b3lha

I haven't been able to find a datasheet for the 37791 anywhere.

I don't think it would be an issue having the separate units on different baud rates. They stay silent until woken by their own specific read command.

At present we don't have the ability to make changes to the ROM.

As I understand it, the 28C1028 EPROM required by the ECU and TCU is no longer available. There is a guy who makes an adapter that will allow a pair of 27C512 EPROMS to be used instead. http://www.scoobyecu.co.uk. This is the same approach taken by Longassname (ECUtune) for his Stage 1.

A burner for 27C512 eproms can be found on ebay for about $18. http://search.ebay.com/Enhanced-Univ...ROM-Programmer I may think about getting one in the future, but at the moment I can't devote enough time to the project.

Phil.

Hi Phil,

I worked out what combination of peripherals the 7791 has. Its got two UARTs, but 3 less timers and 1 less PWM than the 7790. Everything else is the same. I've uploaded the changed disSVX.cpp code and new disassembly (SVX.txt). The source code lists the correct arrangement of registers and interrupt vector table. I have an ulterior motive for messing around with the 7791 stuff: a particular model Nissan ecu uses it too, and I've been meaning to crank out a daughterboard for it for a while, and having a functional disassembler and chip description really helps.

Just some suggestions about ROM boards and such:

-Standardize on the SST 27SF512 eeprom. It very easy to work with, readily available (I stock them), and pretty low cost.
-Use a Moates.net Burn1. Its fairly low cost ($85), but more importantly works right out of the box, every single time. Its fast too, programming a 27SF512 takes about 5 seconds.
-Use ZIF sockets. Swapping chips with regular sockets just stinks. Once you go ZIF you never look back. I don't make ROM boards without ZIF sockets anymore.

This is what my basic ROM board for the '91-93 Nissan B13/S13 looks like, with a walkthrough of how to use the moates.net Burn1:

http://www.sr20forum.com/calumsult/1...tes-burn1.html

Hiding under the board is the 7790 mcu. Just to the right you can see the stock M6M27256 ROM. Nissan handily left a debug header (visible at the top of the ROM board) for external memory usage, and you disable the stock ROM by setting a jumper on the back of the board. Very similar to the Subaru stuff. If your really going to do more than just play with the ecu, and actually custom tune your car, it helps to move beyond a ROM board to something that you can make updates to without having to swap chips all the time. Swapping chips between runs on a dyno is doable, but a headache. I've been there. You've got options on how to do this. This is what I came up (and sell) with in Nissan land:

http://www.sr20forum.com/calumsult/1...all-guide.html

You can just see the USB cable sticking out the back of the ecu. It does realtime memory emulation, plus CONSULT, all over the single USB. Makes tuning much faster, you can make changes while the car is running. On a loading dyno (i.e. not a dynojet) like a dyno-dynamics this is really cool: you can actually hold the engine at one load cell and adjust the timing and fuel on that one cell and watch the changes. Just a small plug (), if your near northern Georgia (USA), check out Dyno4mance sometime. This is a group of B14s getting tuned with a B14 Realtime ECU at Dyno4mance (scroll down past the car pictures). They have a AWD dyno-dynamics machine, and really know how to use it. Andrew does a ton of late model subbies and mitsus, but he could tune a lawn mower. Awesome facility.

http://www.sr20forum.com/members-rid...alhoun-ga.html

Btw, just one last suggestion. When your developing your SSM software, especially if you get the buad rate up to 9600 and your going to use it for ECU tuning, take some time to add in 'map tracing' if possible. Basically you just stream the RAM variables that are being used when the main fuel or timing maps are called, and plot out exactly where on those maps that your operating. The end result is something like this (this is Nissan DataScan, one of many Nissan CONSULT software packages) -scroll down a little for pics-:

http://www.sr20forum.com/calumsult/1...cing-cool.html

The green trace highlights exactly where the ecu is operating, and leaves behind a yellow trail showing where it was operating. When you tune, you just watch where the ecu is operating (or was operating if your doing pulls like on a dynojet), and just tune those load cells. Very handy.

If I pick up an early 90s Subbie ECU (not exactly common in this neck of the woods), harness (I really just need the bit the plugs into the ecu), and some freetime (important!, lol) I'll crank out a basic ROM board. Its not very complicated.

I'll post what I would add to your SSM circuit.

[TomsSVX]

So ur using a $45 converter and using Phil's parameters with success on a 92 ecu and wiring?? If so, I think you just found our problem

tom

Originally Posted by racerx9146

This is my favorite thread of all time. Great Stuff!

Just to chime in with my 5 cents. I have been using Select Monitor with this TTL converter for about 1 month with Phil's parameters. My ROM ID is 722525 I have a Dash mounted touchscreen and a computer permanently mounted in the Truck (92 SVX motor in a Vanagon Syncro Doublecab) I use select monitor every day and it works pretty flawlessly. My converter is right next to the ECU and is powered (12V) off the same power supplied to the ECU via the main relay when Ignition is turned on. Maybe I have a lucky ECU but I rather think you maybe onto something with the voltage discovery. How are you powering your self-made TTL converters?

John

[racerx9146]

Originally Posted by TomsSVX

So ur using a $45 converter and using Phil's parameters with success on a 92 ecu and wiring?? If so, I think you just found our problem

tom

Well I am not sure the problem is found but I just wanted to throw out a working setup. My wiring harness is not exactly "stock" since its in the Vanagon. Its a 92 SVX harness with everything but the Engine stuff removed. So the harness was dissected and rewrapped. If anybody is near Sacramento, CA they are welcome to come by and we can try my converter with a spare laptop I have. Kinda hard to remove my computer from the truck! It would have to be someone who is experiencing the junk data problem with their converter to make it a somewhat meaningful test!

Of course the faster baud rate and more software features as discussed by others here would be incredible!

John

[Calum]

http://www.calumsult.com/calumsu/dis.../SVX/SSM_0.pdf

Thats what I would add. The ratio of R2 and R3 sets the low point of the comparator. With 10k and 6.2k its at approx 2V.

[Trevor]

Originally Posted by Calum

http://www.calumsult.com/calumsu/dis.../SVX/SSM_0.pdf

Thats what I would add. The ratio of R2 and R3 sets the low point of the comparator. With 10k and 6.2k its at approx 2V.

Phil the input described/shown here fronting an OP AMP, is exactly in accordance with the issue I raised earlier in this thread, i.e.

“Or is your input impedance/loading too low i.e. too sensitive. A higher relative loading would pull down the output/input signal voltage. This could be where the Subaru OEM monitor differs. The fact that you indicate that a zero voltage is not being recorded, points in this direction.

The lower the monitor input impedance/resistance; the greater the signal current; lower the voltage (Dependent on output capacity) and greater the immunity to noise. In all respects the transmitted signal is more robust, a worthwhile feature.

In other words, the existing signal could be overloading your gear. Think of the affect of overloading the input of an audio amp.”

“As you have no data to make calculations, trial and error will be the order of the day, as will be a rather crude approach to the problem.

The simple approach is to add a resistor across the monitor input as a shunt. Measure the resistance at present existing across the input and as first trial, connect a resistor of say four times this value in parallel. You will appreciate that reducing the value of this resistor, will further reduce sensitivity and increase the demand for current.

I would anticipate that a small carbon resistor should suffice in respect wattage. There will be problems of a mechanical nature in arranging connections and you will probably have to make up an in and out plug socket arrangement.”

The sophisticated approach towards input impedance correction, which I did not suggest for good reason, is to add a series and a parallel input network. The circuit shown goes further by isolating the input loading via a low gain amp.

You should also notice that the circuit, as would be expected, incorporates a stand alone IC voltage regulator, cost near zero. Reference has been made regarding the possible influence of supply voltage in respect of problems. It would be strange indeed if all of the items in use, were not likewise protected, and on this basis I would discount this as a likely issue.

All the best with your project. Thankfully you now have many chewing with you. Trevor.

[Nomake Wan]

But Trevor, doesn't that assume that the problem is that the unit is getting too much current? My experiment has proven that the exact opposite is the case. When not enough current is in the system, junk data happens. When this is compensated for (by spinning up the alternator), the data goes back to normal. It has been suggested in this thread that "alternator noise" is the cause for the problem. Again, not the case, since the data goes back to normal when the alternator output is increased.

I do not think it is interference in the form of additional current. I don't know how to describe it. Except that when a load is added to the SVX electrical system, the data that the converter receives becomes garbled (i.e. no longer complies with the standard the converter is based upon). When the load is removed, or otherwise compensated for, the data becomes compliant once more.

Sadly I cannot read Calum's schematic as I don't have the learning to do so, but maybe it operates under this principle?

EDIT: Friend of mine took a peek and told me what was different. So in Calum's diagram, he adds a capacitors to the voltage regulator circuit (between pins 2 and 3), adds a diode to the +12V input, and uses a comparator to make "absolute values" of the voltage levels. i.e. +5V = 1 and -5V = 0. That's an interesting way to go about it, removes the whole decision-making process and only hands out the binary data.

Trouble is, I can't really test it...

[b3lha]

Originally Posted by b3lha

This is just a guess, because I haven't had the chance to try it yet, but I would set the baud rate and then send the following as hex 7F313233343532

I tried this. Didn't work
Will have to have a read of the code and see what it is expecting to receive.

[b3lha]

Originally Posted by Calum

Hi Phil,

I worked out what combination of peripherals the 7791 has. Its got two UARTs, but 3 less timers and 1 less PWM than the 7790. Everything else is the same. I've uploaded the changed disSVX.cpp code and new disassembly (SVX.txt). The source code lists the correct arrangement of registers and interrupt vector table.

Thanks. You're really helping us out here.

Originally Posted by Calum

I have an ulterior motive for messing around with the 7791 stuff: a particular model Nissan ecu uses it too, and I've been meaning to crank out a daughterboard for it for a while, and having a functional disassembler and chip description really helps.

Somebody recently sent me the Renesas 7700 software. There's a C compiler and more importantly a 7700 simulator/debugger. It's possible to step through the code and watch it run. I can forward it to you if you would find it useful for your project.

Originally Posted by Calum

Just some suggestions about ROM boards and such:

-Standardize on the SST 27SF512 eeprom. It very easy to work with, readily available (I stock them), and pretty low cost.
-Use a Moates.net Burn1. Its fairly low cost ($85), but more importantly works right out of the box, every single time. Its fast too, programming a 27SF512 takes about 5 seconds.
-Use ZIF sockets. Swapping chips with regular sockets just stinks. Once you go ZIF you never look back. I don't make ROM boards without ZIF sockets anymore.

Thanks. It's nice to have advice from someone who knows about this stuff. Do you make a ROM board like the one on www.scoobyecu.co.uk that will plug into the 27C1028 socket on our ECU and TCU?

Originally Posted by Calum

This is what my basic ROM board for the '91-93 Nissan B13/S13 looks like, with a walkthrough of how to use the moates.net Burn1:

http://www.sr20forum.com/calumsult/1...tes-burn1.html

Hiding under the board is the 7790 mcu. Just to the right you can see the stock M6M27256 ROM. Nissan handily left a debug header (visible at the top of the ROM board) for external memory usage, and you disable the stock ROM by setting a jumper on the back of the board. Very similar to the Subaru stuff. If your really going to do more than just play with the ecu, and actually custom tune your car, it helps to move beyond a ROM board to something that you can make updates to without having to swap chips all the time. Swapping chips between runs on a dyno is doable, but a headache. I've been there. You've got options on how to do this. This is what I came up (and sell) with in Nissan land:

http://www.sr20forum.com/calumsult/1...all-guide.html

You can just see the USB cable sticking out the back of the ecu. It does realtime memory emulation, plus CONSULT, all over the single USB. Makes tuning much faster, you can make changes while the car is running. On a loading dyno (i.e. not a dynojet) like a dyno-dynamics this is really cool: you can actually hold the engine at one load cell and adjust the timing and fuel on that one cell and watch the changes. Just a small plug (), if your near northern Georgia (USA), check out Dyno4mance sometime. This is a group of B14s getting tuned with a B14 Realtime ECU at Dyno4mance (scroll down past the car pictures). They have a AWD dyno-dynamics machine, and really know how to use it. Andrew does a ton of late model subbies and mitsus, but he could tune a lawn mower. Awesome facility.

http://www.sr20forum.com/members-rid...alhoun-ga.html

Btw, just one last suggestion. When your developing your SSM software, especially if you get the buad rate up to 9600 and your going to use it for ECU tuning, take some time to add in 'map tracing' if possible. Basically you just stream the RAM variables that are being used when the main fuel or timing maps are called, and plot out exactly where on those maps that your operating. The end result is something like this (this is Nissan DataScan, one of many Nissan CONSULT software packages) -scroll down a little for pics-:

http://www.sr20forum.com/calumsult/1...cing-cool.html

The green trace highlights exactly where the ecu is operating, and leaves behind a yellow trail showing where it was operating. When you tune, you just watch where the ecu is operating (or was operating if your doing pulls like on a dynojet), and just tune those load cells. Very handy.

That's really cool.

[b3lha]

Originally Posted by TomsSVX

So ur using a $45 converter and using Phil's parameters with success on a 92 ecu and wiring?? If so, I think you just found our problem

tom

All the evidence points to my converter having a problem. It just seems odd how it works perfectly on Joe's 92 and not mine. They are identical cars. As Nomake said, our experiments seem to indicate that the battery voltage is a factor on cars which exhibit the problem.

This is a simplified view of the problem and suggested solution as I understand it:

The signalling is done by varying the voltage between 0 and 5 volts. As a simplified example: The number 84 is 01010100 in binary. The ECU transmits this by applying 0v then 5v then 0v then 5v then 0v then 5v then 0v then 0v then 0v.

But in the real world the voltages aren't exact. The signal looks more like: 0.2v 4.8v 0.4v 4.6v 0.1v 4.7v 0.5v 0.3v 0.2v. To allow for this there is a tolerance built into the receiver.

Any voltage between 0 and 0.8v is counted as a binary 0 and any voltage between 2 and 5 is counted as a binary 1.

The problem ECUs presumably produce a signal where some of the values are outside the range of tolerance. Like: 0.2v 3.8v 0.9v 4.6v 0.1v 4.8v 0.5v 1.1v. We can't predict whether the interface will interpret these values as a logic 1 or a logic 0 and it may not even make the same choice each time. The receiver might receive 01110101 which is the number 117, completely different to the 84 the the ECU transmitted

Calum's solution uses a comparator which compares the signal voltage against a reference voltage (2v) and applies either 5v or 0v to it's own output.

The comparator will take the input 0.2v 3.8v 0.9v 4.6v 0.1v 4.8v 0.5v 0.3v 1.1v and output 0v 5v 0v 5v 0v 5v 0v 0v 0v.

In practice the compator output might actually be more like 0.1v 4.9v 0.1v 4.9v 0.1v 4.9v 0.1v 0.1v 0.1v. But most importantly it is regenerating the signal and the new signal should be within the limits of tolerance.

[Nomake Wan]

Oh yeah, Phil... Kashima-san's 'R' is "Data Points to Read." Look at the Binary version of the read command. Notice that the 'R' is the spot where one would use 00 to read one space, or 01 for two, or 02 for three, etc. That's why I originally used "30 30" as the last two ASCII digits... but it didn't work.

Just did some more driving around. When actually driving around, I can have my radio and headlights on and still get good data. When I turn climate control on (which I had on before; high A/C since it was daytime), the values get a little out of wack but not too much. I assume this is because it was 3 AM and the A/C didn't put much strain on the system keeping the interior at 34 F. Whereas my previous driving test was during broad daylight.

I just found it amazing that the one thing I could do to get the values really skewed while driving was to plug my laptop into the cigarette lighter. That put the most strain out of any single thing on it. Radiator fans do a little, lights do a little, radio doesn't seem to do any (strangely), climate control does a little... inverter does a LOT. Hahaha.

I was giving it some thought, though... the 92 is the oldest SVX. Is it possible that the wiring is just...getting old? That the electrical system has just aged more than the 94s and such?

Also, what do you think would happen if I were to bypass the VDC input and replace it with a 9V battery? Using an external power source instead of the car's. Would that fix it? Or is it really in the transmission voltage?

Racerx: I looked at the schematic for that adapter you're using. It looks the same as the converter box we're using, except that it has a diode on the +12V like Calum's schematic. Just a guess here, but I think it's because you're essentially using a new electrical system that you aren't experiencing the 92 problems...

[Trevor]

Originally Posted by Nomake Wan

But Trevor, doesn't that assume that the problem is that the unit is getting too much current? My experiment has proven that the exact opposite is the case. When not enough current is in the system, junk data happens. When this is compensated for (by spinning up the alternator), the data goes back to normal. It has been suggested in this thread that "alternator noise" is the cause for the problem. Again, not the case, since the data goes back to normal when the alternator output is increased.

I do not think it is interference in the form of additional current. I don't know how to describe it. Except that when a load is added to the SVX electrical system, the data that the converter receives becomes garbled (i.e. no longer complies with the standard the converter is based upon). When the load is removed, or otherwise compensated for, the data becomes compliant once more.

Sadly I cannot read Calum's schematic as I don't have the learning to do so, but maybe it operates under this principle?

EDIT: Friend of mine took a peek and told me what was different. So in Calum's diagram, he adds a capacitors to the voltage regulator circuit (between pins 2 and 3), adds a diode to the +12V input, and uses a comparator to make "absolute values" of the voltage levels. i.e. +5V = 1 and -5V = 0. That's an interesting way to go about it, removes the whole decision-making process and only hands out the binary data.

Trouble is, I can't really test it...

Nomake, you use the term "getting too much current". A device can not get, or be supplied with too much current (volume). Put simply, the current flowing in a circuit is dependent on the input resistance of the supplied item, which therefore fixes the current drawn. A normal source of supply can limit the level of current available, but not increase same without altering the supplied voltage.

A variation in voltage(pressure) as delivered from any supply, will affect the current regardless of the supplied device. A voltage regulator therefore protects the included device from voltage fluctions and the current drawn is completely dependent on operating requirements.

Which diagram was your friend looking at? I was referring to that covering the Subaru select monitot R8232. Here the capacitor between pin 2 and ground is included by way of additional smoothing and has no real significance. The diode in the +12 volt line would be included as a means of protection against possible reverse voltage and again is of little significance from an operational point of view.

[Nomake Wan]

My friend was looking at RS232-Integrated from the VWRX site, and comparing it against Calum's SSM_0 diagram. I guess he got the comparator values wrong (not -5 but 0), but other than that..yeah..

EDIT: Current, voltage... you're right, I'm not using the right term. Because I don't know which to use. All I can report is observations at this point... please look at my observation and pass judgement on that, rather than my wording...

EDIT2: Attached hex dumps of command 78123400 taken earlier today.

[Trevor]

Phil, have you read my last post addressed to you.

I note that comments continue regarding voltage variation as will occur in any supply from the car battery. Is your converter set up in any way dependent on the car battery as a means of supply and if so does it include voltage regulation? If not it should, if only by way of a precaution. The cost is peanuts.

[Nomake Wan]

Trevor;

I am fairly certain that Phil's box is made via the specifications on the VWRX site. Seeing as he says that in his HOWTO document. Found here:

http://vwrx.com/selectmonitor/RS232-Integrated-B.pdf

Going by that diagram, the circuit is powered by 5V which is converted from the car's 12V. Therefore yes, the circuit relies on the car's power, and it's a voltage regulator which steps down the 12V to 5V.

Phil's design:

http://www.alcyone.org.uk/ssm/howto.doc