Memory dump of ECU

[Trevor]

Originally Posted by b3lha

At the higher speed, the pulses of data are shorter and perhaps more prone to interference.

Possibly, higher speed/higher frequency. However in respect of the capable speed of switching available, the speeds involved are insignificant.

Yes, in respect of becoming distorted at/within the receiving end.

Have you read my ugly post? Worth a look.

[Calum]

Originally Posted by b3lha

Thanks. You're really helping us out here.

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.

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?

That's really cool.

No problems. I love fooling around with these old ecus.

I've already got a copy, thanks, but I don't use it. I found there was so much missing external hardware (the rest of the ecu) that I couldn't really tell what the ecu was trying to do. The code is just so dang complicated I get lost really quickly. I have to take it really slow and analyze one piece at a time. Nissan took the same approach that I think Subaru did (an probably every other car manufacturer) to ecus and code: its modular, and if you look at different models they all work pretty much the same and use the same code base. On the Nissan ecus, there are sections of code there for equipment the car may not have, and they use a series of flags to turn on and off blocks of code. Very efficient.

What I did was build a bench engine simulator, which is super handy. Makes it a ton easier to write software for interfacing to the ecu too, much easier than writing code in your car. The hardest part is simulating the CAS signals from the distributor (or whatever the subbie equivalent is), the rest are simple trim pots (actual resistance for the temp senors, voltage dividers for the maf, tps, 02, etc). Then I edit a table and watch what happens (if anything), then try to work backwards through code to see if I can figure out what its doing. Nissan has a command as well for watching variables anywhere in memory. Thats really handy for figuring all the tables out too.

Nothing beats dynamic testing on a real car though. Going out late at night, tweaking tables, seeing if you can tell a response in the car. Fun stuff.

I don't make a 27C1028 board. Nissan never used that. I could make one though, its not very complicated. Kashami has a schematic on his website, so its really just a matter of doing the pcb artwork. I'd really need an ecu and the piece of a harness that connects to the ecu (I need to be able to power up the ecu and talk to it to test it). If there was interest I could roll a Subaru Realtime, but I'm not sure it would be worth the investment.

[Trevor]

Thank you Phil, for a thread which is unique.

You have pitched your topic beyond those with the restricted intent of massaging ego. Many threads quickly become so entangled, that all sense of objectivity becomes buried.

[b3lha]

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.

The local electronics shop doesn't have what I need, so I'm going to mail-order the components today. But I have a question for someone who understands electronics.

In the top left of Calum's diagram he uses a pair of resistors to set the reference voltage of the comparator. I understand the theory behind it, but I'm wondering whether it would be better to replace them with a small potentiometer, something like the one below.

http://uk.farnell.com/jsp/search/pro...sp?sku=9353240

I would connect it in the same way, the track running between 5v and ground and the wiper connected to the comparator input.

This would allow me to adjust the threshold (ie. the voltage that the bit must rise above to be regarded as a 1 or fall below to be regarded as a 0), to find the sweet spot where the signal becomes clean.

Does it matter if I use a 10K or 20K trimmer?

Phil.

[Calum]

Sure, you could do that. Just measure the voltage point that works the best when your done. A 25 or 10 turn won't make a difference. That just gets you higher resolution, but I think you'll discover that you've got a pretty broad voltage range that works (your not exactly trying to set down to the mV level). Even a single turn would work just fine.

Btw, pin out for the M37791:



Source:

http://www5a.biglobe.ne.jp/~miner/Impreza/ecu.html

I suspect the pins that are marked Not Used A & B (NUA,B) are actually used to select external memory usage. I'm not sure what pins 42-49 (A16-A23, WEMP/REMP) do. The Nissan ECU has them setup weird, and I can't find another 77xx mcu that has something called WEMP/REMP. If you get a chance, can you trace out the memory pin connections on your ecu? The jumper that is cut on the subbie ecus, what does that actually connect to?

[b3lha]

I has been mentioned that 1953 baud (bits per second) is not really fast enough for data logging. We now know one method of activating the ASCII mode which uses 4808 baud, but each message requires twice as many bits, so there isn't much improvement in speed.

From looking at the disassembled code. I can see how the baud rate is set.

For binary mode, the command is "LDM #$7f, $31" at address FB73.
This command means "store the hex value 7F in the memory at hex address 0031.

The CPU calculates the baud rate from the value you store at this address. From the datasheet, the formula is B=(C/(n+1))/16. B is the baud rate you want, C is the clock speed of the CPU (approx 4000000Hz) and n is the value that you store in address 0031. The formula can be simplified to B=250000/(n+1)

For the binary mode, it stores the value 7F hex (127 decimal) B=250000/(127+1) = 1953.1

For ASCII mode, it stores the value 33 hex (51 decimal) B=250000/(51+1) = 4807.7

It is possible to change the CPU baud rate on the fly by writing a value of our choosing to address 0031. I first setup the hex comm tool to the binary mode 1953 8E1. Then I send 78003100 to read address 0031 followed by AA003133 to write 33 hex. The data coming back from the ECU changes immediately to nonsense, because the baud rates are mismatched between the laptop and ECU. Then if I change the laptop to 4808 8E1, the data becomes good again . It's now sending binary mode at 4808 baud It is in fact possible to set the baud rate even higher. The value 19 hex will give 9615 baud.

Taking things to extremes, we could write 00 and get a speed of 250000 baud. However, there is a practical limit. Whenever the laptop sends a byte of data to the ECU, the CPU has to stop what it is doing, read the data, process it, and then go back and pick up where it left off. The more data we send per second, the more time the ECU will spend processing that data and the less time it will have to do all its normal functions. We know that 4808 is a safe baud rate because it is used for ASCII mode, but we don't know how much higher we can push the speed without impacting the normal functions of the ECU.

That's the theory, but I am still experimenting with it. Sometimes the data is not coming back as I expect. I have no idea why at this stage.

Phil.

[b3lha]

Originally Posted by Calum

Sure, you could do that. Just measure the voltage point that works the best when your done. A 25 or 10 turn won't make a difference. That just gets you higher resolution, but I think you'll discover that you've got a pretty broad voltage range that works (your not exactly trying to set down to the mV level). Even a single turn would work just fine.

Thanks. I'll give it a try.

Originally Posted by Calum

Btw, pin out for the M37791:

Source:

http://www5a.biglobe.ne.jp/~miner/Impreza/ecu.html

I suspect the pins that are marked Not Used A & B (NUA,B) are actually used to select external memory usage. I'm not sure what pins 42-49 (A16-A23, WEMP/REMP) do. The Nissan ECU has them setup weird, and I can't find another 77xx mcu that has something called WEMP/REMP. If you get a chance, can you trace out the memory pin connections on your ecu? The jumper that is cut on the subbie ecus, what does that actually connect to?

I have no idea what those pins do. I guess that WEMP/REMP mean Write and Read something, but I don't know what. Next time I have a reason to take the ECU out, I'll see if I can trace them. Unfortunately I don't have an ECU on the bench, it's buried behind the dash of the car and it's a real b**ch to get at.

[Nomake Wan]

I just knew that the baud rate could be set manually! Though Kashima didn't detail the method like you did, he believed strongly in being able to reset the baud rate and keep Binary mode working. Now it's proven. Phil, you are a god.

Sadly, while I brought the tool with me to the old-school Subie meet, most everyone there either had OBDII, or a non-stock engine computer. One guy who came in a Brat also had a stock 93 Legacy Turbo which he didn't bring, which sucks 'cause it would've worked on that. You should've seen me upside-down in this one dude's impreza trying to find the select monitor port. "Well I see the ECU plug, but where's the select monitor? Is this stock or what?" "No, it's a PowerFC." "..........oh."

Good luck with the circuit. I wait idly by for further wonderful news.

[Nomake Wan]

Just ran a test. Results:

Initially, it appeared that everything worked perfectly. I used the value "19" and set the baud to 9615. I got the correct data at a much faster speed. But as soon as I sent any command (stop or otherwise) the data ceased. For instance, I would be receiving the information for 0031 and would send '78123400' and suddenly everything would stop.

That's no good. I couldn't get the data to come back again, so for now it looks like I have to leave it up to the experts..

[b3lha]

Originally Posted by Nomake Wan

Just ran a test. Results:

Initially, it appeared that everything worked perfectly. I used the value "19" and set the baud to 9615. I got the correct data at a much faster speed. But as soon as I sent any command (stop or otherwise) the data ceased. For instance, I would be receiving the information for 0031 and would send '78123400' and suddenly everything would stop.

That's no good. I couldn't get the data to come back again, so for now it looks like I have to leave it up to the experts..

Don't despair. The exact same thing is happening to me. That's one reason I'm still experimenting.

It definitely works at 4808. After writing 33 to 0031 and changing the baud rate to 4808. I can send 78123400 and get good data back.

I've been trying to work out other baud rates to try. Although you can enter any baud rate in the Hex Comm Tool, some baud rates are not possible on a PC serial port. It will use the nearest possible rate to what you have asked for. When you set the rate to 9615 on the PC, I think the PC will actually use 9600.

The PC sets its baud rate using the formula B=115200/x. For binary mode, the ECU baud rate is 250000/128 = 1953.1 and the PC baud rate is 115200/59 = 1952.5. As you can see, the baud rates are not the same, but they are close enough.

The trick is to find integer values of x and y where 250000/(x+1) is approximately equal to 115200/y. I don't know for sure how close they have to be.

The ones that look most promising to me are:

19 hex = 9615 baud on the ECU and 12 dec = 9600 baud on the PC
24 hex = 6757 baud on the ECU and 17 dec = 6776 baud on the PC
26 hex = 6410 baud on the ECU and 18 dec = 6400 baud on the PC
31 hex = 5000 baud on the ECU and 23 dec = 5009 baud on the PC
33 hex = 4808 baud on the ECU and 24 dec = 4800 baud on the PC


There are a whole bunch more at lower baud rates, but since I have seen 4808 baud working, I don't see the point in going any slower. Unfortunately, it seems that the faster you set the baud rate, the greater the discrepancy between what the ECU can support and what the PC can support.

[Calum]

Use a usb-serial adapter based on an FTDI chipset. You can set those to any baud rate, even weird ones. You can buy them direct from FTDI (www.ftdichip.com, click on webstore link) in Britain, and mouser carries them in the US. They're cheap too.

They even have Linux drivers.

[b3lha]

I need some more electronics advice.

I tried to build a comparator circuit similar to Calum's design. I substituted an LM393 comparator in place of the LM358 op amp - which may well be the problem, although to me they appear interchangeable.

My circuit is attached and the datasheet for the LM393N can be found at http://www.farnell.com/datasheets/63471.pdf

I've set the potentiometer at 2v. I expected that, if the input is >2v the output would be 5v and if input if <2v the output would be 0v.

But in fact, if the input is >2v the output is 5v as expected, but if I drop the input below 2v then the output only drops to 4v, which is not what I want.

Any ideas? Maybe I should go and buy an LM358?

edit: I just noticed that my diagram is a little confusing. Don't mix up the outline of the IC with the wires, I should have done them in a different colour. The output is pin1, the inverting-input is pin 2, the non-inverting input (reference voltage) is pin 3, the ground (Vcc-) is pin 4, power (Vcc+) is pin 8. There is a second comparator on the IC using pins 5,6,and 7. I have connected its inputs 5&6 to ground.

[Calum]

The 393 has an open collector output. On your output, directly connect the output of the 393 to the input of the max232 (remove the 4.7k and replace with a wire), and connect the 4.7k from the output to +5V (this is a pull-up resistor).

Make it look like the non-inverting example on the first page of this datasheet, but without the 10M resistor (that just adds hysteresis, not needed in this application).

http://i2c2p.twibright.com/datasheet/LM193.pdf

Go ahead and tie your unused input pins (5&6) to the used input pins too.

[Calum]

Just noticed you've got the inverting and non-inverting inputs swapped. Connect your circuit 393 like this:

1 - output A - direct to max232 input, with pull-up
2 - inverting input A - connect to your potentiometer setting the reference voltage
3 - non-inverting A - connect to input (TxD)
4 - GND
5 - non-inverting B - no connect, or connect to pin 3
6 - inverting B - no connect, or connect to pin 2
7 - output B - no connect
8 - +5V

[TomsSVX]

should be getting my connector built soon... Will keep you updated on my findings

Tom