Siemens MS45.1 DME

Hardware

A Motorola MPC555 with an external AMD Am29BL802CB, a 1 MB bottom-boot flash on a 16-bit bus. The program lives across both: part in the MPC555's internal flash (448 KB), the rest and the calibration in the external chip. A small serial EEPROM on the MPC555's QSPI holds what the DME learns.

RAM is 26 KB, not 32

The MPC555's SRAM is 0x3F9800-0x3FFFFF: 10 KB from 0x3F9800 and 16 KB from 0x3FC000. The 6 KB below it, 0x3F8000-0x3F97FF, is reserved in the user's manual and does not exist on the chip. The DME agrees three ways: the loader clears RAM from 0x3F9800, its RAM self-test covers 0x6800 bytes from there, and its diagnostic address table lists RAM as 0x3F9800-0x3FFFFF. firmware

The external chip

Sector layout from the datasheet, which is also how the DME is partitioned. Offsets are into the chip. firmware

The chip is single-bank. While it erases or programs, every read returns status, so no code can run from it. Anything that writes the chip from the running program has to execute from SRAM or internal flash with interrupts off. Erase Suspend is ignored in burst mode, which the DME turns on at boot, so the chip cannot be erased with the engine running. firmware

The boot loader is not one build. Two DMEs of the same part number differ in their boot blocks from 0x285B on; the flash driver inside is byte for byte the same but sits 0x24 further along in one of them. Code that looks for something in the boot region by address will find it in one unit and not the other. car

The internal flash

The MPC555's 448 KB is 14 blocks of 32 KB in two modules, programmed in 64-byte pages. The DME programs it with the chip maker's own driver, which the loader keeps in the 96 KB boot sector (0x14AFC- 0x162F8) and copies to RAM for the job. That driver programs one page in every selected block per pulse sequence: a page takes about 24.6 ms on silicon whether it is one block or twelve, so the same data goes in about four times faster when the blocks are written side by side. Programming needs the EPEE pin, which the loader raises on a MIOS port pin (0x306100 bit 0x40) before any flash work; without it the driver refuses with 0x87. car firmware

The serial EEPROM

A 4 KB (32 Kbit) part on QSPI chip select 1. Reading 64 KB of it gives the same 4 KB sixteen times, because the address wraps, so a write past 0xFFF lands on real data. car

• Read at boot, written in the after-run. The stored data (adaptions, faults, mileage, the immobiliser record) is read once at start-up and written back only after the ignition goes off, each record twice with a read-back: about 1200 writes on a blank part, 35 s of after-run. emulator
• Only the program sets the QSPI up. The boot loader never touches the QSPI module, so anything that runs before the program finds it at its reset state: slave mode, pins as plain I/O. A read started in that state waits for ever and the watchdog resets the DME. car
• "RAM check" means the EEPROM. Fault 2869 (P16A3, "self-test: RAM check") is set when the stored-data restore at boot fails: one block is kept three times and must agree two of three, another must hold a valid record. A blank or torn EEPROM fails it; a DME with its own EEPROM passes. It is not about the SRAM. emulator car

The programming session

This is the order of jobs in a whole-program flash, from a real flasher log. The emulated DME answers every step the same way. car emulator

1A 89                          read serial number
31 07 03 <4 bytes>             read the seed
31 08 00 00 00 10 <key>        send the key       -> 71 08 01 accepted, 71 08 00 refused
10 85 05                       programming session, 115200 baud
83 03 00 78 18 F0 00           timing: P2max 3 s, P3min 12 ms
31 02 06 00 00 02 0A 00 00     erase the program: 0x02060000 + 0xA0000
34 .. 36 .. 37                 download the external program, 253-byte blocks
34 00 00 00 06 00 07 00 00     download the internal flash: 0x06000000 + 0x70000
31 02 04 00 00 02 02 00 00     erase the calibration: 0x02040000 + 0x20000
34 04 00 00 02 00 01 D0 00     download the calibration
10 81 01                       default session, 9600 baud (the loader keeps running)
31 09 02                       check the program signature -> 71 09 01
31 09 04                       check the data signature    -> 71 09 01
11 01                          reset

• Addresses go as bytes 2, 1, 0, then 3. The external chip is 0x02000000 + offset and the internal flash 0x06000000 + offset. There is no separate erase for the internal flash: erasing the program region erases the external program sectors and all of the internal flash. emulator
• The erase is categorical. The range in the request is ignored: asked for the top 64 KB, the first 64 KB or the internal window, the loader wipes the same whole program area plus all of the internal flash every time. Only the calibration erase is its own category, so there is no partial program flash. emulator
• The key answer is 71 08 01 for accepted. A positive answer 71 08 00 means the key was refused, so checking only for 71 passes a wrong key. car
• The serial number used for the key is the last four bytes of the answer's payload, not of the telegram, which ends in a checksum. car
• Reading needs no unlock. A calibration read works in the default 9600 baud session. car
• The first erase hands over. The running program takes the first erase request, shuts itself down and jumps into the boot loader. That request is never answered; the next one is served by the loader. emulator
• The log entry comes last, and only then. The programming log write (3D) is accepted only after an erase and a download in the same programming session; at any other time it is refused with 7F 3D 22. A tool that only checks signatures can never add an entry. emulator

Baud rate is a parameter

The loader's 10 85 <code> takes codes 0-5 from a table: 2400, 9600, 19200, 38400, 57600, 115200. Any code of 6 or more is followed by a 24-bit baud rate, so 10 85 06 03 D0 90 asks for 250000, and the answer echoes it. The serial divider is round(1250000 / baud). The stock loader can therefore run any rate the line carries without a patch. emulator

Timing

A block answer is 76 <counter, 2 bytes> <status>, with status 01 for written and 02 for failed.

Blank blocks can be skipped

After an erase, downloading only the runs of bytes that are not FF leaves the chip identical to a full write. The signature check passes and the program starts. Runs may start at odd addresses and be a single block long. The stock calibration has 125 of 470 blocks blank at the end, the external program 535 of 2590. emulator

Hand-off or park

At every reset the loader runs first, from the vector at 0x100. About 117 µs in, it has checked the flash and takes one of two roads. emulator

• Hand-off. With a valid program and calibration it jumps to the program through one branch at 0x4EBC. Nothing else in the loader runs again until the next reset or the next programming session.
• Park. When the checks fail it waits a moment, then calls its 9600 baud server at 0x5228: an idle loop over a countdown table and a list of callbacks that answers identification, the status job and a new flash for as long as the power stays on. A valid boot never executes that call.

Content decides, not the marks on their own. Blank valid marks with a good calibration still start the program, because the loader re-verifies the checksums; invalid content parks it. A read over diagnostics shows the marks as FF anyway, so a dump never tells you whether they are set. emulator car

Parked, the loader answers a tester at 9600 like a running DME would: 3E (tester present), the hardware reference (22 25 02, "0044570" on this unit), the other reference numbers, and 31 0A with status 0C. A read of the programming log then comes back all FF if the top sector was erased. car

A factory flash leaves the loader alone

The whole-program session above writes the external program (0x60000-0xFFF3F), the internal flash and the calibration. Nothing in it touches the boot region below 0x40000, and nothing could: the loader's sector table at 0x1F900 gives the boot sector no write permission, so no erase or download request reaches it, whatever address it names. The only writes into that sector are the loader's own, its programming log entries. emulator firmware

The other way round, code running on the DME itself can rewrite the boot sector: the chip has no hardware protection there. A power loss between erasing the 96 KB sector and writing it back leaves a DME that neither boots nor flashes, because the loader that would serve a new flash is what was erased. Only a hardware programmer brings such a unit back. emulator

What makes a flash valid

The loader computes checksums in the background, ten bytes per pass, both CRC-32/MPEG-2. emulator

• Program: over the internal flash and the external program, stored at 0x60000 and 0x60340.
• Calibration: over 0x40200-0x5CFFF, with start, end and initial value from the header at 0x40104, stored at 0x40100. The running program re-checks the same range in the background.

31 09 then checks the references and an RSA signature over the MD5 of the listed segments. On success it writes marks into the last bytes of the sector. emulator

Status after a flash

31 0A reports where the loader stands. emulator

A half-written program is recoverable: after an erase the DME stays in its boot loader and accepts a new program flash. car

What the program checks about itself

Once running, the program keeps testing its own memory. Two of those tests matter to anyone who changes the flash. firmware emulator

ROM test level 1: three checksums, including the boot block

A background task walks a CRC-32/MPEG-2 over three ranges in turn, each described by a small table in the flash with its seed and stored word beside it. One full walk takes about 5 s.

The range excludes the top 2 KB of the sector: the sector table, the ISN and the programming log can change without touching the word. The safety monitor's own code sum ("ROM test level 2", stored at 0x60600) is a separate, simpler sum over the program and is what a patched program has to correct as well.

Reset reasons

The DME keeps a record of its own resets in RAM with a reason code. A reset without a record came from outside the program: the watchdog, or the monitoring module. Code 11 is the checksum walk above; the watchdog is serviced at the very end of the 10 ms task chain, so a watchdog reset means the chain did not finish, an unexpected exception or a jump into erased flash. A program patch that ran correctly at idle on the emulator and reset the real car at 3100-3400 rpm under load left no record: it ran its extra code from the external chip on paths the idle run never took, and the 10 ms budget was exceeded. car firmware

The programming log

Every successful flash leaves an entry (the AIF, in the diagnostic description's terms) in the tail of the boot sector, external 0x1FB34-0x1FFFF, in 64-byte slots. A slot is empty when its first byte is FF; every reader walks from the first slot and stops at the first empty one. firmware emulator

• 14 entries, not 19. 19 slots fit in the area, but the DME's log read (a window of service 23, what the description's AIF_LESEN uses) answers offsets below 0x380 and refuses the rest with 7F 23 52, even with 19 slots written. The description counts 14 free, and so does the DME. emulator
• The identity lives here. The VIN, the programming date, the software and assembly numbers that a tester shows for the DME come from the newest entry. A DME whose log is blank identifies with those fields empty, and its next entry gets software number 0000000, because the previous one was the only copy. car
• The boot block checksum excludes it, so entries can be added without changing anything else, which is how the loader itself adds them. Flash only clears bits: a change that only clears bits can be programmed over a slot in place, anything else means rewriting the sector. emulator

A slot

Decoded by running AIF_LESEN on marked slots; all fields round-trip. Offsets are into the slot. BMW data emulator

The immobiliser

The DME is married to the car's EWS3 by a 16-bit number, the ISN. The two talk over their own wire with a rolling code; the number itself never goes over the K line in plain. Found on three DMEs and settled by pairing two of them to one car. car firmware

Where the ISN is

In the external flash at 0x1FB00, as three transformed copies of the value V that the boot code votes on, after a marker halfword (FEFE, ECEC or C8C8):

Bytes 2-3 read raw give the wrong number, which is an easy mistake: only the low byte of that copy is straight. 0x1FB00 sits above the boot block checksum's range, so writing it changes no checksum.

The EWS3 will not tell you its ISN

The EWS3 (DS2 address 0x44) answers identification (part 6905670) and its status, and refuses ISN_LESEN and PASSWORT_LESEN with A2 on a paired car with the ignition on. There is no precondition it waits for: in BMW's own description both jobs are one bare telegram each, with no login or state job in front. A paired EWS3 declines by policy, so the car's ISN has to come from its original DME, read from 0x1FB00 of a dump. car BMW data

Pairing a used DME

1. Write the car's ISN into the used DME's triple at 0x1FB00.
2. Run the EWS start-value sync (the EWS3 description's WECHSELCODE_SYNC_DME and the DME's start-value jobs), which realigns the rolling code. The telegram to the EWS is 44 04 67; nothing secret crosses the K line.
3. Ignition off for 20 s, then crank. The pairing is committed by a real start; it may take two attempts.

The DME's lock flag (STATUS_EWS_LOCK, 21 49, LV_LOCK_IMOB) reads 1 right up until the engine actually starts. A 1 after a good sync is not a failure. Done twice with two different donor DMEs; the car started both times. car

How fast the K line goes

With the DME's serial port set to each rate, over a K+DCAN cable on one car. car

The K-line transceivers documented for this era are rated to about 200 kBaud, so anything above that is outside spec and depends on the cable and the car. A line that is one-way at a high rate is a trap: the DME takes the request to switch and the tester never hears the confirmation, so a tool must fall back on its own when no answer comes.

Reading values while it runs

The stock program serves a logger in the default session, with no authentication. Measured on the emulated DME with the engine stopped. emulator

A 30-byte packet read back to back: 103 ms a read at 9600 (10 Hz), 57 ms at 115200 (17 Hz), 20 ms at 115200 with the timing set (50 Hz). About 9 ms is the floor; the diagnostic task comes round no sooner. The programming session has the same timing limits but refuses 21, 22, 2C and 18, so it is no use for logging. A real cable has to turn round in 2 ms for the fast timing: an FTDI adapter needs its latency timer at 1 ms, not the default 16.

The calibration definition

Checked by running the program and comparing every read it makes against the community XDF. emulator

• Coverage is complete. All 4,325 single-value reads land on a defined constant with the right start and size, and every table the lookup routines are handed is defined.
• One axis is missing: a 6-point 16-bit axis at calibration 0x8E30, used by the cruise control.
• 320 items have no description, 264 constants and 56 tables.
• One scaling looks wrong: c_temp_cur_on_ls_down is defined as 1/16 °C, but the variable it is compared with is 1/64 °C minus 33. Of 359 constants whose scale the code reveals, the other 354 agree.

See also

• Diagnostics and the K line - How the E46-era units talk on the K line, what their answers mean, and what the cables and adapters in between can carry
• GS20 automatic gearbox - The control unit of the E46's five-speed GM automatic