Open Pytrex opened 2 years ago
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.
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.
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.
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.
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
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.
And just for some good info: