Siemens MS45 (MPC555) Noob Help

[Raleigh3rd]

Please forgive my ignorance, I am very new to all of this, and trying to learn.

I have a BMW running a Siemens MS45.1 DME. I have a tuning program (TunerPro), factory .bin files and .xdf definition files. I have been doing some surface level tuning with success, but want to develop a better understanding of how this computer uses all of the different parameters. I really just want to be able to look up parameters from my tuning software and see how/when they are called. My tuning software gives me the hex address of the parameters.

I have downloaded IDA freeware, and Ghidra, but don't know how to use them! Here is what (I think) I know:

I have both full and partial .bin files. (1024KB and 116KB). I "believe" the full file is a complete read of the MPC, while the partial file is just the configurations.
The DME uses MPC555 processor (PowerPC) which I believe is 32bit.

I have some background in coding, but not a lot, and never with assembly or machine code. I am happy to learn as I go, but am at the point where I'm too dumb to get started.

Can someone please help point me in the right direction of appropriate information, how to's, or just help me get my files properly disassembled?

[KingAustraliaggGG]

gday

I am working through BMW Siemens MS42/MS43/MS45 xdf definitions and trying to make the workflow more evidence-based rather than only trusting labels in an XDF.

The main ECU I am working on at the moment is Siemens MS45.0 on an E60 525i M54B25, that i just got early this year and seen theres no defintion file so decideded to make it myself.

The current target family is:

MS45.0 / E60 525i / M54B25
OSID family: 456N0B / BN00
Car calibration/program evidence points to:
- BN00EE0F
- ZB/SW around 7550113 / 7550114
- P7550114 calibration
- Program image 7549387

The closest full flash proxy I currently have is:

B039588_0044560_Flash.bin
This appears to be P7550108 / BN00EA0F.

From my comparison work, P7550108 and P7550114 are very close. The differences I found are only in the early calibration/header area around 0x40000-0x401FF, and the main table/checksum window appears unchanged. I am still treating this carefully, but it looks like a good proxy full flash for building/testing the BN00 XDF until I get a direct full read from the exact car/software.

I also have a known 456N0B stage pair from a DAMOS/tune pack:

BN00RA0G / P7550078
04DB Original -> 0FE1 Stage1

I have normal ECU-order unswapped copies now. The Stage1 differences land where expected: CRC/header area plus IVVT passive ignition, RON91 ignition, and RON98 ignition. I am not treating that Stage1 file as the same base as my car. I am only using the proven deltas as evidence for map locations and shape.

Current MS45 XDF status

I currently have separate full and partial XDFs because MS45 full reads and partial calibration reads use different address bases:

- full flash XDF: 1024 KB layout
- partial XDF: 116/128 KB calibration layout
- calibration area in the full file starts around 0x40000

The current MS45 BN00 XDF work is in the v3.x series. The latest internal candidate I have been working from is v3.19.

Current rough state:

- About 223 editable/catalogued entries
- About 104 maps
- About 119 scalars
- Current raw A+B grading is around 70%
- Most of the currently exposed maps have some combination of export evidence, RomRaider evidence, A2L/DAMOS evidence, full/partial parity, or before/after tune-diff evidence
- Only a small number are true “stage-proven” maps so far
- Only a smaller number again are disassembly-proven through code references

So I am not claiming the whole MS45 XDF is finished. My current goal is to get each table to prove itself through:

1. correct OSID/bin match
2. correct full/partial address mapping
3. correct X/Y axis shape
4. correct endian/scaling
5. sane export values
6. agreement with RomRaider/A2L/DAMOS where available
7. before/after tune-diff evidence where available
8. disassembly xref evidence where possible

The thing I am trying to avoid is making a big XDF that opens in TunerPro but has jumbled tables, wrong axes, or copied labels that are not actually valid for the target OSID.

Other BMW status

MS42:
- 0110C6 is my mature/reference MS42 base.
- 0110CA is working and usable for my E46 328ci project, but I still treat it as about 70-80% genuinely proven until I finish more validation.
- I have used MS42 0110CA as the model for the validation method: axis checks, interpolation sanity, cross-OSID comparison, export checking, and tune diff checking.
- 0110AB exists in my files but is lower confidence and needs more work.

MS43:
- 430069 is my main mature/community-reference MS43 OSID.
- I use MS43 and MS42 exports to compare what sane tables, axes, scalars, and before/after tune deltas should look like.
- I have local MS43 definitions and patchlist material.
- Other MS43 OSIDs like Alpina 430037/430070 still need cleaner support.

MS45:
- 456N0B / BN00 is the current main target.
- 456M0B / BM00 is a future target because I have stock/stage pairs for that family too.
- 456L0B / 456L3B / 457xx families are mostly reference until I build proper matching XDFs.
- MS45.1 is not being mixed into the MS45.0 XDF. I am treating it as reference only unless the OSID and strategy actually match.

Tools/scripts I already have

I have started building a repeatable toolchain instead of only manually editing XDFs.

My public GitHub tools/repos:

TunerPro XDF + BIN Universal Exporter:
https://github.com/KingAiCodeForge/Tune ... l-Exporter

CLI XDF/BIN map editor:
https://github.com/KingAiCodeForge/tune ... map-editor

68HC11 C compiler / disassembler / bench experiments:
https://github.com/KingAiCodeForge/King ... C_Compiler

VY L36 060A enhanced assembly patches / label workflow:
https://github.com/KingAiCodeForge/king ... sm-patches

The exporter can dump XDF + BIN combinations into Markdown/CSV/JSON/TXT so I can inspect what TunerPro should be seeing: table names, addresses, axes, scalars, units, scaling, and actual decoded values.

The CLI editor is for scripted XDF/BIN edits so I can make repeatable changes instead of hand-editing everything inside TunerPro.

The VY L36 / 68HC11 repo is not directly MS45, but it has useful patterns: XDF labels, hardware labels, disassembly labels, patch workflows, and processor-specific annotation ideas. I want to port that workflow to MS45/MPC555/PowerPC.

For MS45 specifically I currently have scripts for:

- OSID/header detection
- byte-swap detection
- MS45 swapped/unswapped BIN normalising
- SP-Daten .0PA/.0DA conversion to flat BIN
- full 1024 KB versus 116/128 KB partial XDF syncing
- XDF + BIN export checking
- full/partial/raw-cal/SP-Daten export parity checking
- RomRaider XML + dump exporting
- A2L/ASAP2 parsing
- DAMOS CSV cross-checking
- ORI/Stage tune diffing
- cross-family stage sanity checking
- editable map/scalar catalogue generation
- Ghidra label generation from XDF addresses
- MPC555 hardware label generation
- Ghidra headless command generation
- Ghidra XREF export
- Ghidra immediate/address-hit export
- Ghidra context-window export
- callsite-pattern export
- conservative disassembly evidence summarising

Some of these scripts are still rough/WIP, but the idea is to make the process repeatable.

Disassembly status

This is the part where I am still learning and would appreciate advice.

For MS45 I am currently working with:

- full 1024 KB external flash
- 116/128 KB partial calibration reads
- MPC/internal code read
- SP-Daten program/calibration files

My current understanding is that MS45 uses MPC555 / PowerPC. For Ghidra I have been using PowerPC big-endian 32-bit as the starting point.

The current working idea is:

- load MPC/internal code at 0x00000000
- map external flash/calibration into the high memory area
- for full-flash calibration addresses, translate XDF full-file offsets into the Ghidra external flash/calibration address space
- then import XDF/RomRaider/A2L labels and look for code references

I have already managed to get a couple of config/variant items to cross-reference into code. For example:

- CAN Variant / lc_var_bn2000
- Vehicle Variant / lc_var_veh

Those have actual read/compare/branch style evidence. I also have a larger semantic seed list of around 200+ possible scalar/config/switch candidates, but I am keeping nearly all of those hidden or review-only until they have proper xref proof.

The sort of evidence I am looking for is:

- load byte/word from calibration
- compare against zero or constant
- mask bitfield
- branch based on result
- use as threshold
- feed into diagnostic/monitor/torque logic
- call a function based on variant/config state

What I am asking for help with

I am mainly looking for advice on the correct Siemens MS45 / MPC555 reverse-engineering setup:

1. Correct Ghidra or IDA processor settings for MS45/MPC555.
2. Correct memory map for full 1024 KB reads.
3. How to correctly handle the MPC/internal code read versus external flash.
4. What base address people normally use for MS45 external flash/calibration.
5. How others map 116/128 KB partial calibration reads back into the full flash.
6. Whether there are known MS45 memory map notes, Funktionsrahmen docs, A2L details, or IDA/Ghidra loader tips.
7. Best method to import XDF/A2L/RomRaider labels and then find reliable code references.
8. How to tell when a calibration address is truly referenced by code versus just appearing as an immediate/address-like value.

I am not trying to pretend the MS45 disassembly is solved. The XDF/export side is now fairly organised, but I am trying to move from “this label looks right” to “the code actually uses this value here”.

Any pointers on MS45/MPC555 loading, address mapping, or calibration xref workflows would be appreciated.

[pman92]

Have a look at this:
viewtopic.php?t=8976

Different ECU, same MCU, same principles apply.

Having a good time in ghidra is all about getting everything setup properly. Correct and complete memory map. Make sure code is loaded to correct address. Find and set correct r2/r13 register values for the code. Etc.

The MPC555 user manual will be your best friend.

AI is also very useful for analysing disassembly, and can often give you a better insight into what a chunk of disassembly is doing, compared to ghidras decompiled view.
GhidraMCP plugin is definitely worth time setting up.

Other than that, familiarise yourself with keyboard shortcuts in ghidra. Keep a notepad on your desk to note down addresses of interest for whatever your currently looking at. You'll be hitting 'G' to jump back to them often.

The single most powerful thing you could do once everything is setup, is get AI to help you create a python script to parse your XDF, and use a pyghidra script to import and label all those addresses.

Most of all have fun. Making progress in ghidra is addictive once you get results

[KingAustraliaggGG]

Legend, setting up all that today. Will make a GitHub when I done