Limp mode with a clean DTC memory on a 2AD-FHV D-CAT is almost always one of two things: either the ECU is torque-limiting from an internal model (soot/ash accumulation, airflow deviation, boost deviation) that doesn't set a code by itself, or the codes are there but not visible on a generic scanner. So before touching the file again, split the problem.
1. Prove it's the software, not the car
Flash your verified original back and drive the same route until it would normally go limp. If the stock file also limps, you're chasing a mechanical/sensor issue, not a tuning issue — and the 2AD D-CAT is famous for it (clogged DPNR, sticking VN turbo actuator, EGR cooler, injector deviation, oil dilution from failed regens). No point patching anything until that's ruled out.
2. Read it properly
Generic OBD is useless on these. Use Techstream and check:
- Pending + history codes in all systems, not just engine
- PM accumulation / soot estimate and DPF differential pressure
- Exhaust temp sensors (all of them) and A/F sensor
- Target vs actual MAF and target vs actual boost at the moment it limps
- Fuel-addition injector data (D-CAT has the exhaust fuel adder, it's not just in-cylinder post injection)
The pair that deviates first tells you which limiter is firing.
3. If only the modified file limps
That's the classic sign of an incomplete DPF-off on DPNR: regeneration was blocked but the accumulation model was left running, so calculated soot climbs, crosses threshold, and the ECU pulls torque — often without a stored code. Same story on EGR: if you switched off the valve/blanked it but left the airflow targets untouched, the MAF target vs actual delta will trigger a limitation. Three different tools giving the same result usually means the same incomplete strategy, not three separate bugs.
Also worth confirming: was the checksum recalculated correctly for this Denso, and is the DPNR still physically fitted and loaded?
About your attachment
I can see the archive contains a single 768 KB
MB175800_org.MPC — I haven't analysed the bytes, and a 768 KB read on this family looks like a program-area read only. Please confirm:
- Ktag protocol used and read type — bench or boot, full or partial
- Whether you read twice and the two dumps compare identical
- Whether you also have the data/EEPROM area saved separately
- What you used for checksum correction
- Exact limp behaviour: how many minutes/km, under load or cruise, does it clear on ignition cycle or stay until codes are erased
Post a Techstream data list screenshot from just before it drops into limp and this gets a lot easier to pin down.