Has anyone on here disassembled the 413 code?

Discuss Bosch (Porsche, BMW, Volvo, etc) tuning topics here. Request definitions, discuss parameters, etc.

Moderators: robertisaar, dex

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Has anyone on here disassembled the 413 code?

Post by Hairyscreech » Mon Sep 18, 2017 6:32 am

I have been trying for a while to get a good disassembly of the code from the 413 ECU with mixed results.

Biggest issue I am finding is that the code seems to reference the zero register a lot and IDA is not liking it. IDA treats the zero register as always zero making a lot of the code meaningless.

Has anyone here done a full disassembly and if so any pointers?

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Mon Sep 18, 2017 11:05 am

My assembly or any other programming skills are about zero, but i was thinked many times, how powerful tool some kind counter can be, which is counting how many times ecu reads some rom addresses when using an emulator. If those counter values can be align on to the ROM dump in hex editor, coloring cells or something like that, it can be helpful to understand where to find some program parts to partially disassemble them. Maybe by manually, without specific disassembler.

Address sequence recording is other interesting thing. It would be feature, which you can set the recorder triggered from specific address hit to record certain number of ROM addresses after that.

EDIT: Actually that hit counter utility seems to be found at TunerPro.

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Wed Sep 27, 2017 7:50 am

I tried that with 413/623 dme, tracing area was set from E680 to E7AF and fitted to match with "Map address table". It ends on E7AA, but i thik it's better to see like this.

That seems to indicate quite clearly what maps are in use or not in use...
Picture below is edited with Paint to fit that map address table on to the trace table.

http://ibb.co/jFUEjQ

I think there is not enough bandwidth in RS232 to get real time address data to PC, but this helps to get a grip from rarely readed maps, which is use in only when happens something abnormal, like knock detected or something fault is detected.
Last edited by olafu on Wed Sep 27, 2017 9:10 am, edited 3 times in total.

Evil
Posts: 133
Joined: Tue Jul 18, 2017 12:53 pm
Location: France

Post by Evil » Wed Sep 27, 2017 8:12 am

Very interesting!
Which utility did you use ?

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Wed Sep 27, 2017 8:15 am

Tools -> Hardware utility -> Address watch utility. ( CTRL- W ) in TunerPro.

Evil
Posts: 133
Joined: Tue Jul 18, 2017 12:53 pm
Location: France

Post by Evil » Wed Sep 27, 2017 8:25 am

Thanks!
:D

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Wed Sep 27, 2017 8:32 am

Like that: http://ibb.co/kWeddk

It draws almost immediatelly graph look like this. Then it's colors partly other 16 bit cells, but if either byte of 16 bit address is read, i think it means whole address it is read at least once.

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Sat Sep 30, 2017 3:22 am

Tried to catch running parts of software/bin with that. Seems to fit with IDA output... :)

User avatar
biela
Posts: 29
Joined: Tue Jul 22, 2014 1:01 pm

Post by biela » Wed Oct 31, 2018 1:28 am

Hello

Can you post a simple function explained?
Like table/map look up calls.

Thanks

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Wed Dec 19, 2018 8:01 am

Unfortunately not as we don't know how they work yet.

I have had very little time to play with the car due to work commitments and the landing of a RUSEfi unit on my desk.

However I still intend to keep playing with this one and maybe implement some of the functions into the RUSEfi unit as it is simply a better unit for roughly the same cost as a M3x motronic and tuning gear.
But to do that means a deeper understanding of the actual motronic code.

Acki
Posts: 21
Joined: Wed Mar 06, 2013 12:00 pm

Post by Acki » Wed Dec 19, 2018 3:58 pm

Table Access, look for code similar to this:
push PSW
push B
push DPH
push DPL
mov DPH, RAM_77
mov DPL, RAM_78
mov A, R2
inc R2
setb PSW.3
movc A, @A+DPTR

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Sun Jan 06, 2019 5:02 pm

Thank you Acki.
I will take a look and see what is lurking in the code this week if I get time (its cold outside so I expect I will).

Can I ask what makes you suggest that?

From what I can see the 80196 processor is quite different to the older 8051 and the code is nowhere as easy to follow.
https://en.wikipedia.org/wiki/Intel_MCS-96

User avatar
biela
Posts: 29
Joined: Tue Jul 22, 2014 1:01 pm

Post by biela » Mon Jan 07, 2019 6:43 am

Hello
I have found Acki´s code in M1.3 and M1.7 8051 ecus.
But i have no luck in M3.3 80196 ecu.

May be in 80196 is something like this?:

Code: Select all

ROM:5349 ROM_5349: 
ROM:5349                                        
ROM:5349                 stb     INTMEM_48+1, INTMEM_D3_IAT ; Store byte
ROM:534C                 ldb     INTMEM_26+1, ROM_1451[] ; Load byte
ROM:5351                 ld      INTMEM_1A, #6   ; Load word
ROM:5355                 lcall   ROM_33C2_table_access ; Long call
#6 as table offset.
And ROM_33C2:

Code: Select all

ROM:33C2 ROM_33C2_table_access:                        
ROM:33C2                 add     INTMEM_1A, INTMEM_6E ; Add words (2 operands)
ROM:33C5                 ld      INTMEM_4C, [INTMEM_1A] ; Load word
ROM:33C8                 ldbze   INTMEM_50, [INTMEM_4C]+ ; Load byte zero-extended
ROM:33CB                 ldb     INTMEM_50+1, [INTMEM_50] ; Load byte
ROM:33CE                 clrb    INTMEM_50       ; Clear byte
ROM:33D0                 ldbze   INTMEM_52, [INTMEM_4C] ; Load byte zero-extended
ROM:33D3                 add     INTMEM_4C, INTMEM_52 ; Add words (2 operands)
ROM:33D6                 add     INTMEM_4E, INTMEM_52, ZERO_REG ; Zero register
ROM:33DA                 je      ROM_3430        ; Jump if equal
ROM:33DC                 addb    INTMEM_50+1, [INTMEM_4C] ; Add bytes (2 operands)
ROM:33DF                 jnc     ROM_33EE        ; Jump if carry flag is clear
ROM:33E1                 dec     INTMEM_4E       ; Decrement word

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Mon Jan 07, 2019 11:35 am

You might be on to something there.

A little while ago I patched in Olafu's RAM dump and some data I managed to capture via INPA to fill out the missing regions of the code.
(I can't say the missing data is correct or perfect as they were snapshots taken from running engines, for all I know the data doesn't quite match as I could only snapshot 100 hex values at a time.) - but anyway...

The missing RAM areas were kind of interesting but only a small step forward, however combined with the info you just posted and some knowledge from the intel manual I get the following.

Code: Select all

ROM:5349 stb     INTMEM_48+1, INTMEM_D3 ; Store byte
ROM:534C ldb     INTMEM_26+1, INTMEM_1451[] ; Load byte
ROM:5351 ld      INTMEM_1A, #6   ; Load word
ROM:5355 lcall   ROM_20C7        ; Long call
ROM:5358 cmpb    INTMEM_48+1, 150h[Diagnostic_ID] ; Compare bytes
ROM:535D jc      ROM_5375        ; Jump if carry flag is set
ROM:535F cmpb    INTMEM_48+1, 151h[Diagnostic_ID] ; Compare bytes
ROM:5364 jnh     ROM_5384        ; Jump if not higher (unsigned)
ROM:5366 jbc     INTMEM_26, 0, ROM_53BC ; Jump if bit is clear
ROM:5369 ldbze   INTMEM_54, 0Ah[Diagnostic_ID] ; Load byte zero-extended
ROM:536D lcall   ROM_6F69        ; Long call
ROM:5370 andb    INTMEM_26, #-2 ; '¦' ; Logical AND bytes (2 operands)
ROM:5373 sjmp    ROM_53BC        ; Short jump

ROM:33C2 add     INTMEM_1A, Table_Tables_ID ; Add words (2 operands)
ROM:33C5 ld      INTMEM_4C, [INTMEM_1A] ; Load word
ROM:33C8 ldbze   INTMEM_50, [INTMEM_4C]+ ; Load byte zero-extended
ROM:33CB ldb     INTMEM_50+1, [INTMEM_50] ; Load byte
ROM:33CE clrb    INTMEM_50       ; Clear byte
ROM:33D0 ldbze   INTMEM_52, [INTMEM_4C] ; Load byte zero-extended
ROM:33D3 add     INTMEM_4C, INTMEM_52 ; Add words (2 operands)
ROM:33D6 add     INTMEM_4E, INTMEM_52, ZERO_REG ; Zero register
ROM:33DA je      ROM_3430        ; Jump if equal
ROM:33DC addb    INTMEM_50+1, [INTMEM_4C] ; Add bytes (2 operands)
ROM:33DF jnc     ROM_33EE        ; Jump if carry flag is clear
ROM:33E1 dec     INTMEM_4E       ; Decrement word
Now some immediately interesting things there, ROM:5358 is using the location of what I have flagged as the "diagnostic ID", seems it is used a few times following that long call to what you have indicated as the rom loading the tables

Secondly, ROM:33C2 instantly adds Register 1A to what I have showing as the ID location for the table of tables, i.e. the master table showing all the other tables in the ECU.

What are you using for disassembly?
You also have PM.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Tue Jan 08, 2019 12:54 am

Worked out something else as well, it looks like ROM 5081 is the beginning of the main program loop.

I might try to get hold of a 413 to take even higher res photos and strip like has been done in that M1.7 thread over on R3v, I started trying to map out the pin inputs on the processor a while ago but stopped when I found I would have to destroy the board to get the internal traces.
413 ECUs here are over £140 at the moment which is a bit expensive to kill for science and I have had no luck finding a defective one to cut up :x

I did manage to map out some of the registers as you will see on the IDB, the table headers on this ECU (I think) are actually the register addresses used so I am going to take a look at that ROM 5081 with the registers in mind and see if it makes anything clearer.

Edit - Did we decide the V8 404 (M3.3) is the same as the 413 but lacking some features?
Didnt someone run a 404 BIN on a 413 ECU ok?
Are the M3.1 ECUs (402/403/405) 8051 processors or 80196?
Both of these are much more common here and easier/cheaper to get.
Its a shame as silver label 413 ECUs used to be dirt cheap but they seem to have all gone.

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Wed Jan 09, 2019 12:09 pm

Some CPU pin data from my notes: (413 ecu)

CPU pins:

4 = P0.3 ACH3 = Battery voltage
5 = P0.1 ACH1 = Intake air temperature
6 = P0.0 ACH0 = Mass air flow
7 = P0.2 ACH2 = Throttle position sensor
8 = P0.6 ACH6 = Lambda voltage
9 = P0.7 AHC7 = Signal from knock sensor controller IC: knock signal level?
10 = P0.5 ACH5 = Coolant temperature
11 = P0.4 ACH4 = Other signal from knock sensor controller IC: reference level?

15 = P2.2 = Vehicle speed signal
24 = HSI.0 = Ignition: Spark detected (secondary shunt resistor signal)
25 = HSI.1 = Crank signal
44 = P2.3 = Cam signal

That "spark detected" is used for diagnostics and limp mode. Ecu is "listening" this pin after every ignition event, and if there is no "snap", it will shut fuelling off from this cylinder and relevant fault code appears. If there is no signal from any cylinders, secondary current monitoring fault code appears, and secondary current monitoring is disabled.

If i remember, some of inputs and outputs are multiplexed.

I can trace more, it's such easy with 2ch oscilloscope. If there is something multiplexed inputs/outputs, i can try to trace them also. I bought a cheap 32ch logic analyzer, so i can hook it on address bus, data bus and chip control lines. So i can see the sequence of reading rom and reading/writing ram.

Ask, i can do tests.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Thu Jan 10, 2019 11:54 am

I just got hold of a 484 V8 M3.3 ecu, not sure if it is a 3l or 4l ecu but it was super cheap as it is an EWS version of the V8 404 and people here dont seem to understand they are all the same bar the software.

I will add the BIN to the folder with the others once I rip it.

I might have to get my hands on a logic analyzer as well, seems they are no so bad price wise now but I will have to do some research to avoid buying ebay junk.

This one is going to become a bench test ECU if I can map out the pins without scrapping it using a logic analyzer as you suggest.

I think one of the key things we need to do is to be sure what is connected to each pin of the MCU so we can work out what it is expecting to sense with each piece of read code.

I remember that things on port 3 and port 4 are multiplexed, I need to take another look at the data sheet.

There is also a thread about the M1.7 on R3vlimited that will be looking at some of the same ICs we have and which could shed some light on some of the things we have here.
https://www.r3vlimited.com/board/showth ... p?t=419240
https://www.r3vlimited.com/board/showth ... p?t=420029


update edit - it looks like this magnificent ba**ard is a pair of 2 sided boards and not a 4 layer board like the M3.3.1.
I thought the ".1" added on was for the addition of VANOS but it looks like it may actually be to indicate the revision of the board to a 4 layer single PCB.
This we can work with without destroying it....

Edit on an edit: - The bottom board is a 2 layer board but it looks like the top board may still be 4 layer. :roll:

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Sat Jan 12, 2019 5:00 pm

Something I have just found out for future reference, the AN82526 chip on the board is an Intel CAN communications chip and seems to hooked up to the transmission control module lines.

It looks from the traces on the board like it is only wired up to transmit and it receives its information from that pesky 100163 port expander which we still know so little about.

I added a data sheet for this IC to the dropbox if anyone wants to look at it further.

I also found a nice database of IC chips here : http://siliconpr0n.org

Edit to add - Bosch 30117 is the knock control chip.

The 30106 is I believe similar to this one: as I can pick up the crank signal on one of the pins http://siliconpr0n.org/archive/doku.php ... sch:b30318
Last edited by Hairyscreech on Sat Jan 12, 2019 6:13 pm, edited 2 times in total.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Sat Jan 12, 2019 5:20 pm

I have also just been through the wiring diagrams for the M3.3 V8 ecu and the M3.3.1 I6 ECU and can report that they are nearly perfectly pin compatible.

The only changes I can see are that the V8 ecu uses a VR cam sensor vs a Hall effect on the I6.
Pin 7 is used for a fuel injector on the V8 and VANOS on the I6 so I suspect it may be the same circuit just recycled to trigger a VANOS solenoid instead of a fuel injector solenoid.
It appears to be no different to any of the other outputs contained in the transistor packs under the heat sinks.
There are a few extra things added to the V8 but they are all on "not used" pins of the I6.

It is possible that with a swap of the cam sensor and an I6 rom loaded that an I6 may run on a V8 ECU. This will need some more checking but it should be possible and an interesting experiment if someone feels brave.

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Sun Jan 13, 2019 9:16 am

The 30106 is I believe similar to this one
413 ecu has 30131 (at least 8ch, maybe 10ch?) chip for coil transistor buffering. I think 30106 has something other features instead of that buffer... Has also M3.3 ecu 30117 knock sensor chip? M60 has four knock sensors, so it would be nice to know how it's controlled in M3.3 ecu.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Sun Jan 13, 2019 11:49 am

Yep we have the 30117 chip connected to the knock sensors.

I will upload some (probably a bit bad due to lighting) pictures of the board I have on my desk to the dropbox right now.

I have also been working out pins on the processor. I have put a bmp file in the dropbox photos folder listing everything I know about the CPU pinout already.


RE the 30106 - all of the 3 ecus I have here are 30106 (M1.7.3, M1.3, M3.3 and M3.3.1)
We can only assume they are interchangeable between the 30106 and 30318 as my rusEFI plug donor was a M1.7.3 with a 30106 in place of the 30318. :?:
I agree about the 30131 chip being the coil interface on the M3.x ECU, this M3.3 uses one as well.
I wonder if the 30106 is only able to act as an interface for 1 coil as the M1.3 and M1.7x only dive 1 coil output? (M42 has a smart coil block that triggers the correct coil from 1 output)

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Sun Jan 13, 2019 2:17 pm

M42 coil pack is actually four "COP" coils in same package... :?
So, i think 30106 is used, because it has many other useful features, but, as example, only four transistor driver channels... So M50 and M60 needs separate driver ic.

EDIT:
https://tinyurl.com/y7ctthob <- M43 coil workshop manual
Last edited by olafu on Sun Jan 13, 2019 2:45 pm, edited 3 times in total.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Sun Jan 13, 2019 2:34 pm

I will double check, the EWS I have for the E36 does not include the M43 so you could be right. I was under the impression they were "smart coils".

I dropped the most up to date info into the dropbox with as many pins listed as I can achieve at the moment.

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Mon Jan 14, 2019 2:24 pm

Power on, no cranking:

0x4000 and 0x4001 are first readed bytes from external ROM, when power is switched on. Next comes 0x4120, 0x4121, 0x4122, 0x4123, 0x476B, 0x476C, 0x476D, 0x476E, 0x476F, 0x4770 and so on, sequentially up to 0x4816. Then comes 3.5ms perioid with no reading from external ROM. Reading starts again from 0x412C, 0x412D, 0x412E, 0x412F.

MAF table is in use. Reading interval ~1ms. Table reading happens in section 0xA4AA-0xA642...

https://www.dropbox.com/sh/xl0wftov6kgv ... uP9jAKxg9a?

0x2000-0x3FFF is internal ROM, and it can be different from external one's same memory area... :?
By the way, ecu works fine with blank EPROM from 0x2000 to 0x3FFF. :roll:

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Tue Jan 15, 2019 7:00 am

I am inclined to say everything in your post below is correct, which is good cause it means everything I can see on the disassembly so far is also correct... :lol:

I will send you a link to a live copy of the disassembly I have so far, that way you can keep up to date easily.

0x4000 is 5AA5h and is the first value read by ROM_2080 and put into register AX.

Intel sheets tell us the program starts at 0x2080 and that seems to be the main ROM which is what you can see running those first set of reads.

The MAF table being read from 0xA4AA makes senses with what I found yesterday.
From what I could see in the code ROM_418C was reading A/D channel 0 and was being called by a software timer interrupt, it was accessing the MAF table section at the right value for the airflow of the idling engine I took the RAM dump from.

Regarding 0x2000 to 0x3FFF - this is capable of being either in the MCU or on the external ROM, it is possible to decide where it is called from by setting pin 2 (EA) on the MCU to high or low.
The default is set high, connected to Vcc, and that forces it to read from the MCU, earthing out that pin and cutting the 5v+ will force it to read from the ROM chip.
We are just lucky that the whole of the ROM code is on the EPROM.
I suspect that there may be some ECU modding coming in the near future.

Link to the disassembly in your inbox now. If you have questions (and I'm sure there will be) then let me know and I could set up a quick slack channel or something to get us up to speed with any open results or questions posted back to here.

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Tue Jan 15, 2019 9:20 am

Yes, EA-pin is now lifted up and grounded. First ROM access is 0x2018 (chip configuration byte) and program starts from 0x2080. ECU boots up and seems to run normally... :D

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Tue Jan 15, 2019 11:16 am

Great news. That paves the way to custom firmware and possibly better access to the current firmware.

I think even if we did not have that ROM section on the EPROM then we could have pulled it off the MCU, it would just have been more difficult.

How did you go about lifting that pin?
Iron onto the exposed trace part and then lifted/pulled out with some tweezers?

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Tue Jan 15, 2019 11:37 am

Hairyscreech wrote:How did you go about lifting that pin?
Iron onto the exposed trace part and then lifted/pulled out with some tweezers?
With crowbar :lol: Tiny bent needle and some heat from soldering iron.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Tue Jan 15, 2019 1:46 pm

I just dropped an old 8051 onto that M1.7 board to try it out on a few pin, was so easy after doing two I went direct to to M3.3

Bit of heat with the iron and a pair of the tweezers below and out it came, run a jumper over the top of the chip and around to a ground pad.
Image

So that's modded ECU number 2.

Need to get this ECU hooked up to a test setup and powered up so I can torture it for science.

What are you using to simulate the crank and cam signal?
I was going to put some resistors etc onto a bit of strip board with some LEDs to fake the injectors and a few pots for the coolant, tps, MAF and iat.
All that is pretty easy its just a good VR signal is hard to fake and still keep it in sync with the cam.

I was considering mounting a trigger wheel and 50/50 cam trigger on a motor powered from an arduino so I can do accelerations easily. [/img]

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Re: Has anyone on here disassembled the 413 code?

Post by olafu » Tue Jan 15, 2019 8:57 pm

Same system as last year, but now daqarta used as signal generator. Audio isolator in PC soundcard output and wired to crank sensor input. Few potentiometers and some load resistors. 1k resistors are enough for load. No cam signal, need to do some kind filtering circuit with latch and generate only triggering pulses with sound card, because it's not capable to output square wave.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Re: Has anyone on here disassembled the 413 code?

Post by Hairyscreech » Wed Jan 16, 2019 6:16 am

I will have to take a look when I get home.

I was thinking of writing a bit of simple arduino code to do it but outputting two digital square wave signals is easy, generating a VR sensor signal is not.
I was wondering how well the ECU would function if it was fed a square wave crank signal or given the square wave signal after the filtering in the 30106 chip.
I am assuming here that the signal coming out of the 30106 chip is a square wave?

What I was thinking is if I could get the signals out of an arduino then I could hook up a rotary pot to it and make it adjust the frequency of both signals as though the engine was accelerating.

I could just buy a "jimstim" but bugger that for £100 + cost of programming cable and still needing to add some bits for a complete setup.

I might pick up a cheap PCIe sound card and give Daqarta a try, no way I am putting it through my MSI board. :shock:


n.b. - As it is kind of relevant here, how do you find the Hantek 4032? I have been looking at them for a cheap logic analyser but have heard the software is a little poor?

Edit to add - I might look at a way to use Daqarta to trigger an arduino to give the outputs we need, that would both solve our signal shape issue and protect the sound card.

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Re: Has anyone on here disassembled the 413 code?

Post by olafu » Wed Jan 16, 2019 6:51 am

Audio isolation transformer protects your sound card, but second sound card is anyway good choice... I bought my own transformer from local grocery store. I was thinking to drive positive feedback comparator and controlling switching transistor with it. On positive peak from daqarta (or something else) it will set on and with negative peak it resets. Motronic also works with square crank signal, but i think it is better to feed it with triangle or sine. Square can cause distortion in vr amplifier.

Hantek's software is pretty restricted and it have some "things" what you must to know. But it works, if you don't ask for it too much...

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Re: Has anyone on here disassembled the 413 code?

Post by Hairyscreech » Wed Jan 16, 2019 3:11 pm

If that's the case then maybe this is of use to you:
https://sigrok.org/wiki/Hantek_4032L

Looks like a 3rd party application for the 4032.

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Re: Has anyone on here disassembled the 413 code?

Post by olafu » Sat Jan 19, 2019 1:07 am

From 80196 user guide:
"The execution times for the instruction set are given in
Figure 3-3. These times are given for a 16-bit bus with
no wait states. On-chip EPROM/ROM space is a 16-
bit, zero wait state bus. When executing from an 8-bit
external memory system or adding wait states, the CPU
becomes bus limited and must sometimes wait for the
prefetch queue. The performance penalty for an 8-bit
external bus is difficult to measure, but has shown to be
between 10 and 30 percent based on the instruction
mix."
:?

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Re: Has anyone on here disassembled the 413 code?

Post by olafu » Sun Jan 20, 2019 4:29 am

Seems like this B58039 PLCC44 chip, number "S750" has significant role in injection output stage (and maybe something else) controlling. Chip "S705" sends eight pieces of data packets in burst to that "S750" on every injection event, three times at one crankshaft rotation. So i think, that "S750" is independent injection timing and pulse width CPU, main CPU only sends data to it, through "S705". "S750" pinout seems very similar to example as 8032 or something like that. (Vss, Vcc, ports location, etc...)
If S750 is 80C32 (or 8051 or something?) the Port0 is working as bus to main CPU through S705, and Port1 is connected to injection output stages. Reset pin is connected directly to main CPU pin 19 (P1.0)

Every times, when that bus between S705 and S750 changes state, there is same time 0x0440 in address bus. Especially the CPU pin 50 (AD10/P4.2) is high. It is connected directly to S705 pin59. AD0-AD7 pins are latch outputs, because my analyzer is connected to ROM address bus, and everything is referred to it.

S705 pinouts: https://www.dropbox.com/s/odudtwxofzndc ... d.png?dl=0

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Re: Has anyone on here disassembled the 413 code?

Post by Hairyscreech » Sun Jan 20, 2019 7:08 am

olafu wrote:
Sat Jan 19, 2019 1:07 am
From 80196 user guide:
"The execution times for the instruction set are given in
Figure 3-3. These times are given for a 16-bit bus with
no wait states. On-chip EPROM/ROM space is a 16-
bit, zero wait state bus. When executing from an 8-bit
external memory system or adding wait states, the CPU
becomes bus limited and must sometimes wait for the
prefetch queue. The performance penalty for an 8-bit
external bus is difficult to measure, but has shown to be
between 10 and 30 percent based on the instruction
mix."
:?
My first thought was "well fug." but on consideration that may not be the issue it seems...
Only code up to 3FFFh is executed from the internal memory and it seems that most of that is startup code that does not loop anyway, the rest is all already running off the external ROM so is already subject to this penalty.
Certainly everything in the main loop appears to be in external memory with the only bit giving me pause being the Table calls around 33xxh to 35xxh.
Still these would seem to be a very tiny percentage of the code in the main loop and the already spend time accessing data values that are on the external ROM so may also be subject to this limitation anyway.

Once I have my setup running I might try running from internal ROM and external ROM while winding the speed up and monitoring the injection output to see when the injection pulses desynchronize from the RPM. This will give us an idea of what the maximum RPM the ECU can handle in both stock and modded condition is.

Unfortunately the onboard memory is one time programmable so there is practically nothing we can do about the 8kb apart from run externally or prey we have no need to modify that part of the code.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Re: Has anyone on here disassembled the 413 code?

Post by Hairyscreech » Sun Jan 20, 2019 7:45 am

olafu wrote:
Sun Jan 20, 2019 4:29 am
Seems like this B58039 PLCC44 chip, number "S750" has significant role in injection output stage (and maybe something else) controlling. Chip "S705" sends eight pieces of data packets in burst to that "S750" on every injection event, three times at one crankshaft rotation. So i think, that "S750" is independent injection timing and pulse width CPU, main CPU only sends data to it, through "S705". "S750" pinout seems very similar to example as 8032 or something like that. (Vss, Vcc, ports location, etc...)
If S750 is 80C32 (or 8051 or something?) the Port0 is working as bus to main CPU through S705, and Port1 is connected to injection output stages. Reset pin is connected directly to main CPU pin 19 (P1.0)

Every times, when that bus between S705 and S750 changes state, there is same time 0x0440 in address bus. Especially the CPU pin 50 (AD10/P4.2) is high. It is connected directly to S705 pin59. AD0-AD7 pins are latch outputs, because my analyzer is connected to ROM address bus, and everything is referred to it.

S705 pinouts: https://www.dropbox.com/s/odudtwxofzndc ... d.png?dl=0
I put some reverse engineered schematics into the dropbox a few minutes ago, I found these a while ago but did not think it was directly useful at the time, with hind sight perhaps it is.
With how much seems to be common among the ECUs it may prove to be vital. :!:

Seeing your Pin out confirmed the S705 chip you were talking about is also the one named as the B58011, 100136 or B58024, BD 266238.
I have 3 different versions of it here and all seem to be exactly the same thing made by different manufacturers.
It seem like these are a Bosch designed chip that were contracted out to at least 4 different manufacturers.
It is used in all of the motronic versions I have seen from the M1.3 onward and seems to be both a port expander and an address router for the MCU.
One has been delidded and photographed in the M1.7 thread over on R3v and I am happy to massacre one if the versions I have here but I am not sure what I will be able to learn from it.

That S750 chip might be the microcontroller I noted on the pinout diagram in the dropbox. I traced it back to part number AN83C51FA which is an intel 8bit MCU.
My guess right now is that it is deciding if the injection should be batch or sequential.
You might be able to figure out if that is the case by measuring its response under conditions we know to be either batch or sequential injection.
Do we know what else that chip is connected to?

Regarding the 0x0440 address, the cross references in the disassembly show the following, I don't know how helpful this is?
Attachments
0x0440 cross references.JPG
0x0440 cross references.JPG (87.04 KiB) Viewed 1007 times

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Re: Has anyone on here disassembled the 413 code?

Post by olafu » Sun Jan 20, 2019 8:03 am

I have to do some tests, need to clear out how this system treats that S750. It woud be useful information for disassembly work.
With this fine laboratory :lol: https://www.dropbox.com/sh/l2subwkgoef2 ... tTgSj-L57a

EDIT: https://www.dropbox.com/s/ivb6hpl33z9ri ... _30131.jpg <- ignition buffer IC.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Re: Has anyone on here disassembled the 413 code?

Post by Hairyscreech » Sun Jan 20, 2019 12:32 pm

The 30131 on this 8 cylinder is pretty much the same but the ignition drivers are set out 15486372 (going from pin 2 to pin 9).

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Re: Has anyone on here disassembled the 413 code?

Post by olafu » Sun Jan 20, 2019 1:17 pm

Yes, with M60 bin, ignition firing sequence is going to 2-9 also with 413 board. And those pin 8 and 9 (T507 and T508) transistors are missing. But 7 and 8 cylinder's injection pulses are not seem to come out from anywhere. https://www.dropbox.com/s/e0o8zid3mf7se ... 4_bin_.BMP

In 413 ecu, firing order is everywhere 536241. -> =153624 with 1 cylinder flipped from first to last. I can't say why.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Re: Has anyone on here disassembled the 413 code?

Post by Hairyscreech » Sun Jan 20, 2019 4:12 pm

Your right that is odd, the firing order is 135624 so that sequence is correct for 624 but 3 and 5 are reversed.

I think this is due to the ECU running in wasted spark mode when there is no Cam signal for sync.

If they are laid out in firing order then it means the channels are triggered in an uneven pattern.
I have named the pairings A B and C in the image below, you can see how the pattern would not work if the channels were laid out in the normal firing order.

I think with the V8 order it is not a problem as each bank would pair up in order, I need to double check the pairings for wasted spark but I think it holds up.
Attachments
IMG_20190121_011008.jpg
IMG_20190121_011008.jpg (186.93 KiB) Viewed 979 times

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Re: Has anyone on here disassembled the 413 code?

Post by olafu » Sun Jan 20, 2019 8:24 pm

No, it is synced now with faked cam signal.
153624 -> 536241 it's same firing order, but it only starts from 5. I think this is something to do with 120 degrees different trigger wheel position. Maybe only BMW engeneers can say why this is changed. :)

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Re: Has anyone on here disassembled the 413 code?

Post by olafu » Mon Jan 21, 2019 8:12 pm

Knock control IC: https://www.dropbox.com/s/ted5caw5yrrd0 ... nished.png
and how it seems to work: https://www.dropbox.com/s/wzz82fdpj8wkw ... _works.png

channel select signals seems to come from S920. :?

So, after discovering all this information, i found pieces of Bosch CC195 datasheet. They looks very similar, so i think this chip is CC195.

This went to disassembling -413 hardware, but i think this is good support for disassemby work in future...

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Re: Has anyone on here disassembled the 413 code?

Post by Hairyscreech » Wed Jan 23, 2019 7:25 am

It would make sense if it was a CC195 given the era and the commonality of that chip.

I did a bit more digging into the 0x2000 to 0x3FFF speed penalty issue. It seems that most of the code in that area is either only read once or is jumps to another ROM.
The only one I can see that may be impacted is about 10% of what I think is the crank senor ROM runs from that area. How significant this will be we can only test.

I have also been trying to tie up some of the jump tables and other ROM areas back to things that have been identified as for specific functions. I have updated these notes onto the live copy in the dropbox.

I finished soldering the break outs onto my bench test ECU, I am just waiting for a few more bits to arrive before I can finish off and start testing things out.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Re: Has anyone on here disassembled the 413 code?

Post by Hairyscreech » Sun Feb 03, 2019 1:05 pm

Just solved the question about the single ignition driver in the M1.7 and why the M43 coil packs are individual inside the block of coils.

The simple answer is there was a single ignition coil E36 316i that used a distributor. The M43 with the big coil packs uses a slightly different version of that ECU.

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Re: Has anyone on here disassembled the 413 code?

Post by olafu » Thu Feb 07, 2019 9:56 am

Some tests with internal and external rom:

8960 rpm (no cam signal, no closed loop, internal rom)
8440 rpm (no cam signal, no closed loop, external rom)

maximum RPM:s. If exceeded, ECU goes reset. Significant penalty.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Re: Has anyone on here disassembled the 413 code?

Post by Hairyscreech » Mon Feb 11, 2019 10:01 am

Hmm, 5.9%.

In that situation its not too bad, certainly if I was turning something faster than 8000rpm then it wouldn't be running Motronic.

I am waiting for another cheap sound card (picked up a PCI not a PCIe by mistake :oops: ) but then I should be able to do some trials with Cam sync and see what we get.
If I can figure out some of the diagnostic routines and bypass them for some of the less important things it would probably claw that performance back at the expense of some ease of fault finding. (although I guess that is easily fixed with a quick ROM change to do a diagnosis).

It might also be possible to rip out some of the code involved in talking to the ABS and auto transmission which may help some too.

olafu
Posts: 131
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Re: Has anyone on here disassembled the 413 code?

Post by olafu » Mon Feb 11, 2019 10:31 am

Actually, real max_rpm is lower. Those tests was accidentally done with 6500rpm rev limit. :oops:
max rpm with external rom: 7860rpm
max rpm with internal rom: 8340rpm

no cam signal.

with maf fault mode (alpha n) max rpm with internal rom: 7980rpm. :roll:
Motronic hardware with software shittened to level of common aftermarket ecu's, it would run full 10200rpm without problems... :lol:

But what about this disassembly? Can you explain how this thing calculates RPM and crank angle from crank signal? I can't.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Re: Has anyone on here disassembled the 413 code?

Post by Hairyscreech » Tue Feb 12, 2019 10:51 am

From what I know of the code the crank decoding is the biggest single part of the code, if the function I have labeled as the CPS detection is correct then it's a massive task to understand.
A hall effect would be easy as its interpreting a digital input but with the VR sensor there is tons of things to do and the signal has to be processed a little to prevent noise. (look at older megasquirt for a good (bad) example of crank sensor noise issues).

I know it divides the slope of each crank tooth into 4 segments but where and how it does it beats me.

I haven't had much time to look at the code this last few weeks due to work and building the bench test ECU so for now identifying the functions is my main focus.

As soon as I have this bench test ECU running I am going to adjust the code to see what functions I can activate or shut off by changing the code.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Re: Has anyone on here disassembled the 413 code?

Post by Hairyscreech » Sat Feb 23, 2019 11:32 am

My new sound card arrived, is now installed and working, my logic analyser should arrive early next week.

I had a play with daqarta and an oscilloscope and it does a fairly passable job at making a square wave form so cam sync should be possible. The square signal dipps about 0.2v across the top at @40hz which should be enough to fool the ecu to think the cam trigger is there.

I am curious how you have your daqarta set up to replicate the 60-2 crank trigger, is there a way to set up daqarta to output a custom wave form?

Post Reply