Nissan 370Z Custom PIDs

I picked up my 370Z CAN hacking project again after others expressed interest on a 370Z forum I frequent.  I ported my old VB6 project over to VB.NET and created a few more tools to help.  I’ve also added standard OBD PID polling to use that info to compare with Nissan’s custom CAN data.  I updated my CAN spreadsheet with new items and corrected a few others.  I always keep the latest copy with the latest CAN information I’ve decoded on my spreadsheet here.

Then I started looking into how to get to the undocumented Nissan PIDs.  Various websites give bits and pieces of information, but a lot of times they’re for different makes or models and nothing seemed to work with my car.  Then I came across Swedish Implementation Standard SSF-14230.  It relates to vehicle CAN systems and implements ISO-14230 that we use here in the US.  You can find free copies using Google.  It outlines several of the protocols and commands used to access various parts of the CAN network.  I was really interested in information on service 22, which is readDataByCommonIdentifier.  Others had used this service successfully on Ford and GM cars to access their custom undocumented information.

This service works similarly to service 01, which is used to access the standard PIDs.  However, this command takes 2 bytes for the address.  This means there are 65,536 possible pieces of data ready to be accessed.  The command structure is as follows:

7E0 03 22 XXXX

7E0 is the CAN address for the ECU, 03 is the number of bytes that follow, 22 is the readDataByCommonIdentifier command, and XXXX is the PID that you are requesting from the CAN node.  However, sending this message returns the following error message:

7E8 03 7F 22 80

7E8 is the standard reply address from the ECU (7E0 + 8), 03 is the number of bytes that follow, 7F signifies a negative response, 22 is the command I sent that failed, and 80 is the error code for “Service Not Supported In Active Diagnostic Session”.  This means that the ECU recognizes the command, but the ECU needs to be placed in a different mode in order to act on it.  I started researching diagnostic sessions and found there are 256 possible sessions.  So I wrote a routine that automatically tried to place the ECU in every single diagnostic session.  The command to place the ECU in a diagnostic session is as follows:

7E0 02 10 XX

10 is the startDiagnosticSession command and XX is the session you are requesting.  Only 6 diagnostic sessions succeeded: 81, 85, C0, DA, FA, & FB.

I put the ECU in each diagnostic session one by one and tried to send the readDataByCommonIdentifier command from before.  I received the same 80 error code for all sessions except for one: diagnostic session C0.  Unfortunately, that response gave me a 12 error code.  That means “Subfunction Not Supported or Invalid Format”.  Basically, it recognizes the command, but the parameters I sent with it (the 2-byte PID) are either unknown, not supported, or in an invalid format.  That is the most vague error I’ve ever seen!  It doesn’t give you any kind of hint on how to fix the problem.  I tried all sorts of different formats, added bytes, etc. but kept getting the same error.  So I decided it must be in the right format, but there’s just no information for that particular PID.  I wrote another routine to try every single PID to see what I got.

After letting it run for an hour or so I looked through the logs and found lots of responses.  I finally found Nissan’s custom PIDs!  224 of them to be exact.  I added the full list of supported PIDs to my spreadsheet and I will start trying to decipher them when I can.  Please let me know if you are interested in helping.  There’s a ton of information to go through.

One other hiccup I ran into is that the ECU will drop out of the special diagnostic session and revert to the default session if there is no activity for about 3 seconds.  The following command can be sent about every 2.5s to keep the current session active:

7E0 02 3E 01

Command 3E is the “Tester Present” command that lets the ECU know that a tester device is plugged into the OBD port and to keep the active diagnostic session going.  I added 01 to the message because it kept giving me a 12 error (just like I talked about above), which meant I needed some sort of parameter with it.  I tried 01 and it responded with a positive response, which is good enough for me.  The positive response looks like this:

7E8 01 7E

7E is the response to command 3E (3E + 40).