Why won't my EDC17C46 start after changing the driver wish map?

[ThomasPirowski]

Your EDC17C46 won’t start after even a small driver wish change because the ECU cross-checks driver wish (DAMOS folder AccPed_DrvDemDes, map AccPed_trqEng on EDC17) against a paired 8-bit monitoring shadow — MoFDrDem_rTrqEng in folder MoFDrDem_Co. At key-on the ECU compares both; if they differ, ignition is blocked with a torque monitoring error. Fix: scale the primary driver wish together with every monitoring map your specific bin actually ships with — the Layer 1 shadow (MoFDrDem_rTrqEng, what blocks the start) and/or the Layer 2 runtime pair in MoFLos_Co (MoFLos_trqEngLos 16-bit + MoFLos_rTrqEngLos 8-bit — what causes limp mode once the car is moving). Keep the change under 10% — 5-7% is the safe zone.

Bin-to-bin variability is normal. Some bins ship only Layer 1, others only Layer 2, many ship both, EDC16 ships neither. No fixed recipe — survey your specific DAMOS, find what’s actually there (grep MoF* prefix), then move everything found together with driver wish. Below is how each map behaves and why it matters.

---

The question — from Q&A #1

Dmitri asked during our first live Q&A session:

“On the EDC17C46, making minimal changes to the driver wish map — after which the engine did not respond to the gas pedal. What could this be connected with?”

His symptom is one of the most common no-start traps in modern diesel tuning. And it has nothing to do with the driver wish map itself. It’s about what the ECU checks alongside it.

---

Why the monitoring map matters

Driver wish is always monitored. If you do changes that are not synchronous with the monitoring of the driver wish — which will be absolutely at the beginning of the map tree — the torque monitoring error fires at key-on (00:40:53).

Many EDC17 variants — including EDC17C46 — pair the driver wish with a monitoring copy called MoFDrDem_rTrqEng (folder MoFDrDem_Co — Monitoring Function: Driver Demand). The ECU reads both at key-on and checks they match. If they don’t, the ECU blocks ignition before the engine cranks. This paired-shadow structure is variant-dependent: it’s not on every EDC17, and EDC16 doesn’t use the same mechanism. So before you touch driver wish, open your DAMOS and confirm whether your specific ECU actually ships MoFDrDem_Co/MoFDrDem_rTrqEng. If it doesn’t, you may still have Layer 2 in MoFLos_Co (covered below) — or neither, depending on the bin.

Why producers use different bit-widths (Layer 1)

This is the clever part. The producer doesn’t duplicate the map. They hide the pair on purpose:

Parameter	Primary driver wish	Layer 1 monitoring shadow
Folder	AccPed_DrvDemDes	MoFDrDem_Co
Map ID	AccPed_trqEng	MoFDrDem_rTrqEng
Bit-width	16-bit	8-bit
RPM axis	Standard factorization	Different factorization
Location in binary	Within driver wish section	At the very beginning of the map tree
Max value example	403 N·m (native units)	~99.6% displayed in WinOLS (= raw 255, the 8-bit hardware max, after the configured factor)

Why does WinOLS show ~99.6%? That’s the producer’s saturation pattern, just shown through the configured factor. The map is 8-bit (raw range 0–255), and the factor is set so raw 255 displays as 99.609% — exactly the hardware ceiling. The producer pre-fills the cells at saturated raw 255 on purpose. Any upward change in primary driver wish then crosses what the shadow allows, and the ECU sees a mismatch at key-on. So when you look at the screenshot below, the 99.6% cells aren’t “almost at the limit” — they are the limit. There’s no headroom left in the shadow to follow your driver wish edit upward.

Real EDC17 Layer 1 monitoring shadow (DAMOS MoFDrDem_rTrqEng). Notice values saturated at 99.609% = 255 in 8-bit raw form — the producer’s intentional pattern that catches any driver wish increase at key-on.

Important disambiguation — two different 8-bit maps in diesel monitoring. Layer 1’s MoFDrDem_rTrqEng (this section) and Layer 2’s MoFLos_rTrqEngLos (covered further below) are different maps in different folders with different roles. Both are 8-bit, both carry rTrq in the name, but they answer different questions:

• MoFDrDem_rTrqEng (folder MoFDrDem_Co) — key-on integrity shadow of driver wish, saturated at raw 255 (≈ 99.6% in WinOLS display).
• MoFLos_rTrqEngLos (folder MoFLos_Co) — runtime torque-loss ratio, tracks proportionally during driving.

Don’t conflate them. If both are present in your bin, you have to scale both.

The producer is very clever — they prepared this map to be at maximum, factorized, so this is the ceiling (00:42:18).

Why even 10% is probably too much

The monitoring copy sits at the saturated ceiling. Any upward change in primary driver wish crosses the threshold. My rule of thumb:

• Under 5% — usually survives without touching monitoring
• 5-7% — safe zone for our engineering-first approach
• ≥10% — probably detected. Scale monitoring by the same amount, or the engine won’t start

---

Key-on vs running — different behavior

The ECU handles the mismatch differently depending on when it’s detected:

At key-on (your case, Dmitri)

There is nonsense in starting the engine (00:42:54).

Sequence: turn key → ECU reads primary driver wish → reads monitoring copy → sees delta above the safety threshold → blocks ignition. No crank, no start.

While engine already running

Different safety logic. The ECU cannot shut down a running engine on a monitoring error alone. The driver might be overtaking, merging, or in a risky traffic spot. Instead:

• Error code stored
• Power reduced (limp mode)
• Engine continues to run

Two different mechanisms, but for your bin the gating one is at key-on. The comparison runs fresh every ignition cycle — ECU reads driver wish, reads the shadow, compares. There’s no stored error to clear: if the delta exceeds the threshold, no-start, every time you turn the key.

---

How to fix it — practical workflow

Step 0 — Survey your specific bin before editing anything:

Open the DAMOS of your actual file and grep MoF* prefix. Three things can happen:

• Found MoFDrDem_Co/MoFDrDem_rTrqEng → Layer 1 is present. Follow Part A.
• Found MoFLos_Co/MoFLos_trqEngLos and/or MoFLos_rTrqEngLos → Layer 2 is present. Follow Part B (next section).
• Found both → do both parts in full.
• Found neither → your bin has a different (or simpler) protection scheme. Don’t invent maps that aren’t there; scale only the driver wish and verify on the bench before delivery.

No fixed recipe. Match the work to what the bin actually ships.

Part A — Layer 1 (the no-start fix, if MoFDrDem_rTrqEng is present):

1. Locate MoFDrDem_rTrqEng — usually at the start of the map tree in WinOLS®, before any main injection structures
2. Check the bit-width difference — primary should be 16-bit, the shadow is 8-bit (or a 1-byte variable-byte map)
3. Check max value on the shadow — in WinOLS the cells should display at ~99.6% (≈ 100%), which is raw 255 after the configured factor. If you see that ceiling, you’ve confirmed the saturated pattern
4. Scale primary + shadow together — when you raise primary driver wish by X%, raise the shadow max by the same X%
5. Keep the total change under 10% — 5-7% is the safe engineering ceiling
6. Check RPM factorization on both — primary and shadow should track the same RPM axis, even if factorized in different units

Part B — Layer 2 (the limp-mode fix, if any MoFLos_* map is present): Steps 1-6 above will get the engine to start if Layer 1 is present, but if Layer 2 also exists in your bin, the car will cold-start fine and then drop into limp mode under load as soon as you drive it. That’s Layer 2 catching up. See the next section for the MoFLos_Co maps.

---

The second monitoring layer you’ll meet — the MoFLos_Co folder

Dmitri’s symptom (key-on no-start) comes from the Layer 1 key-on integrity check I described above: MoFDrDem_rTrqEng — the 8-bit paired shadow saturated at raw 255 (≈ 99.6% in WinOLS display), which fires at ignition when the primary driver wish doesn’t match.

Many bins also ship a second monitoring layer that bites at a different time — during driving, not at key-on. In day-to-day tuning, this is the one most tuners mean when they say “the monitoring map”. It lives in a different folder (MoFLos_Co, Monitoring Function: Losses — a sibling to MoFDrDem_Co under the broader MoF* diesel monitoring umbrella) and uses two different maps working together:

• Folder: MoFLos_Co — “Function Monitoring: Torque loss engine”

• Map IDs (two types in the same folder):

  • MoFLos_trqEngLos — Type 1, 16-bit (absolute Nm representation of torque losses)
  • MoFLos_rTrqEngLos — Type 2, 8-bit (ratio/scaled representation; r prefix = ratio in Bosch naming)

• Visual examples from a real EDC17 binary:

  
  Layer 2 Type 1 — MoFLos_trqEngLos (folder MoFLos_Co). 16-bit representation in absolute N·m. Row axis = coolant temp (°C), column axis = RPM.

  
  Layer 2 Type 2 — MoFLos_rTrqEngLos (same folder MoFLos_Co). 8-bit ratio form (% scale). Same RPM × °C grid, different encoding. Both maps have to move together.

• What they do: together they track plausible torque losses (engine friction, accessories, pumping losses) in real time. Part of the Bosch EGAS Level 2 monitoring layer. In the torque structure: trq_indicated = trq_driver_wish + trq_losses.

• How they break during tuning: if you raise driver wish without scaling both types by the same amount, the ECU sees engine output exceed the plausible torque envelope. The result: fault code and limp mode while you drive. Both maps have to move together — raising only the 16-bit and leaving the 8-bit ratio untouched still triggers the fault (and vice versa).

So the rule generalises:

Layer	Folder	Map(s)	When it triggers	Symptom
Layer 1 — key-on static integrity	MoFDrDem_Co	MoFDrDem_rTrqEng (8-bit shadow, saturated)	Turn key	No crank, no start (Dmitri’s case)
Layer 2 — runtime EGAS monitoring	MoFLos_Co	MoFLos_trqEngLos (16-bit) + MoFLos_rTrqEngLos (8-bit ratio)	While driving	Limp mode, power reduced, engine stays alive

Bin-to-bin reality again: both folders are optional per variant. Your file might have both, one, or neither. Dmitri’s EDC17C46 hit Layer 1 specifically — that’s what I walked through in the Q&A. A later customer on a different bin might only have Layer 2, or neither. Always survey before you scale.

If Layer 1 was present, you fixed MoFDrDem_rTrqEng, and the car starts but drops into limp under load — Layer 2 is what you haven’t scaled yet. Open the MoFLos_Co folder, find both MoFLos_trqEngLos (16-bit) and MoFLos_rTrqEngLos (8-bit ratio), and scale each by the same amount as your driver wish change.

---

Maps referenced in this guide

Concept	DAMOS Folder	Map ID	ECU	Deep dive
Driver wish (primary, 16-bit)	AccPed_DrvDemDes	AccPed_trqEng	EDC16, EDC17, MD1	This KB (deep dive)
Driver wish monitoring — Layer 1 (8-bit paired copy, saturated at raw 255 ≈ 99.6% in WinOLS)	MoFDrDem_Co	MoFDrDem_rTrqEng	EDC17 variant-dependent (confirmed EDC17C46); not on EDC16; presence varies bin-to-bin	This KB (deep dive)
Torque losses monitoring — Layer 2 Type 1 (runtime EGAS, 16-bit absolute Nm)	MoFLos_Co	MoFLos_trqEngLos	EDC17 (variant-dependent); similar on MD1; not on EDC16	This KB (deep dive)
Torque losses monitoring — Layer 2 Type 2 (runtime EGAS, 8-bit ratio)	MoFLos_Co	MoFLos_rTrqEngLos	EDC17 (variant-dependent); similar on MD1; not on EDC16	This KB (deep dive)

Parallel gasoline platform: MED17/MG1 use a different DAMOS convention. Gasoline monitoring lives under the MonDrvDem* folder family (Monitoring Driver Demand) — for example MonDrvDemA_tq in folder MonDrvDemAVW (VAG pedal monitoring variant; other OEMs have their own MonDrvDem* variants). This is gasoline-only — never on diesel. Diesel monitoring lives under the MoF* umbrella — split across sibling folders like MoFDrDem_Co (Layer 1 key-on driver demand check) and MoFLos_Co (Layer 2 runtime torque losses). Same underlying principle (“raise driver wish without matching every active monitor = fault”), different folder families. And on both platforms the specific maps present vary bin-to-bin — always survey before scaling. For the gasoline failure mode (raising DrvDemA_tqCluDemAceped without matching its MonDrvDem* monitor = limp), see KB-11 — MED17 torque conversion path.

---

Related on Tuners Guild

• Full EDC17 methodology: Bosch EDC17 Tuning Guide — maps, physics, methodology (pillar reference)
• Complete diesel workflow (22 chapters): Chip Tuning Diesel — Practice course
• Course pricing and bundles: See pricing →

---

Want the full methodology?

This specific case is one example of the synchronous monitoring problem — a pattern that repeats across modern ECUs (EDC17, MED17, DCM6, DENSO) but never in a fixed shape. Every bin is different: some ship Layer 1 only, some Layer 2 only, many ship both, older families ship neither. The full 22-chapter Bosch EDC17 Practice course I teach walks through the actual workflow — how to read a DAMOS under MoF*, identify which monitoring maps are present on your specific file, scale all of them together with driver wish, and verify both cold starts and full-load pulls before the car leaves your bench. Understanding the concept beats memorising a fixed list of IDs.

See the Chip Tuning Diesel course →

---

Your turn

Has anyone here seen the same no-start symptom on a different ECU family — EDC16, Siemens SID, Delphi DCM6, Continental EMS? Post your case:

1. ECU code and engine
2. What you changed (driver wish / flow / torque structure)
3. Where the error showed up (key-on / idle / under load)
4. How you isolated the monitoring copy

We’ll compare the patterns — the more ECU families we document, the easier future tuners can troubleshoot their specific case.

[stanislav]

The first time I encountered this problem was in 2013. It was a 2011 Kia Sportage with a Bosch EDC17C08 ECU. The client returned after tuning with the engine in limp mode and was very dissatisfied.