RomRaider

Version 1.03b

Unlikely.

In sigrok try to decode the request bytes as uart , 10400bps, and make sure they match. They should.

Then, measure the wakeup pattern before the request (25ms low, 25ms high, then first byte).

I don't need to decode this. I compared the request from the scanner and with NISPROG, they are the same. The scanner is connected to the TCM, I work with this scanner. The problem is different. I have two options why there is no answer after a NISPROG request.
1. The timings between the request bytes are different (7ms and 9ms)
2. The scanner makes two requests and only then receives a response.

NISPROG may not work, but TCM must respond to the request. Right?

If you don't even want to verify those two simple things then at least upload the .sr files. Otherwise I won't help you.

Ok, I'll try to do this.

But I do not understand the meaning of these actions. On the scanner, I saw requests that match the requests from NISPROG. But there are two differences. These are two requests before receiving a response from the scanner and the time between bytes for the scanner is 9ms, and for NISPROG it is 7ms.

Sorry to repeat myself.

One protocol responded positively.

I apologize for the amateurish suggestions. I figured it was enough to make the time between bytes 9ms instead of 7ms and / or make two requests instead of one (as in a scanner).
I am not a programmer and will not be able to make these fixes.

Post your sigrok capture files (zipped).


the decoder should be UART with 10400 bps like I said, not "Parallel".

200 kHz
1 channel

Have you tried sending the "nc" command twice to duplicate this ?

I have looked at your capture and confirmed your tool is sending the same init request (81 18 FC 81) as nisprog. The wakeup pattern (25 / 50 ms) from nisprog is not perfect at 26ms and 52ms but that is extremely, ridiculously difficult to generate accurately with cheap USB adapters and common OS's like windows / linux.

The 7 vs 9 ms interbyte spacing can only be changed by recompiling nisprog (see the "P4" parameter in diag_l1_send; iso14230 only specifies P4 should be between 5 and 20ms for initial connection). I'm still fairly certain this is not the main problem.

Maybe the TCM is very, very picky about the wakeup pattern (ECUs usually tolerate a few ms inaccuracy). Or it really does need two connection attempts. As I suggest, you can more or less emulate this by running 'nc' twice. If the two requests need to happen closer together then it will require some code modifications in nisprog.

I didn't think to send "nc" twice, I'll try)).
As for the timings, I assumed that NISPROG itself does this. There is a dependence on the adapter and on the operating system ..

It is possible to put delay (300) between the "nc" commands in the ini file, for example? Will it pause between requests?

Delivered two nc, the time between the last byte and the next request in Nisprog is 479ms. The scanner has 331ms. No response from ecu.
If not very difficult, please correct the timings in Nisprog.