This is something I've been meaning to post for quite some time, but just haven't had the time. This is pretty technical stuff, if this is greek to you its ok, just skip this thread and move on.
The goal of this is figuring out exactly what every single table in each ecu does, how it works, and documenting it. You can use the disassembly to help this, but its really really tedious and would help if more people worked on it. There's just tons of neat stuff that needs to be worked out and documented.
Alrighty, I've uploaded pretty complete disassemblies from some of the more common bins. All of these except the B14GA disassemble just fine with the current disassembler without any modification (the B14GA takes removing some of the interrupt vectors to run fine, I don't know whats causing it to go awol but it seems complete without them). Also included in each directory is the original bin for reference (again, the B14GA is slightly corrupt, don't go using it on an ecu). The actual disassembly is in the big txt files, and also included is the memory.txt file listing all the known addresses at the time of the disassembly. Know more than whats in the memory.txt? E-mail me and I'll rerun the disassembler (or get it back to the point I can just post it online).
The different disassemblies are here:
http://www.calumsult.com/calumsu/disassembler/
The processor manual (lists all the assembly commands, formats, etc) is in the docs directory.
Ok, so what can you use this for? Well, ultimately you could walk through exactly how the ecu does anything. Thats pretty dang hard though given how complicated the code is, coupled with the unknowns of the rest of the hardware of the ecu. Buuuut, it does offer insights about how specific parts of the ecu work, and it also helps to compare different code bases to see whats been changed between them. Ultimately you've got to stick an ecu in a car and see what happens when you start changing stuff. Really there's two different ways to use the disassembly: walking through code blocks analyzing exactly whats going on, or recognizing different patterns in the code without knowing what exactly is going on, but picking up enough to learn from, then just trying changing things on a running car (or bench simulator). The first is much more tedious, and I usually get lost pretty quick, so I stick to the second most of the time. Oh well.
So lets look at real code. There's three basic types of data used by the code: flags, bytes, and tables (1D and 2D). Flags are individual bits either set by the ecu in RAM for various events, or preset in ROM to enable to disable pieces of the code. Virtually all of these aren't documented, but it would be cool if more would. Nissan made lots of the code modular, so bits and pieces could be turned on and off for different model cars, etc. A good example of a cool known flag that isn't well documented is the O2 feedback flag for the B13/S13. Check out the newest B13 XDF file. I know what it does, but not _exactly_ what all its affecting. This is worth documenting, and also checking the B14 disassembly out to see if theres a similar flag (thats an easy task, I just haven't had time to do that).
Bytes are just individual variables used by the ecu, either in RAM or ROM. Examples are important stuff like the load (TP) in RAM, or the k-value (ROM), but also tons of other not documented stuff like various effects triggered at certain temperatures, etc. Check out the memory.txt files for known variables. Lets look at something specific. Here's the bit of code that has to do with the speed limiter, but pulled from the 91 code. This is intresting because we know the 91 has the speed limiter stuff turned off, but the code is still there (try it: set a speed limiter on the ecu, it won't be used). It would be neat to figure out how to turn it back on in the 91 code for use building a valet mode bin.
Code:
Code block address: C3B3 Length: 51 M:1 X:0
00C3B3 9C904200 ldm #0x00, 0x4290 ; Branch target from C388
00C3B7 ADD441 lda al, 0x41d4 ; Read from RAM: Vehicle Speed
00C3BA D00B bne 0xc3c7
00C3BC ADDE41 lda al, 0x41de
00C3BF 18 clc
00C3C0 690A adc al, #0x0a
00C3C2 CDCA85 cmp al, 0x85ca
00C3C5 B004 bcs 0xc3cb
00C3C7 1CB94101 clb #0x01, 0x41b9 ; Branch target from C3BA
00C3CB ADD441 lda al, 0x41d4 ; Branch target from C3A7, Branch target from C3B1, Branch target from C3C5, Read from RAM: Vehicle Speed
00C3CE 2CB9410213 bbs #0x02, 0x41b9, 0xc3e6
00C3D3 CD3180 cmp al, 0x8031 ; Read from ROM: Top Speed Limit
00C3D6 901F bcc 0xc3f7
00C3D8 AD4042 lda al, 0x4240
00C3DB CD4180 cmp al, 0x8041
00C3DE 901B bcc 0xc3fb
00C3E0 0CB94102 seb #0x02, 0x41b9
00C3E4 8015 bra 0xc3fb
Code block address: C3E6 Length: 70 M:1 X:0
00C3E6 18 clc ; Branch target from C3CE
00C3E7 6D7B80 adc al, 0x807b
00C3EA 9002 bcc 0xc3ee
00C3EC A9FF lda al, #0xff
00C3EE CD3180 cmp al, 0x8031 ; Branch target from C3EA, Read from ROM: Top Speed Limit
00C3F1 B004 bcs 0xc3f7
00C3F3 1CB94102 clb #0x02, 0x41b9
00C3F7 9C404200 ldm #0x00, 0x4240 ; Branch target from C3D6, Branch target from C3F1
00C3FB D8 clm ; m:0 x:0, Branch target from C3DE, Branch target from C3E4
00C3FC AD5C80 lda ax, 0x805c ; Read from ROM: Rev Limit
00C3FF 89490800 rla #0x0008
00C403 8D5641 sta ax, 0x4156
00C406 AD8280 lda ax, 0x8082
00C409 29FF00 and ax, #0x00ff
00C40C 8D5841 sta ax, 0x4158
00C40F ADDA41 lda ax, 0x41da ; Read from RAM: RPM (full scale)
00C412 2CB941040014 bbs #0x0004, 0x41b9, 0xc42c
00C418 CD5641 cmp ax, 0x4156
00C41B 901D bcc 0xc43a
00C41D F8 sem ; m:1 x:0
00C41E AD4142 lda al, 0x4241
00C421 CD8380 cmp al, 0x8083
00C424 9019 bcc 0xc43f
00C426 0CB94101 seb #0x01, 0x41b9
00C42A 8013 bra 0xc43f
Anyone want to walk through this? Its obvious that its comparing the current vehicle speed to the speed limiter, but there's lots of other stuff going on. What does the variable 0x85ca have to do with anything? Likewise 807b in the second block? (btw, the B13/S13 ROMs start in the ecu memory at 8000, so in the bin those variables are located at 05CA and 007B respectivley) Anyone want to walk through this in depth and play with it on a car? It would also help to compare this code block to whats in a bin that has the speed limiter turned on, like the U12 or B14.
This is an interesting side topic btw, lots of the B14 program is identical to the B13 stuff. This is cool, it makes it easy to tell if a certain table or variable functions the same on both ecus. This is especially handy when your looking for tables that are in different locations on oddball bins, like the USDM S14 or B14GA (that dude is just weird).
Okay, now for the fun stuff, the tables. There are tons and tons of different tables (almost all 1D), and this is what I'd really like figured out. Lets look at the 1D tables. When you start looking at known tables, there is a pretty obvious pattern. Whenever a table is called, there are three distinct steps that happen (although often other stuff mixed in):
1 - The a1 register is loaded with the index variable of the table. This could be coolant temp, load (TP), etc.
2 - The X register is loaded with the table address.
3 - A subroutine is called to fetch the data from the table. This subroutine performs interpolation too, so if the index is between points the subroutine calculates the interpolated value. Cool.
4 - The result is stored in RAM for use on down the road.
Here's a really straight forward example:
Code:
00939D ADC941 lda al, 0x41c9 ; Read from RAM: Coolant Temp (%)
0093A0 A22083 ldx #0x8320 ; Load X: Engine Cranking Pulsewidth
0093A3 205BFE jsr 0xfe5b
0093A6 8D6D42 sta al, 0x426d ; Write to RAM: Injection time MSB
A1 is loaded with coolant temp, X is loaded with the table location, the interpolation sub routine is called to fetch the data, then the result is stored in memory. Lots of time it isn't this straightforward though. Here's where it would help for more people to dive in. Search the bin for each time the interpolation subroutine is called, and you've got a list of every single table that might be used by the ecu. Try it.
There's tons of tables, but some don't seem to always be used. This is what I'd like: a list of every table, what the index is, any notes of what its involved with, then someone try and find out what it does. Again, the best way is just play with it on a car. You guys with Realtime ecus have the best tool for this: just add the table to your xdf and start playing with it while watching consult data. Many of these tables aren't important, but it would be nice to document everything. Also, it helps to compare what the table looks like between different stock bins to see if there are any hints as to what Nissan is changing them for.
So lets walk through an example of another unknown tables, again from the 91 bin:
Code:
Code block address: C4C2 Length: 27 M:1 X:0
00C4C2 2C9A410254 bbs #0x02, 0x419a, 0xc51b ; Branch target from C4B6
00C4C7 3C38808018 bbc #0x80, 0x8038, 0xc4e4 ; Read from ROM: Feedback Control Flags
00C4CC 3C9A41080C bbc #0x08, 0x419a, 0xc4dd
00C4D1 2C9A41100E bbs #0x10, 0x419a, 0xc4e4
00C4D6 3C9A410113 bbc #0x01, 0x419a, 0xc4ee
00C4DB 8037 bra 0xc514
Code block address: C4DD Length: 7 M:1 X:0
00C4DD 2C9A410132 bbs #0x01, 0x419a, 0xc514 ; Branch target from C4CC
00C4E2 8005 bra 0xc4e9
Code block address: C4E4 Length: 10 M:1 X:0
00C4E4 2C9A410105 bbs #0x01, 0x419a, 0xc4ee ; Branch target from C4C7, Branch target from C4D1
00C4E9 A26083 ldx #0x8360 ; Branch target from C4E2
00C4EC 800B bra 0xc4f9
Code block address: C4EE Length: 45 M:1 X:0
00C4EE ADD441 lda al, 0x41d4 ; Branch target from C4D6, Branch target from C4E4, Read from RAM: Vehicle Speed
00C4F1 CD3080 cmp al, 0x8030
00C4F4 901E bcc 0xc514
00C4F6 A25083 ldx #0x8350
00C4F9 ADC941 lda al, 0x41c9 ; Branch target from C4EC, Read from RAM: Coolant Temp (%)
00C4FC 205BFE jsr 0xfe5b
00C4FF 18 clc
00C500 6D8C42 adc al, 0x428c
00C503 9002 bcc 0xc507
00C505 A9FF lda al, #0xff
00C507 CDDD41 cmp al, 0x41dd ; Branch target from C503, Read from RAM: RPM/2
00C50A B008 bcs 0xc514
00C50C 0C9A4102 seb #0x02, 0x419a
00C510 0CB04102 seb #0x02, 0x41b0
00C514 1C9A4101 clb #0x01, 0x419a ; Branch target from C4DB, Branch target from C4DD, Branch target from C4F4, Branch target from C50A
00C518 4C03C6 jmp 0xc603
So this is a big code block, with two possible tables that could be called: 8350 and 8360 (0350 and 0360 in the B13 bin). The B14 bin also has similar code, and the same tables (E350 and E360). Comparing the B13 to B14, they're identical. Thats interesting, because Nissan changed many tables slightly between the two cars, I'm guessing based on the changes in cams, intake manifolds, emissions requirements, etc. But, they're different between the KA cars and the SR, but again the S13 is identical to the S14, even with slight changes to the motor. Looking at the U12 bin, its different from the other SR bins, but only slightly. Whats interesting is that the U12 is identical to the gtir. Weird. Ok, lets look at the code and see what we can dig out:
-There are all kinds of flags checked to enter the code at different points. One of them is the O2 Feedback flag in ROM.
-Also based on flags, either 8360 or 8350 is loaded. I don't know what the decision to select one over the other is.
-If 8350 is selected, it may not be used if the speed is less than the value at 8030. Assuming the conversion is the same as speed limiters (this is a good assumption), this stock is 8kph.
-The table is indexed vs coolant. Most of the tables are as it turns out.
-The result is added to another byte, and compared to the RPM, then flags are set based on this. Doesn't really tell me much.
So now we need to try adjusting these tables on a running car (or simulator). I'll add that to the list of get-around-to-it, but comparing how little they've been changed between the stock bins, they aren't particularly important tables so its not high on the priority list. Still, anyone want to play with these and see what they do?
Ok hackers, have fun.
.
