Connection Issues: SRS and TCM

[Pytrex]

Here's what Nisprog throws when attempting to connect to the SRS system. Even though sending "nc" returns "already connected to ECU", it sure doesn't act like it is haha

Connected to ECU !
diag_l2.c:542: Read/Write timeout.
Couldn't get ECUID ? Verify settings, connection mode etc.

A point of interest, the SRS keybytes state that it only runs on default timing parameters, rather than extended timing like the other parameters. Maybe Nisprog is getting mad about that? Because it should be able to return an ECU ID via $1A 80 and $1A 81. Also, the SRS light flashes when "connected", even though any attempts to send commands result in no response (since Nisprog probably doesn't even know it's somewhat connected or something?)

Diag connect, on the other hand, might be able to connect just fine? It still wouldn't return any responses, but it did throw an error when plugging in a $81 request.

nisprog> diag connect 
Connection to ECU established! 
nisprog> diag sr 0x81 0x58 0xFC 0x81 0x56 // Accidentally left the checksum value in the command lol But maybe this will be helpful still? 
Bus Error: got 0x3 expected 0xFC
diag_l1.c:233: We detected write error on diag bus.
diag_l2_iso14230.c:977: We detected write error on diag bus.
diag_l2.c:518: We detected write error on diag bus.
diag_l2_iso14230.c:145: Cant decode msg (ever).
diag_l2_iso14230.c:401: Cant decode msg (ever).
sendreq: failed error -18

And just for some good info:

NDS2 Full SRS Connect Log:
$81 58 FC 81 56	
83 FC 58 C1 6D 8F 94	

05 $22 12 01 04 01 3F 
05 62 12 01 FA 51 C5	

02 $1A 80 9C 
03 5A 30 00 8D	

[fenugrec]

Forget about "nc" until you get diag connect working.

nisprog> diag sr 0x81 0x58 0xFC 0x81 0x56 // Accidentally left the checksum value in the command

You need to stop adding header bytes with "diag sr" The whole point of nisprog is to NOT have to do that.
Also, why are you sending another StartComms request after "diag connect" seems to have worked ?

If you set the protocol addressing and stuff correctly, it should send exactly the requests you want. So physical addressing, destaddr 0x58, testerid 0xfc.

Bus Error: got 0x3 expected 0xFC

Usually happens when the ECU gets confused and talks "over" a request that nisprog is still sending out. When that happens, there's no point in continuing. Try disconnect, wait a few seconds for the comms to timeout on the ECU side, then connect again.

[Pytrex]

You need to stop adding header bytes with "diag sr" The whole point of nisprog is to NOT have to do that. Also, why are you sending another StartComms request after "diag connect" seems to have worked ?

So when using "diag connect", it'll still autogenerate the header bytes? But the startcomms request was just to see if maybe I could manually get it to connect, as neither "nc" or "diag connect" were getting any data for manually requesting the ECU ID. But I guess it's a good time to ask, what exactly is "Diag connect" doing differently?

Usually happens when the ECU gets confused and talks "over" a request that nisprog is still sending out. When that happens, there's no point in continuing. Try disconnect, wait a few seconds for the comms to timeout on the ECU side, then connect again.

Gotcha! And by the way, Nisprog would default to standard timing if you didn't specify any timing adjustments, right? It's just confusing why NDS2 connects just fine but Nisprog doesn't, when Nisprog would be sending the same start comms request and have no issues pulling the ECU ID as a result.

[fenugrec]

So when using "diag connect", it'll still autogenerate the header bytes?

Of course. "debug l1 0x8c" to see exactly what it sends down the wire. It's noisy but you just need to "debug l1 0" to quiet it again.

what exactly is "Diag connect" doing differently?

diag connect is very basic, just tries to start an L2 connection . That means StartComms, get the keybytes, start the keepalive timer, and not much else. It's implemented in the freediag side : https://github.com/fenugrec/freediag/blob/1c646c286c60cfad0b5f849db2eb319d78091e93/scantool/scantool_diag.c#L380

nc also does a StartComms, but tweaks 14230 settings, then tries to get the ECUID:
https://github.com/fenugrec/nisprog/blob/master/np_cli.c#L401

Nisprog would default to standard timing if you didn't specify any timing adjustments, right?

mostly ... StartComms throws in the default values here, https://github.com/fenugrec/freediag/blob/1c646c286c60cfad0b5f849db2eb319d78091e93/scantool/diag_l2.c#L408

but a quick search in nisprog's codebase returns a few results:

np_backend.c:795:       uint16_t old_p2max = global_l2_conn->diag_l2_p2max;
np_backend.c:796:       global_l2_conn->diag_l2_p2max = 1800;
np_backend.c:798:       global_l2_conn->diag_l2_p2max = old_p2max;      //restore p2max; the rest should be OK
np_cli.c:89:            global_l2_conn->diag_l2_p3min = (u16) nparam_p3.val;
np_cli.c:90:            global_l2_conn->diag_l2_p4min=0;

p3 and p4 are the most important for dumping fast; not sure why I was changing p2 there.

[Pytrex]

Of course. "debug l1 0x8c" to see exactly what it sends down the wire. It's noisy but you just need to "debug l1 0" to quiet it again.

Ahhh, gotcha! I'll have to remember that for next time haha

nc also does a StartComms, but tweaks 14230 settings, then tries to get the ECUID:

Hmmm, so if I'm understanding this correctly, we want "diag connect" working first since it relies on the defaults exclusively, while "nc" is altering "14230 settings" which probably means timing parameters? Or at least, the focus is on "diag connect" since it's the simplest of the two to work with for this initial testing. I appreciate all the references! It definitely helps point me in the right direction.

I think I'll try messing with "diag connect" more and utilize the debug options to see if anything cool goes through. Because since diag connect should line up in terms of timing parameters, there shouldn't be anything stopping me from grabbing this ECU ID. So we'll just have to see what's going on with the bus and go from there.