Has anyone on here disassembled the 413 code?

[olafu]

Ctrl + F8 , "Engine_sim crank and cam simulator". You can select square, triangle or sine wave.
but if it doesn't work, don't forget Audacity

[Hairyscreech]

Thanks, seems to all be working on the daqarta front but I'm still not getting any life from the ECU.

How do you have your VR sensor input wired up? I have a feeling there is some fundamental of what I am trying to do that I am not understanding at the moment.

At the moment I have tried direct to left channel and ground on the sound car output, I have also tried it looped and connected to the left channel.
If I do either I can detect the crank signal with the oscilloscope but as soon as I power the ECU up then I pretty much loose the signal and the ecu just sits there powered up doing nothing.

[olafu]

Did you use an isolation transformer? Any fault codes?

[Hairyscreech]

No Isolation transformer. I assume that could be part of the problem.

In fact nothing in there at all at the moment, I was hoping the 5v output from the car would be enough to trigger things without any trickery.

I have a few transformer coils scavenged out of an old power supply.


Not checked for fault codes yet but I have the CEL hooked up to an LED and its off, at this stage the issue is clearly a lack of crank signal.

[olafu]

If you are using 413 ecu, CEL should be on, when ecu is powered up and waits for crank signal. Ecu needs strong power supply, i'm using 15V / 6A from old laptop. 12V / 1A was too lame. Voltage should be something between 12...15V.

[Hairyscreech]

Its a 484 v8 ECU.

I have a 300w desktop PC power supply as a bench test supply so it is hooked up to the 11.97v from that. Mostly cause it gives a very well regulated 33.v, 5v and 12v.
12v rail is 19A

I believe I can pull 15v out of the supply as well with some trickery but I'm surprised if the 11.97v is not doing it.

Certainly enough power to run and heat a wideband o2 gauge and sensor so that 3A minimum.

[Hairyscreech]

Ok, stuck a small transformer into the crank line to decouple the sound card output and that allows me to maintain a waveform of about 5v peak to peak on the scope when the ECU is powered up.

Also am now able to get the CEL to light.

Going to try scanning it with INPA.

[Hairyscreech]

Ok, INPA worked fine.

The obvious mistake became clear when I started scanning the ECU though.

I put my ostrich back into the E30 to do a test on a break upgrade and a new AEM wideband and because of that I dropped the stock ROM chip in place on the ECU.

A stock ROM chip complete with EWS.



Dropped my old 413 chip in and I now have life. I will burn a 404 BIN to a spare chip and then we can start some ECU hacking with a proper unit running on the bench.

[Hairyscreech]

General FYI - the square wave from daquarta is enough to create a cam sync if just pin 17 is hooked up to the right channel and daqarta is set to 1-0 every 360 degrees. Correct cam offset is 40 degrees and I have the Vanos table switching functional.

You can then switch off and on the right channel signal to trigger the wasted spark mode.

[Hairyscreech]

I have just used my bench test ECU to take hit traces of the full binary in tuner pro under both running (1500rpm) and waiting for crank trigger conditions.
I have dropped these onto the "413 and 506 maps and notes" excel file and it clearly highlights the areas of code that are running and not running.

Now we have the ECU forced to run off the external ROM we can see a lot more of the programs hit tracing than we could before.

I am going to try tying some of this back to the disassembly and see if it helps highlight the sections of code that are running in different conditions.

This should be a help to highlight the key bits of code for different functions. If I can force this bench ECU to different fault modes, rev limiter, wasted spark etc then trace what is being accessed then maybe we can confirm which bits of code we should be trying to reverse engineer.

Update - I have found that only 2 tables are used by the ECU while it is waiting for a crank signal and these are a pair of currently unknown tables.
D5B2 and D95B, one is a "27" identifier and the other "CF".
D95B seems to be active in all conditions as well.

If we understand the ID values right then "INTMEM 27" is where the value for this table is stored, if so the cross-references suggest that this is something to do with the Idle control.
Is there any way we can confirm this?

[olafu]

D5B2 is temp sensor normalizer table. Same table is used for IAT and CLT sensors. Looks like raw adc-value is stored in "27".

I did some research:
0x3C25-3C47 is where IAT value goes to INTMEM_D3 and CLT goes to INTMEM_D7. Looks like the map reading happens, when it calls subroutine ROM_4154. Then reads normalized value from INTMEM_49 and stores it to INTMEM_D3 or INTMEM_D7
I don't exactly know how the temperature ends up to INTMEM_49, but ROM_4154: ljmp ROM_20C7 -> ROM_20C7: ljmp ROM_33C2.
And looks like ROM_33C2 is common subroutine to use 2D-maps.

[Hairyscreech]

I started marking the ROMs on the disassembly with an A_"name" for active all the time and B_"name" for active only when waiting for crank signal.
This has the advantage of making the fully active ROMs hit the top of the list.
I have a ton more data to add in to complete the A_ list but the B_ list is complete, the program flow for "waiting for crank signal" is relatively complete.
Taking a hit trace of the whole ROM has also showed a few times when the code jumps. The hit trace seems to continue a couple of values past the last code execution (expected due to the need to read the values after a JN instruction in order to get the location) so as long as you check the hit trace against the end of a ROM or any JNx instructions then you can often see when the code has run a whole ROM or jumped half way through.
I tried to mark a few of these in the disassembly.


Your last post makes a lot of sense for a few reasons:
IAT and CLT have identical resistance curves, I plotted them out and I am sure they are the same, they are also the same as the older M20 engines sensors.
I have had D7 marked as a possible CLT storage location for a while, it fits with our understanding that the ID for the values is actually its physical RAM location. See snippet below of that area of the RAM with some idle values grabbed from the car, I put my notes in bold. They all seem to be realistic.

INTMEM:00D0 11 01 - INTMEM_D0_RPM? - :dw 111h ; A_ROM_2F62+C3r
INTMEM:00D0 - ; ROM_528B_ML_VANOS_Related? - :ROM_5331r ...
INTMEM:00D0 - ; RPM is only first bit = 11h = 17. X40 for RPM = 680rpm which is idle when this data was taken
INTMEM:00D0 - ; Only one instance of D0 being written to in ROM_916C
INTMEM:00D0 - ; Only one instance of D1 being written to in ROM_A0F6

INTMEM:00D2 00 - INTMEM_D2_MAF? - :db 0 ; ROM_916C_ML_Diagnostic?:ROM_945Aw
INTMEM:00D2 - ; ROM_9BDF+98r

INTMEM:00D3 53 - INTMEM_D3 - :db 53h ; B_ROM_3C1B+17w
INTMEM:00D3 - ; ROM_528B_ML_VANOS_Related?:ROM_5349_Table_Read?w ...

INTMEM:00D4 49 - INTMEM_D4_IAT? - :db 49h ; ROM_2080_Main_ROM+2A43w
INTMEM:00D4 - ; ROM_5B7D_ML_Acell_Enrich_Related?+5Ew ...
INTMEM:00D4 - ; x*0.75-48 means ~11 deg C

INTMEM:00D5 31 - INTMEM_D5_LOAD? - :db 31h ; ROM_2080_Main_ROM+2913w
INTMEM:00D5 - ; ROM_528B_ML_VANOS_Related?+3DBr ...
INTMEM:00D5 - ; Load = 2.45, about right for idle condition given rpm and air flow

INTMEM:00D6 31 - INTMEM_D6_TPS? - :db 31h ; ROM_2080_Main_ROM+2916w
INTMEM:00D6 - ; ROM_916C_ML_Diagnostic?:ROM_93AFw

INTMEM:00D7 AF - INTMEM_D7_CLT? - :db 0AFh ; ROM_2D02+Fr
INTMEM:00D7 - ; B_ROM_3C1B+27w ...
INTMEM:00D7 - ; CLT = ~ 83 deg C (X*.75-48)

INTMEM:00D8 CE - INTMEM_D8_VOLTS? - :db 0CEh ; ROM_528B_ML_VANOS_Related?:ROM_5566w
INTMEM:00D8 - ; ROM_6C79_ML+C4r ...
INTMEM:00D8 - ; if factor is X/15 then this would make voltage about 13.7v


Your note about 0x33C2 being the 2D table read has merit, I had not considered that there must be a different section of code for reading the 2D, 3D and transfer functions as they all need slightly different interpretation.
It explains why there are about 7 table read ROMS.

One thing I am not sure about is the D3 for IAT, I had thought it was D4, I could be wrong or maybe its both?
They are numerically similar after all and it could just be a filtered and unfiltered value.

[olafu]

D3 follows IAT sensor input, D4 not. So, i'm pretty sure D3 is air temperature.

0x3C25 is active only in stopped engine. (waiting for crank).

[Hairyscreech]

Go with D3 then. probably a mistake I have picked up somewhere.

0x3C25 did not trace as active when the ECU was running. I will have to look into that.

[olafu]

Hello again!

I think i have some information for 0xE67E:

code "ld SP+2, #xxxh" occurs repeatedly just before "lcall ROM_20C7" or "lcall ROM_20CD".
It is pointer loading for 0xE67E map lookup table.

If you want to find different parts of code by specific maps, you can choose that map from 0xE67E, note the location, and substract it by E67Eh. You get pointer value in hex. It leads you in to the function which is using that specific map.

Example:

0xE0C3 - Ignition dwell map - 12x7 - D0xD8. Address founds from 0xE732, so: E732h - E67Eh = B4h. It's 180 in decimal, but table is 16bit, so it's 90th address in 0xE67E table. Let's find it from code:

find "ld SP+2, #0B4h" or in hex: "A1 B4 00 1A"

and it founds from ROM_692A.

Code: Select all

ROM:692A                 ld      SP+2, #0B4h ; Load SP+2 (INTMEM_1A) with #0B4h (pointer for 0xE67E table)
ROM:692E                 lcall   ROM_20CD ; Call 3d map routine

Other example:

0xDBB2 - TPS based limp mode map - 6x7 - D0xCC. Address founds from 0xE6EE, so E6EEh - E67Eh = 70h

lets find "A1 70 00 1A" or "ld SP+2, #70h" from code...
... and it founds from ROM_9A4A

I'm not 100% sure about that, but it seems ok. So far it has worked on every map. IDA can show this pointer in different styles, so by searching by hex strings is more reliable way.

INTMEM_1A (SP+2) is also used as general purpose register, but most of all "ld SP+2" 's are this pointer loading.

[olafu]

Let's dig this thread up again.

Vehicle speed dependent rev limiter in -965.bin

It has two parts:

Part 1 - Get rev limiter value from 2d table and store it in to SRAM:

Code: Select all

ROM:5B61	A1 86 00 1A	ld      INTMEM_1A, #86h		; Pointer loading for map lookup table (1)
ROM:5B65	B3 01 7B 18 1C	ldb     INTMEM_1C, RAM_187B[]	; Loading vehicle speed data from SRAM to INTMEM_1C (2)
ROM:5B6A	EF 5A C5	lcall   ROM_20C7		; 2D map routine
ROM:5B6D	B1 A0 1C	ldb     INTMEM_1C, #0A0h	; Multiplication factor loading (3)
ROM:5B70	7F 01 49 00 1C	mulub   INTMEM_1C, (INTMEM_49)[]; Multiplication
ROM:5B75	C3 01 A8 18 1C	st      INTMEM_1C, RAM_18A8[]	; New rev limiter value is stored in to SRAM: 0x18A8

Part 2 - Actual "rev limiter part". This is similar to -623.bin, but in 623.bin the rev limit is fixed value in ROM. (***)

Code: Select all

ROM:ADE9	8B 01 A8 18 40	cmp     INTMEM_40, RAM_18A8[]	; Engine speed is compared to revlimiter value
ROM:ADEE	D1 03		jnh     ROM_ADF3		; If engine speed is not higher, jump to ROM_ADF3, program running continues
ROM:ADF0	91 40 C7	orb     INTMEM_C7, #40h		; "OR" operation to "INTMEM_C7". 40h is 01000000, so BIT6 is switched to "1" (4)

NOTES:
1. Referred to "Map lookup table" starting address: E68Ah + 86h = E710h -> ROM_E710 = "99DCh" -> 0xDC99 = Rev limiter map
2. Vehicle speed is stored in RAM_187B. Note! The 0x1C is used in almost everything. Vehicle speed doesn't stay there for long, so it need to load just before the "map routine".
3. RPM values are stored in different form: Rev limiter conversion is x/4, but table values are stored in x*40.
4. 0xC7 BIT6 is "fuel cut" -flag.



*** Rev limiter in -623.bin

Code: Select all

ROM:ADD5	8B 69 30 00 40	cmp     INTMEM_40, 30h[INTMEM_68] ; D002h+30h=D032h. 0xD032 is where the rev limit value is stored in -623.bin
ROM:ADDA	D1 03		jnh     ROM_ADDF
ROM:ADDC	91 40 C7	orb     INTMEM_C7, #40h

So...
I'm trying to create a "variable launch rev limiter" where the launch rpm is picked from actual engine rpm by pushing a button.
There is flags for "car is moving" and all "switch" input pins from Air conditioning and A/T, they can be used in this.

How it works?: Push a button and hold. Select RPM by using throttle, and release the button. Now your rev limiter is set to this RPM. When car starts moving, rev limiter is changed back to fixed value.

It is also possible to create several different fixed rev limits and select them by those inputs.

This would be a good exercise for programming. And maybe nice feature, if someone wants to try it.

[Evil]

Very interesting, it will be a nice feature on our olds motronics.
Ready to try it on my 404 when we'll have more infos

[olafu]

V8 software has similar problem than every six cylinder except US M3. I can't say which RAM address is surely unused in 404 or 413, but in US M3 ecu has the RAM address for rev limiter. It's vital for this launch rev limiter. So only bullet proof variable launch can be available for US M3 ecu.