RomRaider

I'd really like to help people with P1610 NATS lock mode for ECUs used in engine conversions.

I can currently only disable NATS if the ECU is not already in lock mode (if ignition has been turned on less than 5 times since the NATS receiver and/or key have been missing). If it's in P1610 lock mode, disabling NATS has no effect. I understand discussing disabling NATS publicly is not good but my question is ONLY regarding P1610 lock mode, regardless of if NATS is enabled or disabled.

Disabling P1610 via the DTC SupMask only hides the code but the vehicle still can't start. Lock mode is still there in the background.

The only solution I currently have to get an ECU out of P1610 lock mode is to read the EEPROM from another vehicle using nisprog, remove the EEPROM chip from the locked ECU and flash the readout from the other vehicle with a chip programmer.

The factory service manual refers to a "NATS INITIALIZATION" that the Consult II can do but NDSII does not. This would be very handy to figure out how to do with manual commands.

Has anybody had success with EEPROM writing via K-Line other than Shuher?

From what it appears, EEPROM writing via K-line is certainly possible. I’ve seen plenty of references to the EEPROM within the code, including writing to it. The issue is, no matter what, Nisprog would have to be adapted for it. Unless you want to send 0x1FF (for CF48D) bytes manually and just hope you don’t mistype lol Now that I think about it, you’re actually able to rewrite individual bytes in the EEPROM. So technically, if you could find the lockout byte, you’d be able to alter one specific value and fix the issue quite easily. Then that would leave just finding the right SID and ARBID’s.

My guess is it’s probably something within $A0. But $AC allows reading the EEPROM values. (Slowly, byte by byte with two requests per byte.) It’s unfortunate that they decided against using $AC’s DLIDs for $3B. That would be pretty cool to be able to write to RAM/EEPROM via creating DLIDs haha But I’m sure $A0 holds some cool RAM/EEPROM write stuff.

But if $A0 doesn’t support EEPROM writing, then you’d have to rely on one of the separate SID trees. As of right now, we’re not even sure if they’re accessible or not. I’m fairly confident that they are, but there’s always a chance that they never can be reached. $80 seems extremely promising as well. But it’s only in separate SID trees.

I'll have a good look in Ghidra tonight at anything that refers to the P1610 support mask bit in the ROM and DTC status array in RAM and hopefully find something I didn't find in previous attempts.

You may need to go one level higher :
- find the functions that clear/test/set individual bits in the DTC status array, these usually take the DTC index as argument in r4
- find where those functions are called with r4 == dtc_index_for_1610

IIRC the code doesn't ever really go and mess with DTC status bits directly; it's always (?) via helper functions like that.

Have you tried a 0x11 0x80 reset with nisprog followed by a power cycle?

Haven't tried it for this purpose myself, but it might help.

Well this is embarrassing

The first vehicle I tried the NATS disable on (remotely) must have had an unrelated issue stopping his engine from starting and the P1610 lock mode fault must have been a coincidence because I've just tried it on another vehicle and the vehicle starts and runs fine! The P1610 fault is still there but it does not stop the engine from starting and running. I just disabled P1610 via the DTC SupMask.

How you guys disable it?
I mean, I found the DTC on .bin, as the image attached, should I change the next byte?