Idiots guide to disassembly and reading opcode...

Fusion Ed · Post by **Fusion Ed** » Thu Oct 11, 2007 8:28 am

I need help!!

, or some guidance. I want to learn to understand and the opcode used in the 6303 cpus used on Nissan ECU's. (and others once I have the hang of it) I am not totally green, I can for example program ASM on the microchip pic, but there is plenty of documentation so its easy to learn, the 630x cpus are ancient and to find anything about them is by comparison, pretty hard work.
I have found a book which I shall order shortly, however I have been playing with a disassembler called DASM which I have run the file through, and come up with this:

http://www.fusion-motorsport.co.uk/cpu/stock.lst

and I also found an opcode list:

http://www.fusion-motorsport.co.uk/cpu/6303

I just wondered if anyone would spare a few moments to explain what goes on now, how typically the ecu code is structured, and if possible what bits of code does what, like injector control as an example for output and sensors such as temp or airflow for input.

Any help would be great, and I think this would be an interesting topic for others also curious how this kind of stuff works.

Ed

GZ@hybridka · Post by **GZ@hybridka** » Thu Oct 11, 2007 11:10 am

Cool post, we need more people that know something about motorola 8 bit assembly language!

I am in no way capable of giving you even a decent crash course, I too am pretty much a beginner, starting off only using a subset of the language maybe two years ago now.

The only past experience I had was with PIC as well, and not even much assembly at that (I used JAL and some PIC asm). The learning curve of the motorola assembly is somewhat steep, but it is fruitful. The motorola cpu programming model is widely used in the automotive efi industry in different variants, as you well know, so knowledge is this area is valuable

Before you start rewriting/confirming the code you are going to need simulation. This wouldnt be necessary if you were pro, but thats not what this is about. Because there is no hope for any sort of full software simulation of the ECU code (some unknown external hardware and functions), you must rig up at least a semi-complete bench simulation.

The bench simulation provides a running code from which you can update and debug with the use of rom emulation and serial debugging tools (already provided with consult or Nistune).

The most difficult part of the ECU hardware simulation is the function of the crank angle sensor. Because our nissan CAS are complex units, outputting high resolution signals, the only feasible way to simulate this unit on the bench (aside from spinning an actual CAS with a motor) is to use a microcontroller.

The one I use is designed for the ka24e(de)/sr20de CAS and the information I used to build it was provided by a nice guy named Erich on the ECCS-TEC forums.

You can start analyzing the code before this, but before you do any real code reconfiguration your going to need to watch and confirm some ram bytes.

Here is the complete hd63b03ycp datasheet. Opcodes and the programming model is provided pages 156-161. Print this datasheet out and put in a good binder. This binder should also include as many hardware datasheets you can find for your ECU, and any references you may need (such as large easy to read binary/hex/decimal conversion chart).

http://www.hybridka.com/misc/hd63b03ycp.zip

GZ@hybridka · Post by **GZ@hybridka** » Thu Oct 11, 2007 11:20 am

Got cut a little short there with a laptop freezup , but was able to restore my session without any loss of my post (thank you firefox).

Ill make a post later on with more information.

Fusion Ed · Post by **Fusion Ed** » Thu Oct 11, 2007 12:00 pm

What a great start - Thank you!

I have printed out that document and shall read over it. Making a CAS simulator shouldn't be too hard. I shall have a look at that tomorrow

Thanks for the input I do appreciate it

Ed

GZ@hybridka · Post by **GZ@hybridka** » Thu Oct 11, 2007 12:07 pm

I have a cleaner datasheet than that one somewhere, I just noticed thats not as nice as the one I have printed out here.

What ecu are you planning to work on, mainly? I dont recognize that disassembly you posted, though it seems valid at first glance.

Matt · Post by **Matt** » Thu Oct 11, 2007 12:20 pm

Let me know what ECU you are going to start with and I can provide a symbol list

Over the last few days I have written some scripts to take the RAM address information (consult table) from my Header files used in the NIStune autopatch code and combine this with the ROMEditor address file address information to create a symbol table for DASMx

This is your base symbol information for 6303 based ECUs which came from one of the forums

; Generic HD6303XP (DIP) Symbol file (ECU independent)
; 192 bytes RAM (0x00-0x1F registers)

cpu 6303
org 0xC000

symbol 0x0001 Port1_DDR
symbol 0x0003 Port1
symbol 0x0008 Timer_control_status1
symbol 0x0009 FreeRunningCounterMSB
symbol 0x000A FreeRunningCounterLSB
symbol 0x000B OutputCompareRegMSB
symbol 0x000C OutputCompareRegLSB
symbol 0x000D InputCaptureRegMSB
symbol 0x000E InputCaptureRegLSB
symbol 0x000F Timer_control_status2
symbol 0x0010 Rate_control
symbol 0x0011 TxRx_control_status
symbol 0x0012 RxDataReg
symbol 0x0013 TxDataReg
symbol 0x0014 RAM_Port5_control
symbol 0x0015 Port5
symbol 0x0016 Port6_DDR
symbol 0x0017 Port6
symbol 0x0019 OutputCompareReg2MSB
symbol 0x001A OutputCompareReg2LSB
symbol 0x001B Timer_control_status3
symbol 0x001C TimeConstantRegister
symbol 0x001D Timer2UpCounter
symbol 0x001E RegRAM
symbol 0x001F RegTestOnly

; Reset and interrupt vectors

vector 0xFFFE RES_vector RESET_entry
vector 0xFFEE TRAP_vector TRAP_entry
vector 0xFFFC NMI_vector NMI_entry
vector 0xFFFA SWI_vector SWI_entry
vector 0xFFF8 IRQ1_vector IRQ1_entry
vector 0xFFF6 ICItmr_vector ICItmr_entry
vector 0xFFF4 OCItmr_vector OCItmr_entry
vector 0xFFF2 TOItmr_vector TOItmr_entry
vector 0xFFEC CMItmr_vector CMItmr_entry
vector 0xFFEA IRQ2_vector IRQ2_entry
vector 0xFFF0 SIO_vector SIO_entry

Then say for the EK10 MA09ERT the address file entries

symbol 0xC0F0 HIGH_FUEL
symbol 0xC0E0 TP_SCALE_FUEL
symbol 0xC0D0 RPM_SCALE_FUEL
symbol 0xC690 HIGH_FIRE
symbol 0xC460 TP_SCALE_FIRE
symbol 0xC450 RPM_SCALE_FIRE
symbol 0xC5C0 VQ_MAP
symbol 0xC5A0 TEMP_CONV
symbol 0xC4A0 DWELL_TIME

It gets used by DASMx to make the output lst cleaner. Symbol file must be the same name as the binary you are disassembling

You can also add symbols for the RAM entries too once those are found (This is what I'm trying to hunt down for this particular ECU)

I'll grab some datasheets and opcode guides i have collected from home. They describe each opcode operation in detail

The problem with DASMx is that it doesn't update all the addresses with the symbols above. I've written some PERL scripts to substitute symbol information for all address entries. I'll post those up too

I've written quite a few tools to parse assembly and assist in searching for routine pattern searching which is why I've been able to trace down addresses from different ECUs with similar code structure

Fusion Ed · Post by **Fusion Ed** » Thu Oct 11, 2007 12:27 pm

Thats because its a super super rare car!

Its a Nissan March Superturbo.

Chassis: EK10
Engine: MA09ERT (930cc i4 8v supercharged & turbo charged)

looks like this:
http://www.fusion-motorsport.co.uk/imag ... d/img1.jpg
Engine looks like this:
http://www.fusion-motorsport.co.uk/imag ... d/img2.jpg
And I rebuilt if from a shell that did look something like this:
http://www.fusion-motorsport.co.uk/imag ... d/img3.jpg

It now has a GT28R turbo and makes nearly 200bhp..

Now I know everything about the car I want to know everything about the ECU, hence this topic

GZ@hybridka · Post by **GZ@hybridka** » Thu Oct 11, 2007 12:52 pm

Sweet little car, not something seen in these parts for sure.

I see all the tell tale signs of the modular building blocks of ECCS in that code. There is a lot that you can do.

If you sent or posted a stock .bin I could go through and help add to the RAM list.

Fusion Ed · Post by **Fusion Ed** » Thu Oct 11, 2007 12:57 pm

Matt I missed your post just read it now sound great. I shall add that and see what happens.

Also the stock.BIN is here.

http://www.fusion-motorsport.co.uk/cpu/stock.BIN

Fusion Ed · Post by **Fusion Ed** » Thu Oct 11, 2007 1:04 pm

OK so I updated the stock.sym file and have re-run the disassembler file. All new updates have been also put online to replace the others so you can now have a look

http://www.fusion-motorsport.co.uk/cpu/stock.sym
http://www.fusion-motorsport.co.uk/cpu/stock.BIN
http://www.fusion-motorsport.co.uk/cpu/stock.lst

Matt · Post by **Matt** » Thu Oct 11, 2007 1:06 pm

I've got Eds ECU here now so have to solder a connector to it on the bench (the plugs are similar size to Z32 but plug in type like Z31 and I dont have anything like that here)

I've got some RAM addresses so far, once I get home will post them. Got RPM, TP, Temp, battery so far

I use the DTC reporting code sometimes to locate what the RAM addresses are since failures with input sensors always flag errors and DTC addresses have a standard 'map' of codes so you can work out which sensor flags which DTC bit mask bit

GZ@hybridka · Post by **GZ@hybridka** » Thu Oct 11, 2007 1:33 pm

I use the DTC reporting code sometimes to locate what the RAM addresses are since failures with input sensors always flag errors and DTC addresses have a standard 'map' of codes so you can work out which sensor flags which DTC bit mask bit

Whoa, crazy good tip. Never thought of that.

This March Superturbo code is very similar to S13 ka24e.

Port 6 is set entirely to output and it looks as if a few pins on that port are connected to emissions related solenoid. That would be something to check out, they could be reconfigured.

Speed based rev limiter (launch limiter) looks relatively easy to do as well.

Matt · Post by **Matt** » Thu Oct 11, 2007 2:29 pm

Yeah i noticed that too with the KA24E, which is what I used to start working from with my disassembly... since the maps all start at the beginning similar to the MELPS 77xx code

This one starts from C000 offset for some reason. I dont know why they do that. The A31 Cefiro is the same also starting from same address

Eds main concern is finding where the supercharger gets triggered from in the code.

About 4000rpm it kicks in, so theres a constant there somewhere which gets compared against about 0x50 (hex) and then turns on the output

GZ@hybridka · Post by **GZ@hybridka** » Thu Oct 11, 2007 2:48 pm

Well, what I would do is trace it back on the hardware side first.

It should go ecu connector pin > transistor > resistor > 6303 pin.

It may use its own transistor, or it may be a part of a transistor array. Judging by everything else, if it does use a transistor array it is probably PU4424.

I have the datasheet on that PU4424 as it is the same as the ka24e/de/sr20.

Once the 6303 pin is found, it would be simple to work back the switching logic.

Matt · Post by **Matt** » Thu Oct 11, 2007 6:33 pm

pin 6 i think ed was saying in the email from last night. i'll trace it through...