NGC3 (sci-B) immo off?

The behavior you're describing, immo coming back after a power/ground cycle, almost always means the change isn't landing in persistent storage. On NGC3 the SKIM/immo state isn't just one flag; there's typically a stored value plus a validation copy, and on init the module reconciles them. If you only patch the live/working copy (or an OBD tool writes a soft state), the controller rewrites it back from the reference on the next power-up, so it looks "re-enabled."

A few things worth separating out:

• Fact from your post: SKIM is disconnected before and after, three tools tried, state reverts on cycle. That points at a persistence/validation issue, not a wiring or write-failure issue.
• General guidance: On these you usually need the immo-off applied in the actual EEPROM/flash region that survives reset, and any mirror/checksum that guards it has to be corrected in the same write. An OBD-level "disable" that doesn't touch the stored reference will revert.
• Inference: If HPT is the only one that sticks, it's likely writing the persistent location (and fixing the guard) rather than a runtime flag. That's consistent with what you're seeing.

To point you at the exact next step, can you post:

• The controller part number and HW/SW rev
• Vehicle year/model/engine
• How you're reading and writing, OBD vs bench/boot, and whether you have a full read including EEPROM (not just cal)
• Whether the tools reported a successful write/verify or just a "done"

If you can attach the read (or at least the EEPROM dump), that's the fastest way to confirm whether the immo status and its validation copy are both being handled.

Gemini said:

The behavior you're describing, immo coming back after a power/ground cycle, almost always means the change isn't landing in persistent storage. On NGC3 the SKIM/immo state isn't just one flag; there's typically a stored value plus a validation copy, and on init the module reconciles them. If you only patch the live/working copy (or an OBD tool writes a soft state), the controller rewrites it back from the reference on the next power-up, so it looks "re-enabled."

A few things worth separating out:

• Fact from your post: SKIM is disconnected before and after, three tools tried, state reverts on cycle. That points at a persistence/validation issue, not a wiring or write-failure issue.
• General guidance: On these you usually need the immo-off applied in the actual EEPROM/flash region that survives reset, and any mirror/checksum that guards it has to be corrected in the same write. An OBD-level "disable" that doesn't touch the stored reference will revert.
• Inference: If HPT is the only one that sticks, it's likely writing the persistent location (and fixing the guard) rather than a runtime flag. That's consistent with what you're seeing.

To point you at the exact next step, can you post:

• The controller part number and HW/SW rev
• Vehicle year/model/engine
• How you're reading and writing, OBD vs bench/boot, and whether you have a full read including EEPROM (not just cal)
• Whether the tools reported a successful write/verify or just a "done"

If you can attach the read (or at least the EEPROM dump), that's the fastest way to confirm whether the immo status and its validation copy are both being handled.

Click to expand...

It is a Wrangler 4.0 with the NGC3 (sci-B) part number P56044703AD and the tools were not able to read the memory(eeprom or flash), they just performed id/get info and skim disable

beantoat said:

It is a Wrangler 4.0 with the NGC3 (sci-B) part number P56044703AD and the tools were not able to re...

Click to expand...

Thanks, that fills in the key gap. If none of the three tools can actually read the EEPROM/flash and are only doing ID + a SKIM-disable command over SCI, then you're confirming exactly what I suspected: those are OBD-level soft writes, not a persistent edit. The NGC3 reconciles its stored immo state on init, so a command-based disable that never touches the stored reference (and its guard copy) gets rewritten on the next power-up. That's why it reverts on power/ground cycle regardless of which of the three you use.

So the takeaway:

• Fact: Tools only do ID/get-info + a disable command, no memory read/write. That's a runtime/soft change, not persistent.
• Inference: To make it stick you need to write the actual persistent immo-off in EEPROM and correct any checksum/mirror in the same operation. An SCI command-level disable won't survive reset on this controller.
• General guidance: On the P56044703AD NGC3 that usually means a bench/boot read of the module so you have the full dump including EEPROM, edit the stored SKIM state offline, fix the guard, and write it back. That matches why HPT reportedly "sticks", it's writing the persistent location rather than issuing a command.

To point you at the exact next step: are you set up to pull the module and do a bench/boot read, or are you strictly OBD only right now? If you can get a full read (EEPROM included) and post the HW/SW rev off the label, that's what determines whether an offline immo-off edit is practical here.