RomRaider

yes

The bits which are valid are defined in the CID 1300 table which is set up in u32 pairs. One value is the RAM address where the data is saved, and the other value is (usually) a ROM address which defines which bits are supported.

I'm 100% guessing, but assuming the last 4 digits are the actual response data, maybe two digits are the supported bits and the last 2 the data?

Hmm, that sounded strange but after looking at the disasm I mostly agree with your analysis.

I would differ on the format of the two data bytes: I think the first one is the flags (in this case 0x48), second one is support mask (0x44).

On ZD89A, if you try CID 1302, and it returns "13 02 xx 3F", then that would also tend to confirm this; 0x3F should be the support mask for CID 1302.

For ZD89A, the query followed by the response:
1300
13007FFC2000
1301
13010000
1302
1302003F
1303
13032020
1304
13048090
1305
13054844
1306
13060010
1307
13070442
1308
13080008
1309
13091002
130A
130A0010
130B
130B0002
130C
130C4065
130D
130D003F
130E
130E003F
130F
130F01FF
1310
13100003
1311
13110000
1312
no response
1313
13130007
1314
13140000
1315
no response

1300 says 1302 thru 130E and 1313 are valid CIDs

So for the example of 1302, we get back 003F. So no bits are set, but if they were only the bits that AND with the mask 3F are valid, correct?

What about the case of 1305, we get back 4844. If 44 is the mask then there is a bit set in 48 that is not valid (or undefined)?
48 = 01001000
44 = 01000100
& = 01000000

No response at all? Or a negresp 7F 12 or 7F 78 ? Really shouldn't be the latter, which means "wait for it" - that would make no sense for reading a RAM loc.


That is indeed how I interpret it. As for the case of 1305, the "stray" set bit in 0x48 could just be an internal flag not officially mapped to a CID param.

yup

Yeah, bits 0 thru 6 are supported, but none of them are set (0=off,1=on for these CIDs).

I don't think the result can be AND'd right away. The mask should be used separately so only valid parameters are displayed in the logger. In this case the bit that is set but not supported is "Rev unit D" and I have no idea what that might be.

I'm away from my computer, but some of the non supported CIDs can be FFFFFFFF, FFFFFFFF in the table. Might explain it?

Yes it replies with 7F2212, I simplified the response.

I would eventually interpret this as bit 6 = 1 and bit 2 = 0.

I suspect there's a timer in the ECU that limits the response to the 2181 command to once every 0.1 secs.
We'll need to work on the parameter conversions...

Awesome work !!
I hope you're not re-sending the SID AC request every time ?
Also, have you tried experimented with the TXMode and NResp fields of the 2181 request ?

No, sending 21810401 1msec after received last response. It takes 0.1sec before seeing data from the ECU.

If I send 21810402, I do get two messages back. I'll have to think about how to handle that.
RR Logger does have a mode where it will just listen for data from the ECU once the ECU is commanded to send based on set addresses. It would be easier to work with that if the Nissan ECU would do the same, send data till stopped. It seems 21810400 does the same as 21810401.

Silly question, but are you sure the 100ms delay is not between the function call and the actual data on the bus ? Then again, I haven't taken a logic analyzer to the K bus in a long time, I don't know if that delay is usual. IIRC when dumping ROMs with SID AC, I can practically saturate the 10400 link speed, i.e. near 1ms per byte.



I think TXmode=6 does that (i.e. 21 81 06 01) but I don't know how to stop the stream. I didn't investigate a lot, I remember trying briefly and drowning in a flood of responses.

That timing is up to the J2534 cable.
Here is the J2534 write msg followed by the Start of Msg indication. The time, the first value in msecs shows ~0.1 between the msg write and the J2534 cable indicating data is coming. The data is read 2msec later.
RR Logger can send requests and process responses in under 1msec if the ECU can keep up and the line is fast enough. i.e.: on CAN we can process upwards of 80queries/sec.


I'll have a look at this.

True, unless somehow the USB request was buffered / delayed in queue, but your log confirms it's not the case.
Then maybe it's rather a combination of parameters, have you modified those ? I would recommend setting P4_MIN=0, and mayber shortening P3_MIN a bit ; the defaults are 5ms and 50ms respectively. That could help with some of the delay.

I hadn't changed the defaults for initial testing.
Setting P4_MIN to 0 bumped the query rate up with about 0.07 secs between responses.
Settings P3_MIN has the greatest affect. At setting of 10 gives about 30 queries/sec for a small packet of only four parameters.