RomRaider

When attempting to connect to the TCM or ABS module (NCS), they both throw errors and fail to connect. (Although, the ABS module seems to get close) Also, it would certainly make sense to have the logger only show the parameters for whatever module you're connected to. For example, only showing ECU parameters if you're connected to the ECU rather than showing ECU, TCM, and ABS parameters.

Following modules throw the following errors;
TCM:
- Response checksum match failure. Expected: 0A, Actual: 34
- Invalid response length

ABS Module:
- Invalid response length
- Invalid response code. Expected one of [5A, EC, 61, 62]. Actual: 7F.


Attached below are two trimmed error logs showcasing the errors shown when attempting to connect to both the ABS Module and the TCM.

The target attribute of the parameter element is used to select ECU or TCU or both. There's no value defined for other modules.
https://www.romraider.com/index.php/Rom ... renceGuide

It will be impossible to debug the comms without a device to test against. If the protocol timing is off, it will be hard to test any code changes.

How useful is this? Subaru users can log TCU, but I've only ever heard from a couple of them, and there are thousands of Subaru owners logging compared to, what, five or six Nissan users I see here
If useful I can look at getting a TCU to test against in my spare time.

Yeaaaa, it's probably safe to say you could count the active RR Logger Nissan users on one hand haha Hopefully the number will grow over time, though. But the ABS module is useless to datalog. It would really on "need" to be loggable just to say it is. But the TCM would be extremely beneficial to datalog. Not anytime soon, but eventually I'm going to get the TCM reflashing worked out. So being able to datalog specific RAM addresses to figure out TCM logic would be necessary. But you're talking about something being beneficial for ONE person only, as most automatic owners aren't tuning their ECU's, let alone having the knowledge on tuning a TCM lol

I will say though, Nissan Datascan 2 can datalog the TCM AND ABS CIDs through a VAG-COM cable. So I could sniff that TCM and ABS connection and see what's going on.

For sure some captures would be helpful.

Do you happen to know of any softwares that would be able to sniff the messages being sent through the VAG-COM cable? I have some old wireshark captures, but I'm not quite sure how to interpret the data. There's a good chance it's just gibberish and doesn't actually contain any of the proper K-line commands, but just thought I'd share so you could take a look.

I just use a Y-cable and another serial software like PuTTY to capture the data.
I'll have a look at the captures, are they taken at the USB interface of the VAG-COM with Wireshark?

EDIT: yes these captures are taken at the USB end of the cable.
This is the ECU connect data:

For real? That's awesome! Thanks for checking it out! It's already obvious just from the ECU connect code that NDS2 handles it much differently than what we do. I'm currently working on some notepad++ regex stuff to see just how neat I can make this look to help with analysis.

It would appear that timing parameters are identical between the ECU and TCM.





So the issue is that RR is splitting the TCM ID response into two separate responses. The normal response (as seen in the NDS2 log) is "07 5A 20 43 46 34 30 41 AF", but RR is splitting this response into two separate responses, causing it to throw checksum and response length errors. Also, it tries to re-establish comms during the split, but I'm not quite sure why?

RR is not splitting anything. That's what the J2534 cable provided. Split responses happens when the module doesn't reply with all the data in a timely fashion. Then the J2534 cable sends up to the application a partial packet, resulting in an error.
Maybe try different timing values, adjust it in NCS in the logger.xml.

Ahhhh, it's starting to make more sense now. I was confused as to why RR would ever split messages, so it's good to know that it's just needing a longer delay! I'll definitely have to experiment to see what values can help out!

TCM Problems:
Adjusting the p1_max volume seems to solve the response issues! Setting it to 5 (ms?) allows for the TCM to connect. While it DOES actually work for a few parameters, the "Next Gear Position" CID is throwing an error now. Is this caused by having an incorrectly defined byte size for a parameters? Because RR logger has no issues reading 8 of 8 bytes even with the TCM. And since it's actually reading the full messsage, but then saying "read 5 of 6 bytes", that means it's presumably choosing to do so.




ABS Problems:
The ABS error is just because CID 1500 isn't supported. So while ABS logging really isn't all that useful, technically it would be good if it could understand that a 7F response to a CID check marks the end of supported CIDs.

This is returning a word (16 bits) "00FF", not a byte (8 bits) of data.


7F is does not mean the end of CIDs, 7F means "negativeResponse Service Id" and 10 means generalReject. We would need to drop the query for 2215 from the init request to allow it to proceed. The init is currently setup to query 2211, 2212, 2213, and 2215. If 2215 will never be used we can drop it in the future.

So it is a definition error, how strange. Not sure why Nissan thought it was necessary to make a 1-5 gear position value a word value, but whatever lol


Is there a specific response that signifies the end of CIDs? I was just thinking that since it errored, it meant that it could be implied that the requested CIDs don't even exist for the ABS module.

As for 2215, it might be certain switches, but they're all completely undefined in the logger (even though there are quite a few that are enabled in the supmask for CF48D). Couldn't the logger be setup to just notice the error, but keep running as if it didn't happen? Since it's just a CID check, I'm sure there aren't many normal instances that it returns a 7F 22 10 error. Bu then again, it's my first time seeing a CID request throw an error lol

I'll definitely need to mess with RR logger's code sometime so that way I can be of more use with some of these more personal endeavors

Yes the end of CIDs has the last bit = 0.
Once you figure out some useful 2215 parameters they can be added to the Logger.xml anytime.
I'll have to look at how to handle the 7F response differently. The Logger is expecting some data and 7F returns the wrong amount of data so it is handled as a comms error right now.

Huh. I suppose I'll have to checkout the ABS logs and do some personal testing with Nisprog to see if I can figure anything out.


I'll definitely send you the updated def once I finish it up! It looks like 2215 is going to be emissions info, such as emissions readiness testing and such.