RomRaider

Has anyone expanded on or validated these PIDs?
I'm going to start a Logger definition and want to describe any known logging parameters and their SID/PID values and scalings.

Here's the supported SID/PIDs for the ECU I have:
2100 80000000
221100 E4419A41
221120 282C0901
221140 1F040080
221200 B5AF00F1
221220 E86013FF
221240 B3000000
221300 7FFC2000
221400 EEBBFFF8
221500 5B5B6000

Very exciting! I am willing to help fill in the blanks or with the defs themselves. Is the logger using the 10.4 kbit/s protocol?

CID/PID spreadsheet; https://docs.google.com/spreadsheets/d/ ... IipSvC7xhQ

Whoa, very nice progress @dschultz !

I like your spreadsheet a33b; have you thought of adding a column for "A2L name" and "scaling source" (to keep a trace of how the scaling was obtained, in case some conflicts ever arise between ROMs).

PS what happens in the spreadsheet with the CIDs > 1300 ? they're weirdly formatted, i.e. "13010" - or would that be CID 1301, bit 0 ?

Yes it's 10400 baud.
Can you include in the spreadsheet a column for ecu_init_byte, ecu_init_bit and datasize?
I know data size if fairly well grouped by SID/PID, but we'll still need it for the def file.
I'll provide the mapping for each SID/PID to ecu_init_byte, ecu_init_bit.

For any parameter of interest that is not directly obtained through SID/PID then we can read the direct RAM address.

I have ECU ID ZD89A, if you have a def for it let me know.

Thanks, but it's been much slower than I expected till now.

The question wasn't addressed to me, but what are ecu_init_byte and ecu_init_bit ?


Least I could do is take care of that. I'll have a basic one ready later today.

Internal to RR Logger it's a mapping of the supported SID/CID pulled from the ECU when RR Logger first connects. RR builds an internal mapping and then uses this info to filter out the logger def parameters that do not apply to the connected ECU. In this example they are: ecubyteindex & ecubit

If you string the ECU ID and all the possible SID/CIDs together you get a 200byte sequence.
Each bit in that sequence maps to a logger parameter and if set then the ECU will report a value for it.

For my ECU the sequence is:
I put the | into the sequence to separate the SID/CID groups. Basically from the top down:
ECU_ID |
SID 21 |
SID 2211 |
SID 2212 |
SID 2213 |
SID 2214 |
SID 2215

Ah, I see, thanks. But in


Isn't the information given by ecubyteindex and ecubit somewhat redundant with the 'address' field ? Granted, probably not a serious problem if that's in a logger def that isn't normally user-edited.

Just made a basic def for ZD89A with a few maps, just to have a starting point:
https://github.com/fenugrec/NissanDefs/ ... /ZD89A.xml

I probably can, but you're using different terms than I've become familiar with. ecu_init_byte and ecu_init_bit? Just saw you responded above this post...

This is a great option, I've had to hack the SIDs to attempt this (some of the junk notes in the spreadsheet I attached)

Good idea, I was mostly using this for RE purposes within the disassembly. Now that a logger is coming I agree that some more effort should be expended to verify as many as possible.
Correct

This is for the parameters of the Logger definition, it's only defined once and then you will forget all about it unless we discover new parameters in these SID/CID combos not currently defined.



BTW: The RR Logger for the Nissan protocol will only work with a J2534 cable on Windows.
I use the Tactrix Openport 2 & Drew Tech Mongoose ISO/CAN. I have a couple of others but have not tested them yet. I find the Tactrix OP2 has the best performance (although the new MongoosePro might close the gap, I have the original version).
It might work on Linux (not yet tested) but only with the OP2 cable and this driver.

Understandable, it's so much easier than manually managing K comms.
Did I dream or does the SSM code have pretty much all we would need for 10.4k comms over a simple serial-K adapter ? Of course I'd rather have everybody (including me) using J2534 hardware for everything, but it's still much more expensive, and nisprog only supports dumb cables.

SSM is simple. Set baud to 4800 8-n-1 and just start your queries. None of that silly KWP wakeup tomfoolery dancing mating ritual.

Ah my bad, I thought I had seen fastinit / wakeup code. I probably got that idea seeing how the packets are formatted mostly like iso14230.

So the next project (ha ha) is to have nisprog/libdiag expose a J2534 API with a dumb K cable backend ! Doable, but not worth my time.

So from this I gather that each bit returned is effectively a switch (on/off), correct?

If the reply to 1301 is a byte, is each bit supported or is it possible that say only 5 of 8 bits contain real values?

how would you interpret this?
Mode221305 Request = 052213050401
Mode221305 Response = 056213054844