HR nisprog connection issue

HOODEY · **Joined:** Sun May 09, 2021 12:41 am **Posts:** 28

Found it did some searching all over the place. Now having a ton of issues with the VAG KKK Chinese cable.

I am getting L2 start Comms failed.

I also have the same unanswered question as ALIF. There is brilliance in creating the technical things but
documentation is challenging for some one trying to follow along.

E.g L2 StartComms failed is not a helpful error handling message. The error should give insight into the underlying issue and suggest actions for the user to resolve.

Pytrex · **Posted:** Sat Jun 26, 2021 6:08 pm

AxelF wrote:

1. In the tutorial it is mentioned, that you know that runkernel runs, when car fans start (with ignition on). This is never the case with the car here??????? But i can connect and finds CF44A as ECUID also through nisprog.

You can connect to the ECU with Nisprog just fine. The kernel makes the ECU start running from RAM, bypassing normal functionality. So if the fans don't kick on, that means you're just connected to the ECU normally. Think of it like using an OBD2 reader at that point.

Quote:

2. Also the nissandefs.xml seems to be nowhere in the zip-file.

Those can be found at my repo -> https://github.com/Pytrex/NissanDefinitions (Z/G Specific)

Quote:

3. I am not sure, if my programmer already did checksums, does nisprog change them itself, when starting to write? Do i need to check before with Romraider? Can't load the file into Romraider, as i have no definitionsfile...

Checksums are handled by RomRaider. So make sure whenever you make changes to your ROM, it's done through RomRaider.

Pytrex · **Posted:** Sat Jun 26, 2021 6:16 pm

HOODEY wrote:

E.g L2 StartComms failed is not a helpful error handling message. The error should give insight into the underlying issue and suggest actions for the user to resolve.

Read/write errors are typically caused by OS timer issues. Make sure that your VAG-COM cable is appearing in your device list as well. Possible that you don't have the proper drivers for it. If you have Nissan Datascan 2, verify if you can connect with that. If so, then we can at least narrow it down to being Nisprog specific.

HOODEY · **Joined:** Sun May 09, 2021 12:41 am **Posts:** 28

Love how you translate the highly technical stuff into a more palatable serving.

I cannot connect using Nisdata scan 2. I am trying to read the HR Rom.
I opened the cable and saw a comparator and a CH40?

In the device manager I see the cable on COM4 and the status says working correctly.

I notice on the bench I need the K line to connect to the unit using Generic OBD2.

What is really the difference between using Generic and clicking on the vehicle Icon?
With the K line disconnected I can look at live parameters using CANL and CANH.

Code:

Calibrating timing, this will take a few seconds...
Calibration done.

**************** nisprog v1.04-8e3390d+ ****************
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.
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.
running commands from file nisprog.ini...
port set to: \\.\COM4
dumbopts set to:      72
No such item !
testerid: using 0xFC
destaddr: using 0x10
        p3 set to 0 (0x0).
        rxe set to 200 (0xC8).
diag_l2_iso14230.c:766: Read/Write timeout.
diag_l2.c:435: Read/Write timeout.
L2 StartComms failed
now using 7058.
Must be connected normally (nc command) !
Not connected !
nisprog: Settings loaded from nisprog.ini

nisprog>

Pytrex · **Posted:** Sun Jun 27, 2021 3:09 pm

Oooh that’s the problem. HR ECU’s are CAN-based. This isn’t supported by Nisprog or NDS2. While the only other tuning option is UpRev or EcuTek, NDS3 can connect to your ECU for consult functionality at least. But you’ll unfortunately have to dish out the money for one of the professional tuning softwares in order to tune your Z. Maybe one day Nisprog can be CAN-compatible! But it’ll take quite some time and effort.

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 652

HOODEY wrote:

E.g L2 StartComms failed is not a helpful error handling message. The error should give insight into the underlying issue and suggest actions for the user to resolve.

It is not a helpful error message perhaps, but the line above says "read/write timeout" which is the helpful information. I am certain this type of issue has been discussed in many, many threads here already. Perhaps not easy to search / find, but it comes up regularly.

Quote:

"give insight into the underlying issue and suggest actions"

Easier said than done. I choose not to print 150 lines of advice every time an error occurs, because
A) nobody will read it , judging by how few people read even just the included docs;
B) (especially) in the case of timeouts, there can be a ton of causes. Here's a list off the top of my head :

- K line not connected
- ECU not powered
- IGN off
- bad cable
- bad options in nisprog
- OS configuration issue
- OS power saving / performance timers issue
- driver config issue (is it an FTDI ? these have special config options. A cheap ch340 ? sometimes these just don't work)
- ECU doesn't support K line at all (thanks Pytrex, I think you have it)
- random occurence. Sometimes trying to connect twice in a row will work. Timing is critical, and nisprog tries to control it more precisely than what a typical OS guarantees or recommends. Like 10x more accurate.

etc.

Not saying things can't be improved, I'm very much aware it's not a user-friendly program. But this s*** is complicated and I can only spend so many (unpaid) hours on this software.

HOODEY · **Joined:** Sun May 09, 2021 12:41 am **Posts:** 28

Pytrex this is one weird ECU. I swore I saw TOMC was successful connecting to the HR ECU but killed the session
and was not able regain connection.

If this ECU is CAN only when I remove the CAN Connection I can connect to the ECU using Generic OBD2 via the K line using a Autel Scan Tool?

When I click on the NISSAN ICON with the Kline disconnected (Can Connected) I am able to view live data.
Does the ICON represent Nissan Consult functions and not OBD2 over CAN?

If the Kline is connected and the CAN Line disconnected when I click on the Nissan ICON I get a communication error.

Logic is telling me both Interfaces are being used. Therefore the logical question to ask is NISPROG using generic OBD2 on the Kline?

The cable is using the CH340 chipset. I am going to put a scope on the K line.

NDS111 is saying can filter fail. NDS11 cannot connect.

bradsm87 · **Joined:** Thu Apr 14, 2011 8:16 am **Posts:** 425

BitBox just released a Nissan CAN 7055/7058 flash module. They have very good pricing. Their wording of "Nissan Gen 1 SH7055/7058 CAN" made it sound like they have a kernel for CAN flashing of K-Line ECUs that also have CAN communication. I put my hand up to test it. Of course it didn't work. They later clarified that this is for the later CAN ECUs.

Pytrex · **Posted:** Sun Jun 27, 2021 10:15 pm

HOODEY wrote:

If this ECU is CAN only when I remove the CAN Connection I can connect to the ECU using Generic OBD2 via the K line using a Autel Scan Tool?

So here's the thing. 03-06 Z ECU's use K-line to dump and flash the ECU. Could this be done with CAN? Maybe??? But 07-08 Z ECU's utilize CAN exclusively for this. So there's no way to access dumping or flashing the ROM without it being done through CAN. This isn't to say that K-line goes completely unused! But it does mean that you won't ever be able to dump or flash the ROM through K-line. So OBD2 and such might still be K-line compatible for diagnostics at least.

Quote:

NDS111 is saying can filter fail.

Go to communications and do their search for ECU's thing. See if it can find your ECU

NDS3 can connect to my 06 Z's BCM and IPDM, but not ECU either. But it tells you what ECU's it finds and whether they're NDS2 or NDS3 compatible. So my ECU shows up as being NDS2 compatible only.

bradsm87 · **Joined:** Thu Apr 14, 2011 8:16 am **Posts:** 425

I’m guessing the least amount of work to develop something to flash a later ECU would be something to upload and initiate npkern via CAN then just use npkern as normal over K-Line?

HOODEY · **Joined:** Sun May 09, 2021 12:41 am **Posts:** 28

Pytrex I understand regarding the point of only being able to flash via can.
The question then remains as to why the scan tool can connect to the ECU via K line and
NISPROG cannot.

I am seeing nice clean signals on the Kline.

The scope is now reduced to connecting.

Is connecting not a simple issue of sending a sequence of bytes at a baud rate of 5
and then waiting for a response?

Both ISO's 9141 and 14230 knows a 5 baud initialization sequence. The microcontroller must start this init by transmitting byte 0x33 to the verhicle at 5 bits per second. The total transmit time for transmitting byte 0x33 takes about 2 seconds. After this initialization it is expected to continue communicating at 10k4 baud.

For ISO 9141-2 the verhicle ECU will respond with synchronization byte 0x55. After this, the verhicle will respond with key bytes 0x08 and 0x08 or 0x96 and 0x96. The sync byte with key bytes of the verhicle must be acknowledged by the microcontroller by inverting the second key byte. This will end the initialization part of ISO 9141-2.

The 5 baud init is also called "slow init". There is also a "fast init". The fast init does not use the 5 baud init as descibed above but starts directly at 10.4 kbps. A StartCommunication request 0xc1, 0x33, 0xf1, 0x81, 0x66 must be submitted prior submitting requests.

Based on the log the protocol being used is 14230

Quote:

diag_l2_iso14230.c:766: Read/Write timeout.

ISO 14230 initialization response:

The response of ISO 14230 is slightly different. The verhicle ECU will also respond with synchronization byte 0x55. Only the key bytes are different. In case of a VW Touran of 2003 the key bytes are 0xef and 0x8f. Also here the second key byte must be acknowledged by the microcontroller by inverting it.

It seems to me therefore that the code could confirm whether a 55 response was received.
It could also display the key bytes.

If the controller (NISPROG) responds as per specification and nothing is returned you can 100% conclude the ECU
is not program to respond. If the can tool can get a response why can't NISPROG get a response?

Where can I find this routine?

Code:

diag_l2_iso14230.c:766: Read/Write timeout

Something is not making sense.

Pytrex · **Posted:** Mon Jun 28, 2021 1:46 am

@HOODEY, unfortunately, that’s more of Fenugrec’s area of expertise rather than mine haha But I do know that there are TONS of variables in play. Imo, it’s irrelevant due to the fact that Nisprog isn’t designed for anything other than K-line based ECU’s.

But I will say that it’s definitely something to keep in mind.

@bradsm87, I don’t think it would work like that. Tbh, I have no idea what the kernel is physically doing, but I don’t think you could just copy the kernel over? The reason being that SH7055 and SH7058 both have different kernels, even though both are reasonably similar. So given the fact that the CAN-ECU’s probabblyyy use a different version of SH7058 (think SH7055_18 and SH7055_35), they’ll probably need a brand new kernel. Depending on what the kernel is actually doing, the hard part might just be connecting to the ECU and tweaking a few lines of the SH7058 kernel. But who knows. Probably better to focus on establishing a connection before focusing on the reflash kernel haha

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 652

HOODEY wrote:

Is connecting not a simple issue of sending a sequence of bytes at a baud rate of 5
and then waiting for a response?

You're on the right track with iso9141 vs 14230.

To reflash & do the interesting stuff, we need to connect via iso14230 with fast init, with testerid 0xf1 and ECU address 0x10. "set show" in nisprog will show those options.
When connecting to an ECU via iso9141 with slowinit, the addresses and address mode are different. This is what a generic OBD2 scantool would try; and when connected over a iso9141 link, Nissan ECUs support only OBD2 requests (i.e. SIDs 1 through 9 or so).

It's possible some ECUs work via CAN for most stuff, including for reflashing, but they still provide a K line with OBD2 services over a 9141 link.

@bradsm87, it's my understanding that "CAN-only" ECUs do not need, and possibly cannot use at all, a RAM kernel like we have for K-line ECUs. Reflashing CAN ECUs is thus much much simpler since they contain a kernel already (which they internally take care of copying + executing from RAM), it's a simple matter of sending the correct commands. I believe some CAN reflash logs were even posted somewhere in these threads, I know I've seen some.

HOODEY · **Joined:** Sun May 09, 2021 12:41 am **Posts:** 28

Must be failing some where in here. Always found C to be challenging to read.
How do you compile and create an executable for all this so you can run in debug mode.

Code:

   case DIAG_L2_TYPE_FASTINIT:

      /* Build an ISO14230 StartComms message */
      if (flags & DIAG_L2_TYPE_FUNCADDR) {
         msg.fmt = DIAG_FMT_ISO_FUNCADDR;
         d_l2_conn->diag_l2_physaddr = 0; /* Don't know it yet */
         in.physaddr = 0;
      } else {
         msg.fmt = 0;
         d_l2_conn->diag_l2_physaddr = target;
         in.physaddr = 1;
      }
      msg.src = source;
      msg.dest = target;
      msg.len = 1 ;
      data[0]= DIAG_KW2K_SI_SCR ;   /* startCommunication rqst*/
      msg.data = data;

      /* Do fast init stuff */
      in.type = DIAG_L1_INITBUS_FAST;
      in.addr = target;
      in.testerid = source;

      rv = diag_l2_ioctl(d_l2_conn, DIAG_IOCTL_INITBUS, &in);
      if (rv < 0) {
         break;
      }

      // some L0 devices already do the full startcomm transaction:
      if (d_l2_conn->diag_link->l1flags & DIAG_L1_DOESFULLINIT) {
         //TODO : somehow extract keybyte data for those cases...
         //original elm327s have the "atkw" command to get the keybytes, but clones suck.
         dp->state = STATE_ESTABLISHED;
         break;
      }

      /* Send the prepared message */
      if (dl2p_14230_send(d_l2_conn, &msg)) {
         rv=DIAG_ERR_GENERAL;
         break;
      }

      if (d_l2_conn->diag_link->l1flags & DIAG_L1_DOESL2FRAME) {
         timeout = 200;
      } else {
         timeout = d_l2_conn->diag_l2_p2max + RXTOFFSET;
      }

      /* And wait for a response, ISO14230 says will arrive in P2 */
      rv = dl2p_14230_int_recv(d_l2_conn, timeout);
      if (rv < 0) {
         break;
      }

      // _int_recv() should have filled  d_l2_conn->diag_msg properly.
      // check if message is OK :
      if (d_l2_conn->diag_msg->fmt & DIAG_FMT_BADCS) {
         rv=DIAG_ERR_BADCSUM;
         break;
      }

      switch (d_l2_conn->diag_msg->data[0]) {
      case DIAG_KW2K_RC_SCRPR:   /* StartComms positive response */

         d_l2_conn->diag_l2_kb1 = d_l2_conn->diag_msg->data[1];
         d_l2_conn->diag_l2_kb2 = d_l2_conn->diag_msg->data[2];
         d_l2_conn->diag_l2_physaddr = d_l2_conn->diag_msg->src;

         if (d_l2_conn->diag_l2_kb1 != 0x8f) {
            DIAG_DBGM(diag_l2_debug, DIAG_DEBUG_INIT, DIAG_DBGLEVEL_V,
               "Warning : non-standard KB1 received (0x%02X) !\n", d_l2_conn->diag_l2_kb1);
         }

         DIAG_DBGM(diag_l2_debug, DIAG_DEBUG_PROTO, DIAG_DBGLEVEL_V,
            FLFMT "_StartComms Physaddr=0x%X KB1=%02X, KB2=%02X\n",
            FL, d_l2_conn->diag_l2_physaddr, d_l2_conn->diag_l2_kb1, d_l2_conn->diag_l2_kb2);
         rv=0;
         dp->state = STATE_ESTABLISHED ;
         break;

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 652

HOODEY wrote:

Must be failing some where in here. Always found C to be challenging to read

Whoa whoa whoa, you're in way too deep there... shouldn't need to recompile at all

Code:

set
show
l2protocol iso9141
testerid 0xf1
initmode ?

(actually, I think this last syntax with the '?' may be broken, it doesn't show the available choices anymore. Il'l have to check on this later

RomRaider

Forum rules

HR nisprog connection issue

Who is online