mitsubishi triton

Ratings and Reviews
Total ratings: 0
Sort by date Sort by votes

Post #2

FCM (Forward Collision Mitigation) delete is possible on some Tritons, but it depends heavily on the exact model year and which module holds the function. On most of these the radar/FCM control is its own module, so "deleting" usually means either coding/disabling it or editing the module data — not a simple engine ECU tune.

To point you the right way, tell me:

  • Exact year and engine (e.g. 2.4 DI-D 4N15)
  • Why you want it removed — permanent fault in the FCM radar module, or just want it switched off?
  • Any current DTCs and which module they sit in
  • What tool you have for reading/coding (dealer-level scanner, bench read, etc.)

If it's a fault, in a lot of cases the cleaner fix is repairing/coding the radar module rather than trying to delete the function. Post the DTCs and we can narrow it down.
 
Upvote 0 Downvote

Post #4

Understood — if the radar module itself is dead and you can't source a replacement, then disabling the function and clearing the cluster warning is the realistic path. A couple of important points first:

The FCM/warning behaviour on these Tritons is usually controlled by coding/variant configuration across the FCM radar, the cluster (meter) and sometimes the body/ETACS side, all talking over CAN. So it's not always a single "delete" — you typically have to code out FCM participation so the cluster stops expecting messages from the radar and stops throwing the warning.

Whether it can be done cleanly by coding vs. needing an EEPROM/flash edit depends on the exact year. So I need:

  • Exact year and engine (e.g. 2016 2.4 DI-D 4N15, or later MQ/MR facelift)
  • The current DTCs and which module reports them — is the FCM radar showing "no communication / internal fault", and is the cluster warning driven by that?
  • What tool you have — MUT-III / clone, or a bench/EEPROM setup? This decides whether coding-off is possible or you need to edit module data

If you post the fault list and confirm the tool, I can tell you whether it's a coding change in the cluster/FCM config or whether it needs a module data edit to stop the light and message.
 
Upvote 0 Downvote

Post #6

Good, that helps — a 2019 4N15 is the MQ-series Triton, so FCM/FCM warning is handled through coding/variant config across the FCM radar, the meter cluster and the ETACS over CAN.

Two things still decide whether this is a clean coding-off job or a module data edit:

  • The exact DTCs and which module reports them — is the FCM radar showing "no communication / internal fault", and confirm the cluster warning is being driven by that radar fault
  • What tool you have — genuine MUT-III / clone, or a bench/EEPROM setup

On the MQ platform, if the radar is truly dead and you have MUT-III access, the usual approach is to code FCM out of the variant/coding so the cluster stops expecting radar messages and drops the warning. If MUT-III can't fully disable it on your car, then it comes down to editing the coding data in the cluster/FCM config — but I don't want to guess the exact bytes without knowing your tool and the live fault list.

Post the DTC list and confirm your tool and I'll tell you which route applies.
 
Upvote 0 Downvote

Post #8

If MUT-III can't code FCM out, that's often because the coding/variant function needs the radar to be communicating to accept the change — and with a dead radar it just fails or greys out. So the coding route can dead-end exactly for the reason you want to delete it.

That pushes you toward editing module data directly. On the MQ platform the two realistic targets are:

  • The meter cluster (combination meter) EEPROM — to stop the FCM warning light/message being displayed
  • The FCM/ETACS coding data — to stop the cluster expecting radar messages over CAN

But before anyone can point at exact bytes, I still need the missing pieces:

  • The exact DTCs and which module reports them — is the FCM radar itself showing "no communication / internal fault", and is the cluster warning tied to that?
  • When you say both tools "cannot perform" — what exactly happens? Coding option greyed out, throws an error, or writes but nothing changes? The exact message matters
  • Can you do a bench/EEPROM read of the cluster (and FCM if reachable)? That decides whether a data edit is even on the table

Post the fault list and tell me exactly how the tools fail, and we can work out whether it's a cluster EEPROM edit or an ETACS/FCM coding edit.
 
Upvote 0 Downvote

Post #10

There isn't a copy-paste "delete FCM" tutorial for the MQ Triton that's safe to just follow blind, because the exact fix depends on your live faults and what your tools actually do. But here's the honest general workflow so you know what the job involves:

  1. Confirm where the warning comes from. Read all modules and note the exact DTCs. You need to know if the FCM radar shows "no communication / internal fault" and whether the cluster warning is driven by that.
  2. Try the coding route first (MUT-III). On a healthy car you code FCM out of the variant config so the cluster stops expecting radar messages. With a dead radar this often fails or greys out — which is likely why yours "cannot perform."
  3. If coding dead-ends, it becomes a module data edit. That means a bench/EEPROM read of the combination meter (to stop the warning light/message) and/or the ETACS/FCM coding data (so the cluster stops waiting for the radar). This is not done through MUT-III — it needs an EEPROM/bench tool and someone to compare the good vs. bad data.

So the "tutorial" can't be generic — the exact bytes only make sense against your actual reads. To move this forward, post:

  • The full DTC list and which module reports each
  • Exactly how MUT-III fails when you try FCM coding — greyed out, error message, or writes but nothing changes? The exact text matters
  • Whether you can do a bench/EEPROM read of the cluster (and the FCM if reachable) — if yes, upload the dump

Get the cluster EEPROM read and the fault list up, and we can look at whether it's a meter EEPROM edit or an ETACS/FCM coding edit.
 
Upvote 0 Downvote

Post #12

Right, that confirms it — a dead FCM radar with no communication is exactly the case where MUT-III coding usually won't take the change, because the variant/coding routine wants the radar on the bus to accept it. So on your car the coding-off route is likely a dead end, and it moves to a module data edit.

With "no comms FCM," the practical path is:

  • The FCM DTC will sit as "no communication" in the cluster and probably ETACS too, and that's what drives the warning/message.
  • To kill the light and message you're looking at a bench/EEPROM edit of the combination meter, and possibly editing the ETACS/FCM coding so the cluster stops expecting radar messages on CAN.
  • This is done off the car with an EEPROM/bench tool — not through MUT-III.

Before anyone can point at actual bytes, I need to see the data, not guess it. Please post:

  • The full DTC list with which module reports each (confirm the exact FCM code, e.g. U-code for lost comms)
  • A bench/EEPROM read of the combination meter — that's the file where the warning display lives
  • The cluster part number / EEPROM chip type if you can read it off the board

Upload the cluster dump and the fault list and we can compare against a known-good state to work out what stops the light. Without the actual read there's no safe byte-level tutorial to give.

Which EEPROM/bench tool do you have for reading the cluster?
 
Upvote 0 Downvote

Post #14

Good — the Multiprog is the right kind of tool for this, it'll read the combination meter EEPROM/flash on the bench once you identify the chip. Key Tool Plus won't really do the cluster edit part, so Multiprog is your workhorse here.

Next steps to actually move forward:

  • Pull the combination meter out and open it, then identify the EEPROM/flash chip on the board (e.g. 93Cxx, 24Cxx, 95xxx, or the MCU-internal type). Post a clear photo of the board and the chip markings.
  • Read the cluster with Multiprog and save the original untouched dump before anything else — that's your safety net.
  • Post the full DTC list with the exact FCM U-code and which modules report it (cluster / ETACS), so we confirm the warning is driven by the lost-comms fault.

Once you upload the original cluster dump and the chip type, we can compare against a known-good state to work out what stops the FCM light and message. I don't want to name bytes blind — it has to be against your actual read.

One thing to check first: can Multiprog even see/read your cluster chip on the bench, or are you still at the stage of opening it up? Tell me where you're at and post the board photo.
 
Upvote 0 Downvote

Post #16

Sounds good. Read it with Multiprog and upload the original untouched dump, plus a clear photo of the cluster board so I can see the chip markings. Also grab the full DTC list with the exact FCM U-code and which modules report it. Once that's here we can compare against a known-good state and work out what stops the light and message.
 
Upvote 0 Downvote
Activity
So far there's no one here

Similar threads

Sahil670
  • Question Question
Ecu suzuki swift 2008 mark mitsubishi MH8104
    • Like
Replies
0
Views
2K
Reactions
1
Sahil670
Sahil670
Bin
EvoScan Cable, Protocol & Logging Setup — Mitsubishi/Subaru Support
    • Like
Replies
0
Views
15
Reactions
1
Bin
Bin
aleksey-ms
Mitsubishi FUSO Commercial Pack: Dealer Repair Manuals & Wiring Diagrams
    • Like
Replies
0
Views
102
Reactions
2
aleksey-ms
aleksey-ms
aleksey-ms
Mitsubishi MMC ASA (All Regions): Global Electronic Spare Parts Catalog
    • Like
Replies
0
Views
73
Reactions
1
aleksey-ms
aleksey-ms
aleksey-ms
Mitsubishi Motors Tech Database: Service Manuals & Electrical Wiring Diagrams
    • Like
Replies
0
Views
124
Reactions
1
aleksey-ms
aleksey-ms