ISTA+ DME Blue Block - MEV1746 MV1746 Bmw E Series LCI

Post #1

N Online now

nogeren

Stock Member

Russia
Joined
06.07.2026
Messages
11
Reactions
0
Location
Russia
Hello, please help. BMW e87 lci 2008 n46b20
I have:
  • original DME
  • donor DME
both marked 7 585 247 and 0 261 s04 289
The original one broke at the service center!
They said the unit wasn't communicating, but I saved it.
We bought a donor kit - (CAS + DME + key) - installed it, and the car started. (The donor VIN, ISN, etc., was preserved.)

The donor DME was flooded.
I extracted the entire donor backup using ktag.
1) 973 KB file
2) 128 KB eeprom file
3) 4 MB flash file
4) 2 MB MPC
I decided to read the ORIGINAL DME.
1) 284 KB file
2) 128 KB eeprom file
3) 30 KB flash file (garbage)
4) 2 MB MPC

I decided to upload the donor's flash to the ORIGINAL DME
and read the ktag again.

1) 627 KB file
2) 128 KB eeprom file
3) 4 MB flash file (inside the donor's flash)
4) 2 MB MPC

The car now recognizes the original DME.
The DME is now blue in ISTA+, previously, it wasn't detected at all.

Available
ISTA+ 4.50.12 ISTA-P 3.72 WINKFP
VCX SE BMW
KTAG KESS R207+
ISTA+ 4.50.12 - doesn't program, says go to ISTA-P 3.72 - it's been working for us for a very long time....

WINKFP gives this error
switching programming mode failed 03ME17, DIAGNOSE_MODE (ECUPM) ERROR_ECU_SECURITY_ACCESS_DENIED_ SECURITY_ACCESS_REQUESTED
Flash download failed 03ME17, FLASH_SCHREIBEN (..): IFH-0009: No response from controlunit
Flash download failed 03ME17, FLASH_SCHREIBEN (..)
Flash download failed SG_PROGRAMMIEREN
Flash download failed
Tell me where I made a mistake?
 
Ratings and Reviews
Total ratings: 0

Post #2

The blue block in ISTA+ is expected here — you've got a mismatch between what's physically in the flash and the ECU's internal identity/security state, so ISTA+ refuses to touch it and WINKFP fails at security access. That's the core of it.

The key problem: you wrote the donor's full flash into the original DME, but the EEPROM stayed original (your read shows the 128 KB eeprom each time). So now the ECU has donor calibration/program data but original EEPROM identity data. The security access is derived from data that no longer matches, which is exactly why you get:

Code:
ERROR_ECU_SECURITY_ACCESS_DENIED_SECURITY_ACCESS_REQUESTED

and then IFH-0009 (no response) once it tries to enter programming mode.

A few things to sort out before going further:

  • On MEV17.4.6 the ISN and security data live in the EEPROM/internal area, not the external flash. Copying only the flash region leaves the ECU internally inconsistent.
  • Since your original EEPROM survived (you read a valid 128 KB), the cleaner path is usually: keep the original EEPROM (original ISN/identity) and write only matching flash+cal to it, then let ISTA-P do a full recover/programm. Mixing donor flash + original EEPROM is what's producing the blue state.
  • WINKFP won't recover a DME that ISTA+ marks blue — you need ISTA-P (which you have, 3.72) to do a full "encode/programme" recovery once identity is consistent.

To tell you exactly what to correct, I need a couple of specifics from your dumps:

  • Confirm the exact ECU family from the label — is it MEV17.4.6 or MEVD17.4.6? (your title says MEV1746)
  • Which EEPROM are you currently running in the original DME right now — original or donor?
  • Are the ISN in original DME EEPROM and the CAS ISN the same? On a donor CAS+DME+key set the ISN should match the donor, so if you kept original DME EEPROM the ISN will conflict with the donor CAS.

That last point matters a lot: you said the donor CAS + DME + key made the car start, but now you're trying to run the original DME against the donor CAS. If the ISN in the DME doesn't match the ISN the donor CAS expects, EWS/DME alignment will fail regardless of flash. Post the ISN from original DME EEPROM vs the CAS ISN and we can confirm whether it's a security-access mismatch or an EWS sync issue.
 

Post #3

Hello
MEV17.4.6
The original DME uses the original EEPROM.
I used a donor FLASH in the original DME
I'm currently using the original CAS + original DME + key (ISN original).

I currently have two sets:
1) Original CAS + original DME + key (previously fully functional)
(DME stopped working after the update)
2) Donor CAS + donor DME + key (previously fully functional)
(Water got into the DME - it's not working properly)

I decided to upload the donor's flash to the ORIGINAL DME
The car now recognizes the original DME.
The DME is now blue in ISTA+, previously, it wasn't detected at all.
 

Post #4

Good, that clears up the identity picture: original EEPROM (original ISN) + donor flash in the original DME, running on the original CAS. So the ISN/CAS pairing is consistent — that's not your problem. The blue block now is a software/programming-state mismatch, not an immo mismatch.

Here's what's happening: the donor flash you wrote carries the donor's I-level / program+cal version and internal progman counters, but the ECU is being addressed as your original VIN/order. ISTA+ sees an ECU whose actual flash content doesn't match the expected SW status for that vehicle, so it marks it blue and refuses OBD programming until it's brought back to a known state. WINKFP then dies at security access / IFH-0009 because it can't negotiate programming mode on an ECU in that inconsistent state.

The realistic fix is to let ISTA-P 3.72 do a full recovery/programme of that DME to your car's target I-level. That's exactly the case ISTA-P is built for (blue/unrecognized SW state), and it's why ISTA+ told you to go to P. WINKFP alone won't dig it out of blue.

Before you run it, a few things worth checking so it doesn't fail mid-flash:

  • Same MEV17.4.6, same part number both units? You said both are marked 7 585 247 / 0 261 S04 289 — good, so the target SW ISTA-P wants should be flashable.
  • Was the donor flash a full read (internal MPC + external flash) or partial? If the external 4 MB flash went in but the internal MPC/pflash region is still original/garbage, WINKFP/ISTA-P can't complete programming mode — that alone produces IFH-0009.
  • Stable bench or in-car supply — 13.5V constant during ISTA-P recovery, no battery charger noise.

To tell you the exact next click, confirm:

  • Did you write both the 4 MB external flash and the 2 MB MPC (internal) from the donor into the original DME, or only the external flash?
  • What's the target I-level of the car (from ISTA-P vehicle info) vs the donor's SW status?
  • When ISTA-P sees the DME now, does it list it for a "Programmieren/Nachprogrammieren" action, or does it also refuse it?

My suspicion is you copied only the external flash and left the internal MPC original — that's the usual cause of a DME that goes blue and then blocks security access. Confirm the MPC question and we'll know which way to go.
 

Post #5

I copied only the external flash, and left the internal MPC original.
 

Post #6

This is exactly the root of the problem. If you flashed the external 4 MB from a donor and left the internal MPC/pflash original, then inside the unit you have two incompatible parts: the external flash with the donor firmware and the internal MPC with its own (original) program version. MEV17.4.6 is addressed as a single image - the controller checks that the internal and external parts match, and when they do not, you get a blue block plus a security access failure and IFH-0009.

The correct logic for MEV17.4.6:

  • The internal MPC (pflash) and external flash must be from the same dump / the same version.
  • EEPROM (ISN/identification) can be left original - that part is already correct.

So you have two workable paths:

  1. Restore consistency manually - write the same version into the internal MPC as the one in the external flash (that is, the donor one), while leaving the original EEPROM. Then the software part will become coherent, and ISTA-P 3.72 can then bring the block up to the required I-level for your car.
  2. Restore the original completely - if you still have a valid original external flash (not that 30 KB junk), restore both parts as original and repair the block through ISTA-P.

In practice, the first option is usually easier, since your original external flash is not readable.

To be more precise, clarify:

  • Your donor MPC dump (2 MB) - is it a full read KTAG or a partial one? Is it from the same donor as the working 4 MB flash?
  • Did you save the original MPC (2 MB) before writing? Does it read as valid?

If the donor MPC is complete and from the same unit - flash it into the internal memory of the original DME so the internal and external parts match, then run ISTA-P for recovery.
 

Post #7

Я завел двигатель,
Подскажи мне у меня ошибка в ISTA+ - 2b79 DME Система впуска с изменяемой четвертой передачей, активация.
напомню мотор N46B20BZ
 

Post #8

Good news that it's running. Before chasing wiring, keep in mind the unit is still in the mixed state we discussed (donor external flash + original internal MPC, never properly programmed/coded to your car), so some faults will be artifacts of that rather than real hardware.

How to split real vs. artifact

2B79 in your reading is an activation/output-stage fault for the variable intake (DISA) solenoid, i.e. the DME is complaining about the driver output, not about a plausibility/position deviation. That gives you three candidates:

  • Electrical — open circuit or short on the DISA solenoid or its wiring to the DME.
  • DME output stage — the original DME already "stopped communicating" at the shop; a damaged final stage on that pin is possible.
  • Software/variant — the donor calibration may not match your vehicle's equipment/variant, so the DME tests an actuator channel that is configured differently than your car is wired. This is inference, not confirmed, but it's very common after a flash from another unit.

Next steps, in this order

  • Clear the fault, run an ISTA component activation on the DISA valve with the engine off, ignition on, and listen/feel for the solenoid clicking. Then check whether 2B79 comes back immediately (current) or stays stored only.
  • Measure the solenoid coil resistance at the valve connector and compare both sides of the harness for continuity to the DME pin. An open coil or a chafed wire is the cheapest explanation.
  • With ignition on, check that the solenoid gets B+ on the supply side; the DME switches the ground side. No supply = fuse/harness, not DME.
  • Check the DME connector and the DISA connector for corrosion/green pins — you've had a water-damaged unit in the mix, and the shop had the car apart.
  • Record the freeze-frame/environmental data for 2B79 (open circuit vs. short to ground vs. short to B+). That single detail usually decides harness vs. DME.

If the valve and wiring measure good and activation does nothing, I'd treat it as either a dead output stage in the original DME or a variant mismatch from the donor flash — and in that case the real fix is still to get the DME into a consistent software state and programmed/coded to your car's I-level, then re-evaluate the fault list. Faults diagnosed on a mismatched flash are not trustworthy.

To go further, post:

  • The exact DTC text and freeze-frame data as ISTA shows it (screenshot is fine).
  • Whether the fault is current or stored after clearing and a short run.
  • Measured DISA solenoid resistance and the DME pin continuity result.
  • Current SW status of the DME as read by ISTA/WINKFP, and whether you have done any VO/FA coding since the flash.
 

Post #10

That matters for interpreting the fault list, but it should not be the cause of 2B79. On N46 the HFM (MAF) and the DISA output stage are separate channels — an unplugged MAF sets its own codes (plausibility/signal, typically 2A3x / 2B2x range depending on I-level) and forces the DME onto substitute load values from throttle angle and MAP. It does not trigger an activation fault on the intake manifold solenoid output.

What the unplugged MAF does do:

  • Fills the memory with secondary faults (mixture adaptation, load plausibility, sometimes misfire entries), which makes it impossible to tell which codes are real.
  • Changes the load signal that the DME uses to decide when to switch DISA, so component activation and plausibility checks won't behave normally.

So the order should be: plug the MAF back in, clear all faults, run the engine briefly (idle plus a short rev to ~3000 rpm), then re-read. Only the codes that come back after that are worth diagnosing. If 2B79 returns with the MAF connected, go through the three steps from my previous post — ISTA component activation on the DISA valve, coil resistance at the valve connector, and continuity/supply to the DME pin.

One question, since it changes what I'd suspect: was the MAF disconnected deliberately (to get it running, or because it was suspected faulty), or is it still unplugged from the work at the shop? And when you re-read, post the full fault list with the MAF connected, not just 2B79 — with the mixed flash state in that DME I'd want to see whether the DISA code appears alongside other actuator/variant faults, which would point at the calibration rather than the harness.
 

Post #12

That settles it — 2B79 is almost certainly a software artifact, not a hardware fault. If the engine has no intake manifold flap at all, the DME can only be logging an activation fault on that output because the calibration it's running expects a DISA-equipped variant. That's the donor flash talking, not your car.

Why this fits
  • An activation/output-stage code on a component that physically doesn't exist means the channel is enabled in the data set and the DME finds no load on the pin — exactly what you'd expect from a flash that was never coded/programmed to your vehicle's variant.
  • Both units share the same Bosch number (7 585 247 / 0 261 S04 289), but the base number doesn't guarantee the same calibration — equipment and market variants differ inside. Inference, but it matches the symptom.
  • It also means you can stop chasing the DISA wiring and solenoid — nothing to measure there.

What this does not fix
The unit is still in the mixed state from earlier in the thread: donor external flash + original internal MPC, never properly programmed. Coding alone won't clean this up. The order stays the same as before — get the internal MPC and external flash onto the same version, then let ISTA-P 3.72 programme and code the DME to your car's I-level. After that, 2B79 should disappear by itself because the correct data set won't have that output enabled. Until then, expect more phantom codes of this type.

Right now
  • Plug the MAF back in before reading anything — otherwise half the list is secondary noise.
  • Clear faults, idle plus a short rev, re-read, and treat 2B79 as low priority unless the car actually runs badly.

Two things that would help: the donor car's model/engine (if you know what the CAS+DME set came out of — a DISA-equipped N46 would confirm the variant theory), and the full fault list with the MAF connected. Also confirm whether 2B79 comes up as current or stored only.
 

Post #13

с блоком все впорядке - я восстановил оригинальный CAS+DME обновил и закодировал!
 

Post #14

Nice work — that's the right outcome, and it means the earlier mixed-flash state is off the table.

With the original CAS+DME restored, programmed and coded, the picture for 2B79 changes. If it's gone from the fault memory after the update and coding, it was exactly the data-set artifact we suspected and there's nothing to chase. If it still comes back on the properly coded unit, then it's no longer a software story and only two things are left:

  • The vehicle order / coding data still lists the DISA-equipped variant for your car, so the output channel stays enabled even though the hardware isn't there. Worth checking the VO and the SALAPA/equipment data rather than the DME itself.
  • An actual open on that DME output pin — but on an engine with no flap fitted that's a dead end to measure, so I'd treat the VO as the suspect.

Before you judge it, plug the MAF back in (if it's still off), clear the memory, idle plus a short rev to ~3000 rpm, then re-read the full list. Codes that survive that are the real ones.

If 2B79 does reappear, post the complete fault list with freeze-frame info and your current I-level / DME SW status after the update — with the unit now in a clean state, that's enough to tell whether it's the VO or something else.
 

Post #15

у меня есть ошибка 2b79 disa нету, и есть ошибка 2ef2.
в данной комплектации нету disa !
 

Post #16

Two separate things here, so treat them separately.

2B79 with no DISA fitted
If the engine genuinely has no intake flap, then the DME is running a calibration/variant that expects one. After a proper ISTA-P programme the program variant is picked from the vehicle order, so the thing to verify now is the VO/FA on the car — if it still describes a DISA-equipped variant (or carries anything from the donor side), the output channel stays enabled and the code will keep returning no matter how many times you clear it. That's inference from the symptom, but it's the only explanation that fits "activation fault on a component that isn't there".

Two practical outcomes:
  • VO is wrong for your car → correct the VO, re-programme and re-code the DME; the fault should then stop being generated.
  • VO is correct for an E87 LCI N46B20BZ and ISTA still demands DISA → then the engine/intake in the car does not match the vehicle's own build data (engine swap or a replaced intake manifold), and you'd either fit the solenoid or live with a stored code. It is not a drivability fault.

2EF2
I don't want to guess at this one from the number alone — the text differs between I-levels. Post the exact ISTA description for 2EF2 as it appears on your car, plus whether it's stored or current.

Also, before judging either code: is the MAF plugged back in? While it's disconnected the DME runs on substitute load values and will set secondary faults, and 2EF2 may well be one of them.

What I need to go further:
  • Full fault list (all codes, not just these two), with current/stored status and freeze-frame data
  • DME SW status / I-level after your update
  • The vehicle order (FA) as read from the car
  • Confirmation that the MAF is connected
 

Post #17

после запуска мне не понравилось, так как работал мотор, было много дыма!
я поменял три раза масло и три масляных фильтра и сделал 2 раза раскоксовку двигателя - это не помогло, двигатель так же дымил.
я вытащил клапана VANOS почистил их в химии, подавал коротко на них 12 вольт они работают щелкают. После поставил в автомобиль, дыма стало на 90% меньше, но мне не нравиться звук как работает двигатель! Есть шум и воет он.
 

Post #18

Sounds like you've made real progress — if the smoke dropped by 90% after cleaning the VANOS solenoids, the original cause was almost certainly stuck solenoids holding the cam timing far off, so that part was diagnosed correctly. Residual smoke after a decoke is also normal for a while, since chemicals and loosened deposits keep burning off for a few hundred km.

The noise is the part to pin down now

"Whine/howl" and "rattle" point to completely different things on N46, so first classify it before changing anything:

  • Metallic rattle/chatter from the front, worst at cold idle, fades when warm — timing chain and chain guides/tensioner. Very common on N46 and it also affects cam timing, so it ties into your VANOS story.
  • Howl/whine that rises and falls with engine speed, from the rear of the cylinder head — the brake vacuum pump. A classic N46 whine, cheap to confirm.
  • Whine that changes when you load the electrical system or steering — accessory belt, tensioner, idler, alternator or PS pump. Easiest test: run the engine briefly without the accessory belt and see if the noise disappears.
  • Buzzing/grinding near the valve cover that follows load changes — Valvetronic eccentric shaft servo motor.

Practical order

  • Stethoscope or a long screwdriver on: timing cover, rear of head (vacuum pump), valve cover near the Valvetronic motor, each belt pulley. That alone usually settles it in five minutes.
  • Check oil level and viscosity now that you've changed it three times — an overfilled or wrong-grade oil on N46 gives both smoke and odd noise, and a low level makes the VANOS units rattle.
  • In ISTA live data, look at camshaft position deviation / VANOS control deviation at warm idle and around 2000 rpm. If the chain is stretched or the guides are worn, the deviation will be visible there, and it would also explain why cleaning the solenoids only partly helped.

Still open from before

  • Is the MAF plugged back in? With it disconnected the DME runs substitute load values — that affects mixture, smoke and idle quality, so any judgement on noise and smoke is unreliable until it's connected.
  • I still need the exact ISTA text for 2EF2 and whether it's stored or current — on N46 the 2Exx range can be VANOS/Valvetronic related, and if it is, it's directly connected to the noise you're hearing.

To go further, post: the full fault list after a clear and a short warm-up run, the camshaft deviation values, and if you can, a short video or sound clip of the noise at idle plus a slow rev — that's usually enough to tell a chain from a vacuum pump.
 

Post #19

2EF2 Сигнал датчика температуры всасываемого воздуха DME. гугл пишет что 2b79 это VVT. Я менял два ролика на новых и поставил новый приводной ремень, звук не изменился. Звук не влияет на прогрев! Что на холодную, что на горячую звук одинаковый! смотрел фазы Vanos через ista+ все градусы в допуске! я смотрел на цепь она натянута! Насос гидроусилителя не шумит... когда руль поворачиваю слышу как он дает давление, но оно не сильное.
 

Post #20

Good data points — two of them actually lock things down.

2EF2 — intake air temperature sensor, DME
On N46 the intake air temperature sensor is integrated into the HFM (MAF) assembly, not a separate sensor in the intake tract. You said the MAF is unplugged. That alone generates 2EF2. This is not a mystery and not worth any measuring — plug the MAF back in, clear the memory, and 2EF2 should not return. If it does return with the MAF connected, then it's the sensor element in the HFM or its wiring (pins to DME), and that's a simple resistance/voltage check at the connector.

2B79 — I think my earlier DISA reading was wrong
Your ISTA text ("variable intake system, activation") plus what you found online points to the inlet camshaft VANOS solenoid output, not an intake manifold flap. That makes much more sense on an N46B20BZ with no DISA fitted, and it ties directly into the work you just did:

  • You pulled both VANOS solenoids out, cleaned them, tested them with 12 V. An activation fault on that output is exactly what you'd get from a connector not fully seated, a bent/pushed-back pin, or a damaged pigtail after refitting.
  • Check: coil resistance at the inlet VANOS solenoid connector (both solenoids, compare them against each other — they should be close), then continuity from solenoid connector to the DME pins.
  • Then run the ISTA component activation on the inlet VANOS valve and see whether 2B79 sets as current again on the spot.

Note that "angles in tolerance" in ISTA does not clear the solenoid output — the fault is about the electrical driver, not the achieved position. So the cam timing can read fine while the code still sets.

The noise
What you've just excluded is useful: belt, rollers, temperature dependence, chain tension, VANOS angles. That leaves a short list for a howl that is identical cold and hot:

  • Brake vacuum pump (rear of the cylinder head, driven off the exhaust cam) — classic N46 howl, completely temperature-independent, follows rpm. Listen with a stethoscope directly on the pump body; also check whether the noise character changes if you briefly pull the vacuum line off the pump with the engine running.
  • Valvetronic eccentric shaft servo motor — buzz/whine from the valve cover area, changes with load/throttle rather than with temperature.
  • Unmetered air leak / intake or exhaust gasket — an air leak can howl rather than hiss, is rpm-dependent and temperature-independent. With the MAF unplugged you have no way to see the effect on the load signal, which is another reason to plug it in first.
  • Power steering — I would not write it off. You say the assist pressure feels weak when you turn the wheel. Weak assist plus noise usually means low or aerated fluid, or a suction-side leak at the hose/clamp between reservoir and pump. Check the fluid level and whether it looks foamy, and inspect the low-pressure hose and clamp. Air in the system makes the pump howl even when the pump itself is fine.

Order I would follow
  • Plug the MAF in, clear all faults, idle plus a short rev to ~3000 rpm, re-read. Only the codes that survive that matter.
  • Stethoscope on: vacuum pump, valve cover near the Valvetronic motor, PS pump body, timing cover. Five minutes and it usually settles the question.
  • Check PS fluid level and condition.

To go further, post:
  • The full fault list with the MAF connected, and whether 2B79 is current or stored.
  • A short video/audio clip of the noise, taken from the engine bay, with a rev from idle to ~3000 rpm.
  • VANOS actual vs. target for inlet and exhaust at idle and at ~2500 rpm, plus the solenoid resistance values you measure.
  • Your current I-level and DME SW status after the programming.
 
Activity
So far there's no one here