Missing DLL for ndOpenDiagnostic().

[Dennisatwork]

Additional info:

I am getting -1074384765 when I replace the "" with "34" and "98".

status = ndOpenDiagnosticOnLIN (Interface, 10417, 98, "" , "" , &DiagStruct); 

[JefeL]

The error -8260 is a general timeout error when a command from the master did not receive a response from the slave before the specified timeout elapsed. This can be caused by any number of things such as incorrect baud rates, incorrect NAD, or timeout values that are to short. 

I'm not sure what the -107 error is as it comes up undefined. Make sure that it isn't a typo or a user error. On LIN, diagnostics will have to be performed with a master request and slave response ID. The LIN specification limits these IDs to ID 0d60 and 0d61.

ndOpenDiagnosticOnLIN takes two character arrays as inputs for the name of MasterReqFrame and SlaveRespFrame. If you are using the example database, the master request and slave response already use these names so the default empty string should work. Providing an integer as an input probably casts the integer to a string and no frames named 34 or 98 exists in the database which results in -1074384765.

[Dennisatwork]

Whenever I add either

status = ndGetProperty (0); or status = ndSetProperty (0,3);

the second time running thru I get a general protection fault:

FATAL RUN-TIME ERROR: "c:\...\cvi_code\official_LIN.c", line 192, col 11, thread id 0x0000126C: The program has caused a 'General Protection' fault at 0x77DA22E2.

[JefeL]

What changes between the first execution and the second execution when the error occurs? Do you close the diagnostic session and fail to open a new one prior to calling ndGetProperty?

[Dennisatwork]

When I perform : ndSetProperty (15, 0); before the "ndOpenDiagnosticOnLIN" on the second try I get the General Protection fault but if I do it after the "ndOpenDiagnosticOnLIN" command the GPF does not happen.

status = ndOpenDiagnosticOnLIN (Interface, 10417, 98, "" , "" , &DiagStruct);

Delay(2);

ndSetProperty (15, 0); 
status2 = ndDiagnosticService (&DiagStruct, &resp, &dataIn, word_size, &dataOut, size_word);

ndCloseDiagnostic (&DiagStruct);

But I am still getting -8260 from the ndDiagnosticService command.

[JefeL]

ndSetProperty and ndGetProperty both require a valid diagnostic session to operate properly. They must be called in-between the ndOpenDiagnosticOnLIN() and ndCloseDiagnostic() calls. If they are called before the diagnostic is opened or after the diagnostic session is closed, a general protection fault is expected. 

You can try to use the XNET bus monitor to view the traffic on the LIN bus to get a better understanding of what might be causing the -8260 timeout waiting for a response. The bus monitor will allow you to see if the diagnostic message was transmitted and if a response was sent by the ECU. Knowing whether or not the ECU sends a response will confirm if the error condition is true.

If the ECU isn't sending a response, we can look into the diagnostic command sent to the ECU to ensure it is valid.

If the ECU is sending a response and ADCS isn't receiving it or rejecting it, we can verify that the timeout is not elapsing and take a closer look at the value returned by the ECU to ensure it is the expected response.

[Dennisatwork]

I have modified the "ADCS_LIN_database.ldf" file (for timing) and added "ndStartDiagnosticSession" function to wake up the UUT. 

 status2  = 0 , meaning it succeed .

I placed a scope on the LIN signal and see communication but dataOut is still zero.

int word_size = 1;

int size_word = 1;

unsigned char dataIn[8] = {98,3,34, 1,0,255, 255, 255 } ;

unsigned char dataOut[8] = {0,0,0, 0,0,0, 0, 0 } ;

resp = 1;

status = ndOpenDiagnosticOnLIN (Interface, 10417, 98, "" , "" , &DiagStruct);

ndSetProperty (0, 2000); // timeout 
ndSetProperty (15, 1);    // term

status5 = ndStartDiagnosticSession(&DiagStruct,"",0);      // wakes up UUT
status2 = ndDiagnosticService (&DiagStruct, &resp, &dataIn, word_size, &dataOut, &size_word);

[Dennisatwork · Accepted solution]

The "ndDiagnosticService()" function places the first two bytes into the command my program sends to the UUT.

So, instead of sending  - 0x62 0x03 0x22 0x01 0x00 0xFF 0xFF 0xFF and specifying 8 bytes

 I have to send -  0x22 0x01 0x00  and specifying 3 bytes is being sent.