Communication Protocol Analysis

Pytrex · **Posted:** Wed Jul 28, 2021 9:46 am

Hello all!

This thread will basically just be partially documenting my progress with analyzing KWP2000 and ISO-15765 functionality for a 2006 USDM Nissan 350z 5AT Coupe. A full analysis and notes will be available on the linked wiki page. I'd highly recommend avoiding taking anything stated here as fact, as this is more of a draft thread than official data. Use the wiki for official answers! I'm keeping the wiki up to date to act as proper documentation just in case anyone ever wants to utilize them. But unless you're building an application to communicate with control modules, I'd highly recommend avoiding sending any SIDs yourself. While the odds of you bricking your ECU are slim to none, there's just no reason to be risking such a thing when Nissan Datascan 2 can do everything you need more effectively, and more safely, than manually sending commands.

On that note, I would HIGHLY recommend purchasing Nissan Datascan 2 (~50 USD). It works with the same cable you use for Nisprog and it'll do everything any normal user would need.

ECU Progress:
- Full $3B Support (VIN Writing!)
- Full $21 Support (Just CUID lol)
- Full $22 Support (Eventually will be added to the public logger def)
- Full $31 Support (Key Reprogramming, Idle Relearn, etc!)

ECU Plans:
- $09 (Pretty sure this is just the same as $09 for OBD-II protocol)
- $30 (Partially defined right now, but plenty more to go!)
- $A0 (EEPROM Functionality Probably)
- $A4 (SID request provides a memory address.)

Wiki Page-> https://nissanecu.miraheze.org/wiki/Com ... _Protocols

Pytrex · **Posted:** Sat Oct 02, 2021 11:53 am

Made some progress recently. $A3 is most likely going to be the read DTC SID, as it calls the DTC RAM block to test for set DTC's.

$A0 has some really crazy operation where it can actually hard reset the ECU, do something similar but force the fuel pump to continually prime till key off, etc. There are tons of EEPROM references inside that $A0 function, so I'm not exactly sure what's happening.

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 652

Pytrex wrote:

Wiki Page-> https://nissanecu.miraheze.org/wiki/Com ... _Protocols

Is that supposed to eventually replace this page : https://nissanecu.miraheze.org/wiki/C2_14230
? They look like mostly duplicates but we should only have one such page. Let me know your thoughts on that and we can reorganize the pages accordingly.

Quote:

- Why don’t any of the modules seem to support $17? (You’d think that since freeze frame data can be read with the standard $12 SID,

No idea, but on the K-line ECUs I've dealt with, freeze-frame data is accesible only via an iso9141 OBD-compliant session. Connection as a 14230 link gives access to a different set commands, but seems like they didn't bother to enable that.

Quote:

but what are LID’s in $21, and what are the dynamically defined LID’s in $AC?

So the way I use it in nisprog is that AC 81 ... "Creates" a LID, numbered 0x81, with the contents specified. Such as 13 ROM/RAM addresses, or a bunch of CIDs, or what have you. Then using SID 21 81 , it retrieves each of the items that were defined with the most recent AC 81 request.
Not sure what other LIDs there are, I forget.

Quote:

- Has anyone looked into $31-$33 commands? (It seems likely that testing sensors and such will be handled by these.)

See at the end, I pasted all my old notes on that. Haven't looked at those in years and didn't bother to clean up / publish them.
Anything that is done via "work support" functions (the service manuals often mention that for various troubleshooting tests), most definitely uses one of those SIDs.

Quote:

- What exactly could be achieved by $30 I/O control by local ID?

Stuff like activating solenoids etc, I believe. One would need to analyze consult3 software for the real answers.

General SID notes, some of this is already on the wiki

Code:

Some SIDs (e.g. 21) have a TXM field 
TXM==4 : normal response 
TXM==6 : sends a deluge of responses. Not sure how to stop

*** standard SIDs with Niss extensions
 
1A ReadECUIdentification
   1A 80: get fw_version?? resp: 5A X0 X1
   1A 81: get ECUID, resp 5A X0 X1 X2 X3 X4 X5, X0=0x31 often (always?)
   1A 82: ?? resp 5A X0 X1 X2 X3 X4 X5 Y1 Y2?; X==ECUID; Y==? TBD
   1A 83: ?? resp 5A XX
   1A others: badresp.

21 ReadDataByLID:
   21 LID TXM NRESP, TXM et NRESP ses iso14230-3 p.34; needs TXM==4 et NRESP==1 usually
   21 81 04 01: dump data loaded with last "AC 81" request. resp: 61 81 [data]
   
22 ReadDatabyCID:
   22 CIDH CIDL TXM NRESP
   if CIDL=={0, 20, 40, 60} : acts like a "supported CIDs mask"; resp = 62 CIDH CIDL M3 M2 M1 M0 
   else : resp = 62 HH LL [CIDTABLE+LL]db

31 StartRoutine: 31 LID XX YY ?
   => no trace of parsing extra bytes after "31 LID XX YY" in SID_31 handler ! wtf !
   "31 01 01 00 00 06 ff ff n1 n2" for checksum (?)
   see RE_protos

32 stop routine
   32 LID: resp 72 LID

33 request routine results

34 RequestDownload
   34 80 : prepare s***
   34 81 : not in sentra
   34 82 : not in sentra
   34 83

36 TransferData
   36 BKH BKL 20 <32 bytes data>
   BK is the block # : 00 00; 00 01; 00 02 etc.

37 RequestTransferExit
   37 CKH CKL : 16-bit sum of all decrypted bytes sent through sid 36.
   First response is always "7F 37 78" RspPending !
   Bad checksum gives "7F 37 91" response

3B WriteDataByLocalId
   3B 00 : get supported LID mask
   3B LID X0 X1


*** SIDS custom
A0 ?

A3 wtf ? deals with DTC likely

A4 ReadMemoryByte?
   A4 G3 G2 G1 G0 TXM NRESP;  Resp: E4 G G G G [GGGG]db
   
AC LoadAdresses?
   complex. Pre-load addresses, then needs SID 21 to retrieve
   AC 81 T2 ... T2 ...; T2 = "fieldtype";
   T2==83 : fieldtype = mem address. ex.:
      AC 81 83 GGGG 83 HHHH ...; resp: EC 81
   T2==02 : fieldtype= CID ? ex.: AC 81 02 12 0B 02 11 03 would load CIDs 120B and 1103

BF ramjump
   BF 00 RamJumpCheck

Very rough, unverified notes; any RAM addresses probably refer to 8U92A rom analysis.

Code:

SID 31 01 : start routine for checksum : "31 01 01 00 00 06 ff ff n1 n2"
 afa0 |= 1 ? looks like AFA0 is bitmask of localroutines in progress (see end of sid32)
31 00: unsure, reads table 3864
LID 1..9: set AFA0+ something, unclear

SID 33, request routine results :, LocID must be 1...9 ?
reads in table at dw 3868[2* lid-1] ?
33 01 : "tst [ffffaba8], 0x40 db, good response if bit==1
33 02: skip directly to goodreply ?
33 03: tst [ffffabc3], 0x02 db; 
33 04: tst [ffffabc3], 0x10 db; 
33 05: tst [ffffabc3], 0x08 db; 
33 06: skip direct to goodreply ?
33 07: same as 33 03
33 08: tst [ffffab19], 0x20 db;

SID 21 (readdata by lid) : complex... SID 21 LID TXM NRESP;
TXM = txmode; NRESP=Max # of resps ? (iso p.34)
ram 8212=TXM, 8214=NRP ; TXM read in sci_tx1byte? @ 11cc4
TXM must be 04 ou 06; else TX bad 12.
   LID < 6: s*** with [3780 + 4*LID]
   LID <= 80 : bad 12
   LID >= 81 : if LID!=[a997] : bad12;
   check AFAF & 0x80; &0x40;
   filtr  illegal addrs ? (stack area ffff0000 - 8000)
   good resp : 61 LID ...
   weird checks, adddr != b374 b375;
   check flags in bd8d;


ram flags 8212 & 8214 used elsewhere too...
8214  sci1_te_ih : if [8214]>[8213] disable RX?...
8212,14  SID22 : copy from [8006,8007?] ;
8212,14  SIDA4 : copy from [8009,800a] 
8212:  SID22, used for TXM ( iso 7.1.1)
8214:  SID22, used for NRESP (iso 7.1.1+)

SID 22: (readdata by common id); CID=dw; TXM must be 4 or 6 else badresp.
if CIDH==11
 complex... table at 3324[CIDL*4] dd; if == FFFFFFFF : badresp.
 prepare resp: 62 CH CL [r6] 
 then  if CDL==0x{0, 20, 40, 60}: (CID mask)
  write [r6+1] [r6+2] [r6+3] into resp !!
 tx resp?? (sub_10fa8)
 if CIDL!=46h : exit
 check [ffff8420] db, exit if 0;
 [ffffa0d0]=0 db (wtf)
 exit
else if CIDH==12:
 complex, esp. if CIDL=0B! reads 3-bytes into ffffbb6c+something.
else if CIDH==13:
 similar to CIDH 12
else if CIDH==14:
 similar to CIDH11?
else if CIDH==15:
 table 36E0+8*CIDL?
else
 badresp

Pytrex · **Posted:** Sat Oct 02, 2021 1:26 pm

fenugrec wrote:

Is that supposed to eventually replace this page : https://nissanecu.miraheze.org/wiki/C2_14230
? They look like mostly duplicates but we should only have one such page. Let me know your thoughts on that and we can reorganize the pages accordingly.

Whoops! Yea, the new page is intended to replace the old one. The reason being that eventualllyyyyy I'll get around to the UDSonCAN stuff, so it's just easier to have everything all in one place. Speaking of which, is there a way to make Nisprog connect to the SRS module? Currently it won't hold a connection maybe due to the fact that the SRS isn't returning an ECU ID? NDS2 can connect to it just fine, so that's what makes me think Nisprog gets mad about the ECU ID thing and just decides it doesn't wanna talk lol

Quote:

So the way I use it in nisprog is that AC 81 ... "Creates" a LID, numbered 0x81, with the contents specified. Such as 13 ROM/RAM addresses, or a bunch of CIDs, or what have you. Then using SID 21 81 , it retrieves each of the items that were defined with the most recent AC 81 request.
Not sure what other LIDs there are, I forget.

That actually makes a lot of sense. Does that mean that hypothetically, we could use $AC to create a couple of LID's and then just have RR logger switch between them all? Not sure on how much it would slow things down, but it seems like it would at LEAST allow you to get tons of data. Wouldn't be useful for tuning necessarily, but it would be beneficial for testing purposes if it could work like that.

But thank you for sharing all that information! I really appreciate it

It would be extremely interesting to attempt to test every SID and ARB ID combination with a spare ECU, as I just keep discovering new things! For example, changing the diagnostic mode for the TCM causes the gauge cluster gear position indicator to go blank! Then obviously the $A0 stuff I mentioned. So it's just kinda cool to see what else there is hidden away.

Pytrex · **Posted:** Sat Oct 09, 2021 10:59 am

Wait a minute, doesn’t that mean that via $AC and $3B, we can write to RAM addresses? Since $21 is read LID and works with $AC, then that means that $3B (write LID) would work as well. So for testing fixed values for, let’s say, ignition timing, you could just have it loop write the RAM address via $3B after setting it with $AC.

If you could actually run fixed values by continually overwriting the RAM address without the ECU being able to update the value, that would be extremely beneficial to have added to RR logger, as it would apply to all ROM’s in terms of functionality.

Pytrex · **Posted:** Sun Oct 31, 2021 7:07 pm

Just some interesting info I found while looking through the Consult 3+ files;

Code:

Header Byte configuration for K-Line protocol (Keyword) This setting is used to properly construct the message header bytes to complete the PDU. 

This parameter is not used if the protocol parameter RawMode is set.

Header bytes are constructed following the rules of the protocol specification. This parameter overrides any keybyte values received from the ECU during initialization, which could be used for automatic header byte construction.

(No Header Bytes);
 
(1 Byte Only) (max size = $3F);
 
(2 Bytes depends on length) 1st byte = size up to $3F, 2nd byte not used else size > $3F 1st byte does not contain size 2nd byte = size up to $FF;
 
(2 Bytes always) 1st byte never contains size information. 2nd byte = size up to $FF;

(3 Bytes Only) 1st byte = Format with size up to $3F 2nd byte = target address 3rd byte = source address;

(4 Bytes depends on length) 1st byte = size up to $3F 2nd byte = target address 3rd byte = source address 4th byte not used. else size > $3F. 1st byte does not contain size. 2nd byte = target address 3rd byte = source address 4th byte = size up to $FF;
 
(4 Bytes always) 1st byte never contains size 2nd byte = target address 3rd byte = source address 4th byte = size up to $FF7 (Ford-9141 Header Format)

From what I'm seeing in the code, I'm positive that this is applicable for SH70XX ECU's. The functions for KWP2000 have a check done with a value (5, 6, 4, etc) to determine which KWP2000 function to utilize. So I believe that we CAN have 255 byte block sizes! Also, all those unique implementations of certain SIDs (Cough cough, ECU reset) depend on this 0-6 mode setting. So there are limitless possibilities if we can figure this out!

By the looks of it, any sizes > 0x3F require you to specify said size with the last byte, where you can specify a size from 0x40 -> 0xFF. Unfortunately, I don't actually have a way of testing this since Nisprog and everything else automatically calculates this size value. Would anyone be able to look into this further via actual ECU testing? Another thing is what exactly is determining this value that gets compared? A potential possibility is that the numbers are the header byte format value. From how it's working in the xml, it seems like it would be something you set just like "initmode" and such.

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 652

Quote:

Header bytes are constructed following the rules of the protocol specification. This parameter overrides any keybyte values received from the ECU during initialization, which could be used for automatic header byte construction.

See iso14230-2, section 4.2 , if you haven't. It explains exactly those types of headers.

If you wanted to experiment with this in nisprog, you could either go full manual (set l2protocol to RAW, l1proto to raw, but I'm not sure if the fastinit would even work...).
Or recompile with different settings, you'll want to look at
np_cli.c around line 424 in cmd_npconn;
freediag/scantool/diag_l2_iso14230.c :877 dl2p_14230_send{}

Pytrex · **Posted:** Sun Oct 31, 2021 11:48 pm

fenugrec wrote:

See iso14230-2, section 4.2 , if you haven't. It explains exactly those types of headers.

If you wanted to experiment with this in nisprog, you could either go full manual (set l2protocol to RAW, l1proto to raw, but I'm not sure if the fastinit would even work...).

Or recompile with different settings, you'll want to look at
np_cli.c around line 424 in cmd_npconn;
freediag/scantool/diag_l2_iso14230.c :877 dl2p_14230_send{}

I’ll definitely have to check all that out over a break or something. Thanks for sharing all that info! Whenever I get around to testing, I’ll certainly update this thread

Pytrex · **Posted:** Sun Nov 28, 2021 10:24 am

fenugrec wrote:

If you wanted to experiment with this in nisprog, you could either go full manual (set l2protocol to RAW, l1proto to raw, but I'm not sure if the fastinit would even work...).

It doesn't mind l1protocol being raw, but it gives an error message of "L2 protocol must be iso14230 to use Nissan commands ! try "set l2protocol"" and doesn't even attempt to connect (as you expected). Haven't tried recompiling yet, however!

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 652

Pytrex wrote:

fenugrec wrote:

It doesn't mind l1protocol being raw, but it gives an error message of "L2 protocol must be iso14230 to use Nissan commands

Have you also tried "diag connect" instead of npconn ? diag_connect is lower level , has nothing nissan-specific and should just do a fastinit, wait for keybytes and start a keepalive timer if successful.

Pytrex · **Posted:** Sun Nov 28, 2021 10:44 am

fenugrec wrote:

Have you also tried "diag connect" instead of npconn ? diag_connect is lower level , has nothing nissan-specific and should just do a fastinit, wait for keybytes and start a keepalive timer if successful.

While I'm not connected to my Z atm, Nisprog DOES actually attempt to connect with "diag connect"! So good call there! We'll have to see what happens when I attempt it when connected, but it looks like it'll at least let me mess around with it. So good call, Fenugrec!

Edit; So diag connect does connect, but any “diag sr” message I send just returns the exact same bytes that were sent. I presume this is to be expected, but wanted to share anyway just in case it’s indicative of something else. Also, do you have any idea what the 0-6 values mean? Because when looking at the ISO-14230 PDF’s, the only format byte values that would work for the full byte length thing would be 0x00, 0x10, 0x20, and 0x30. So I’m not exactly sure what Nissan means by 0-6.

Pytrex · **Posted:** Fri Dec 10, 2021 12:21 am

FINALLY making some progress with this... From sniffing NDS2;

Code:

Clear ECU Self Learns:
04 $31 06 FF FF 39 (Start Routine by LID)
Response: 02 71 06 79 

02 $32 06 3A (Stop Routine by LID)
Response: 02 72 06 7A 

02 $33 06 3B (Request Routine Results by LID) 
Response: 03 73 06 01 7D

-----

Read All DTC's:
$A3
05 E3 01 06 05 00 F4 (I think in this case, P0605 was set, so the "0605" = P0605)

Clear All DTC's:
$14


Distinction Flag Checks:

$30 00 32 (I/O Control : Returns the bytes from the I/O Control Supmask)
06 70 00 E0 D0 00 81 A7 

$30 20 52 (I/O Control: Returns the bytes from the I/O Control Supmask 20)
06 70 20 00 78 34 C1 03 

$30 40 72 (I/O Control: Returns the bytes from the I/O Control Supmask 40)
06 70 40 00 00 00 01 B7 

// For whatever reason, doesn't grab the I/O Control Supmask 60 bytes. I'm guessing it's an oversight, as $30 60 92 would return the proper supmask bytes.

$3B 00 3D (Write Data by LID : Returns the bytes from the WDLID Supmask)
06 7B 00 DF FF F0 00 4F 

$31 00 33 (Start Routine by LID : Returns the bytes from the SRLTBL Distinction Flag Supmask)
06 71 00 AE 00 00 00 25 

 

Not sure why it doesn't use the ECU reset SID, but I'm guessing the routine clears more self learns than the ECU reset does. Next up is going to be sniffing literally everything else lmao. I'm hoping the fast dump or even logging will return the full 255 header formatting, but we'll have to see.

Byte 2 for the I/O responses are the I/O LID.

Edit;
Got some potentially bad news. NDS2's fast dump just bumps the 6-bit length value to 0x2F (Not even the limit lol) and uses $AC 81 83 like usual. I honestly have no idea why it's limiting it to 0x2F, but I do know it's not dumping 255 bytes per request haha This doesn't mean anything really that definitive, since it's not even at the current limit. But it's definitely something interesting to keep in mind.

What’s ironic is that when datalogging, NDS2 actually bumps their length value up to as high as 0x35. Sure it’s only six more bytes, but it presumably shows that their 0x2F length limit for fast dumping isn’t based on an actual packet size restriction. (Correct me if I’m wrong!)

Pytrex · **Posted:** Tue Dec 14, 2021 11:26 pm

Well, went through a bunch of Consult CSV files because they included the bytes sent for certain functions. Since it's meant to cover a wide array of vehicles, the data isn't immediately useful until we can verify and group together certain functions.

For example "$31 01 10 22" is used to write the EEPROM (Pretty sure the csv files are all referencing UDSonCAN), but we'd have to actually figure out which ECU's it's applicable for.

Pytrex · **Posted:** Wed Dec 22, 2021 11:12 am

Well, that's really interesting. So $21 for CF48D only supports LID 0x01, Consult 2 Control Unit ID. (And obviously LID 0x81) But what's actually interesting is that the ONLY code that does anything more than return a Control unit ID is used for LID 0x81. On top of this, it's referencing EEPROM parameters, DTC RAM Block, DTC Status Array, and many unknown RAM parameters. So it appears that a LOT can be done with $21 81.

On top of this, in my testing of RAM writing for the $AC Address storage, it actually hard reset the ECU a few times for whatever reason. So I feel like there's a lot left to discover with $21 81, past just normal datalogging.

Edit;
It also appears that communicating with multiple ECU's at once might be possible? This really would only be beneficial for datalogging, but it would definitely be quite interesting to see if we can make it work.

Pytrex · **Posted:** Thu Dec 23, 2021 9:32 pm

Figured VIN writing out lol $3B with 17 LIDs. For CF48D, LID 01 is Ignition Timing Adjustment, LID 02 is Idle RPM Adjustment, and LIDs 04->14 are the 17 VIN Writing Bytes. Pretty cool actually. What's not so cool is having to send all the freaking commands.

Code:

VIN Writing Example (Only 5 bytes)

$3B 04 12 00
$3B 04 12 FF
$3B 05 34 00
$3B 05 34 FF
$3B 06 56 00
$3B 06 56 FF
$3B 07 78 00
$3B 07 78 FF
$3B 08 9A 00
$3B 08 9A FF

While I haven't personally tested this, it should work like this. Because when you send the 00 ending, it's setting a bit that tells the ECU to write VIN Byte X. Then the FF ending allows you to go to the next byte. If you fail to send the FF byte, you'll just keep writing the same VIN byte. Hence why y'all shouldn't be sending SID commands on your own lol Leave it to a computer so that you don't have to worry about the little things

Obviously the VIN value is stored as ASCII text, so just convert your VIN to bytes online. If we implement this in an application, it could just convert it automatically.

RomRaider

Forum rules

Communication Protocol Analysis

Who is online