RomRaider

Hey guys,

firstly nice job you lads have done here, quite a labor of love you have going.

I'm in a bit of a pickle and maybe someone can advise me what to try next (please, argh!!).

I have the above car, engine is out for a rebuild with some upgrades. This will require tuning, and its where I'm stuck. I would like to put uprev onto it, but want to confirm the ecu can take it, however I can't seem to get anything to talk to the ecu which is still in the harness but without the engine. I can't even pull the rom. This is what nisprog sees when I try to connect:

C:\nisprog>nisprog
diag_os_gethrt() resolution <= 0us, avg ~0us
diag_os_getms() resolution: ~16ms.
diag_os_chronoms() : resolution: ~15ms
Calibrating timing, this will take a few seconds...
diag_os_millisleep(50) off by +10% (+5094us); spread=23%
diag_os_millisleep(40) off by +15% (+6288us); spread=17%
diag_os_millisleep(30) off by +4% (+1255us); spread=5%
diag_os_millisleep(20) off by +46% (+9381us); spread=56%
diag_os_millisleep(18) off by +30% (+5569us); spread=64%
diag_os_millisleep(14) off by +13% (+1941us); spread=37%
diag_os_millisleep(12) off by +29% (+3566us); spread=30%
diag_os_millisleep(10) off by +57% (+5748us); spread=67%
Calibration done.
nisprog v1.02
nisprog: Interface set to default: DUMB
nisprog: Type HELP for a list of commands
nisprog: Type SCAN to start ODBII Scan
nisprog: Then use MONITOR to monitor real-time data
nisprog: **** IMPORTANT : this is beta software ! Use at your own risk.
nisprog: **** Remember, "debug all -1" displays all debugging info.
interface is now DUMB
Note concerning generic (dumb) interfaces : there are additional
options which can be set with "set dumbopts". By default
"K-line only" and "MAN_BREAK" are set.
port set to: \\.\COM4
dumbopts set to: 72
testerid: using 0xFC
destaddr: using 0x10
diag_l2_iso14230.c:736: Read/Write timeout.
diag_l2.c:438: Read/Write timeout.
L2 StartComms failed
now using 7055.
Must be connected normally (nc command) !
nisprog: Settings loaded from nisprog.ini

nisprog>


So as you can see it times out. Everything I've tried including:

other programs (which all time out like this)
3 different cables

I've used the programs provided in the tutorial thread (thanks - brilliant post). I've canbus rewired the thing as per uprev instructions, but no joy.

I'm 50% thinking I still have a dud cable, or there is a wiring issue to the ecu, maybe make a bench test for it? Dunno...

Anyway, thanks in advance if you see this and can help

Cheers

A read/write error, in my experience, has always been Nisprog specific. Are you using the latest version of Nisprog? found here -> viewtopic.php?f=65&t=13259

I had tons of read/write errors using an older version. But once I switched to the newer one, haven't had a single one since!

Bunch of these points to extremely unstable Windows OS timer which is quite important as nisprog handels all the timings on a SW level, saw this pretty much of the times on Win10.


In newer versions there is a workaround that forces it to "tick" quicker and provide better accuracy, so I would agree with reccomendation to upgrade the version.

Thanks for the tip, will report results.

Still no joy with timeouts trying to connect. Do you guys recommend any timing settings to try here? Ive had a play with them but maybe I'm missing something...

Its interesting win10 was mentioned as a possible culprit, Ive tried to connect using 3 systems, all win10. Does nisprog get past this as a problem in the newest version? Is the timing workaround baked into nisprog?

That's exactly what Shuher and Pytrex are saying. Use the latest nisprog otherwise you're wasting time.

Hi Fen,

just to confirm, my last messages were posted after trying the latest version - still got the timeout error

That's quite odd. When I was on the old version, my record for consecutive read/write errors before connecting was 52. Most of the time, it would take at least 5-15 retries before it would connect. But ever since I updated to the newer version, I've had 0 Can you confirm that you're on version 1.03?

Yes, 1.03b
When you retry are you just launching nisprog again? Or restarting the ecu too?
Does having the engine out make a difference? I can't see why it would... but it is out.
Makes me wonder if it is bricked, I can't seem to get aything to talk to it! However all the lights in the car and dash and everything else seem to work, and fuel pump will run so it must be doing something...

I just restart Nisprog. Hmm, I don't think it would matter for read/write errors. Read/write errors seem to occur before Nisprog even connects to the ECU in the first place. Make sure everything on your computer is updated and that you don't have many applications open at one time.

Wiring issue? Has anyone made a test harness for this before?

I've bit the bullet, and purchased another cable from a more reputable source... will update when i get it.

Sorry, I misunderstood.

If you're still getting high values of "spread=XX %" at startup, then you're still having timing issues. If so, run a media player in background.

Restarting nisprog shouldn't change anything. Just try 'nc' multiple times in a row.



Engine doesn't need to run, no. But to state the obvious... key has to be at the 'ON' position



if you suspect your cable, there's some tests you can run inside nisprog. Key OFF this time, but cable still plugged in so it gets battery power.

don't put these in your ini, just type them in

Thanks Fen, I'll give that a try and report back.

So so I did as per Fen's last post and none of the tests of the cable seem to indicate a fault, the only error message was the after the line saying to ignore the next error which looks like its as the program finishes running.

However nisprog (and for that matter anything I've ever tried) still can't talk to the ecu. Here is the console log of the present version trying to connect.



This really makes me wonder if it is a problem with the wiring because it seems like nisprog isn't getting any response at all. In fact if I run nisprog with the car off I get the exact same logging. Thoughts on that?

Possible... for my bench ECUs I had a short pigtail with just the proper connector for the ECU, and a bunch of signals (GND, +12 to a few wires including IGN). Hard to tell what's going on without being there. It's possible your combination of hardware an software isn't generating the proper wake-up pattern on the K line. Hard to say for sure without a scope or logic analyzer.

Can you borrow an OBD scanner for a quick test ? Should connect with a slightly different protocol (iso9141). You could also try iso9141 with nisprog; off the top o my head you'd have to change

l2protocol iso9141
initmode 5baud (or slow ?)
addrtype func
destaddr... 0x33 I think ?
testerid 0xf1 ?