Modifying Motronic 2.3.2 ECU hardware and software.

[prj]

I think you need to spend more time sitting in IDA Pro and understanding code and less time making up gadgets that will leave you none the wiser if you want to get anywhere with this ECU. But hey, it's just my opinion.

[-ice-]

It's not the price, it's because I don't have low level access to it. I will mainly use it to test modified firmwares.

[prj]

Ostrich is cheap. It is far cheaper buying a 2nd one rather than making your own project... well depends how much free time you have of course.

As for IDA, there is a free version:

https://www.hex-rays.com/products/ida/support/download.shtml

I have not checked if it supports the 8051 CPU though.

[-ice-]

In my view the emulation of both eproms is a good practical use. I don't want to buy a second ostrich.

I don't have IDA pro, too expensive...

Bye

[prj]

I just started to develop an own emulator hardware which will be able to filter for opcodes and queue the previous an next instructions in SRAM to be read out.

Basicly a microcontroller with an extern RAM, which emulates the motronic eprom.

Regards

Waste of time ... maybe fun for a school project but no practical use whatsoever.
The 8051 is so primitive, you can literally just map out the memory, document the multibyte subroutines, such as multiplication, shifting, division as well as map lookups and then you can just read the code.

There is no guessing as to what reads what, it's right there at the start of each call, and IDA lays it out beautifully.

[pasbogdan]

I do not see why not.If jap has interface with "file/open,edit/add more power" why not a 2.3.2 nice log screen and graph?

[-ice-]

I just started to develop an own emulator hardware which will be able to filter for opcodes and queue the previous an next instructions in SRAM to be read out.

Basicly a microcontroller with an extern RAM, which emulates the motronic eprom.

Regards

[prj]

What log feature are you talking about?

The one you have seen

Maybe I should start selling it to those adventurous enough.

[pasbogdan]

The thing I want the most is a better log feature than I got today but for a starter I would just be using time on figuring out how things are connected.

What log feature are you talking about?

[minim]

Keep posting I'm reading this and a lot of other threads on the subject because I'm considering to try this myself. I do fear that I lack knowledge about this and that's what keeping me from ordering what I need to persue this.

I did program a bit low lvl back in school but the last years it's been only high lvl programming of PLC systems. Is it hard to start from scratch again and do this step by step? I've pretty much forgotten all I knew about assembly by now... The thing I want the most is a better log feature than I got today but for a starter I would just be using time on figuring out how things are connected.

[prj]

Seems that i will receive an Ostrich 2.0 in the next weeks

Does anyone have experience with the address hit feature? Is it possible to log all addresses which were hit and also display the data-bytes?

For example to identify the calling code parts, which will use dptr to read data from a known place. Is it fast enough to trace all eprom accesses? It's called realtime but seems to have serial 1mbps connection.

Am I the only one who works on the motronic code (except prj ). Don't want to write monologs here...


Regards

I think your wet dreams are strongly exaggerated
Or in other words - forget it, the tracing is pretty useless.

That said, this ecu's microcontroller is so simple it's really easy to see in code what accesses what, the problem is as always putting the big picture together.

[-ice-]

Seems that i will receive an Ostrich 2.0 in the next weeks

Does anyone have experience with the address hit feature? Is it possible to log all addresses which were hit and also display the data-bytes?

For example to identify the calling code parts, which will use dptr to read data from a known place. Is it fast enough to trace all eprom accesses? It's called realtime but seems to have serial 1mbps connection.

Am I the only one who works on the motronic code (except prj ). Don't want to write monologs here...


Regards

[-ice-]

Another thing i worry about...

We discussed the map access routine, which uses 75/76 and 77/78 + registers as "parameters"

I don't understand how and when these variables are assigned. There are code parts, where it writes to them directly

f.e:

4CB5 : 75 75 88 MOV 75H,#88H
4CB8 : 75 76 00 MOV 76H,#00H
4CBB : 75 77 80 MOV 77H,#80H
4CBE : 75 78 00 MOV 78H,#00H
4CC1 : 22 RET

Ok, but these don't access the interessting maps of the map adress-table (f.e. rpm-load-fuel @8dc6)

So i think, this adresses will be assigned indirectly (perhaps the offsets are also mapped anywhere an loaded with dptr).
I can't find code where it assignes 75h/76h (except some code, in which it does something with the carry flag)

[-ice-]

Nice I need to get an emulator working to try out the modifications. I tried to buy an Ostrich 2.0, but they can't deliver it to germany

I have a question concerning the rev-limit: Does the aan engine really have a 0xB0 limiter-value? Thought the rev limit would be later around 7200rpm...
0xA5 for automatic transmission seems conclusive...

Greetings

[prj]

You can put data directly into sbuf too.
If you write your own logic it is possible to just have 1 byte that tracks the current packet and then use the JMP @A+DPTR system to jump through them sequentially...

It's enough to do something like this:

RAM_PTR equ 0xXX

JBC TI, bitset
RET

bitset:
MOV A, RAM_PTR
MOV B, #003h
MUL AB
JMP @A+DPTR
LJMP byte1
LJMP byte2
...
LJMP end

byte1:
MOV SBUF, xxx
LJMP end
byte2:
MOV SBUF, yyy
LJMP end

end:
INC RAM_PTR
RET

And you can start sending by just doing:
CJNE RAM_PTR, <packet length>, getout
MOV SCON, xxx
MOV PCON, xxx
MOV RAM_PTR, #00h
CLR TI
MOV SBUF, zzz
getout:
RET

And then make sure the first block is called often enough... Maybe use some magic combination of 2 or 3 bytes so that you can see where the packet starts, and just stream the data nonstop.

Quite simple really... you can easily just replace the diag routine with this.
Stuff gets fun when you want to read data from the other uC as well and you have to sync them to each other so they don't talk over each other.