0

I am writing a CAPL script to automate testing for service testerPresent and need to send requests with suppressPosRspMsgIndicationBit" ("suppress positive response message indication bit"). This can be done easily by using diagSetParameter(Req_0x3E,"zeroSubFunction",0x80).

However, this is where my problem begin. I have a series of automated testcase which run sequentially. So when I request testerPresent with suppressPos bit set, the testing ECU will not respond (which is correct), but CANoe keep waiting for the P2 client timer in (ISO TP configuration->Diagnostic layer). During this interval, CANoe will not allow any UDS request (even the manual request on diag console), testWaitForDiagRequestSent will return error code. This mean the subsequent testcase can not send UDS request. However, I dont want to adjust this P2 client timer.

I have found that a function diagSetSuppressResp is used to deal with requests with suppressPos on. However, I have failed to find a way to use this function. CANoe keep waiting for the P2 client timer and block UDS request.

If anyone have use this function or have met some similar problem please help me.

My code:P2 timer in CANoe

includes
{
}
variables
{
  //zeroSubFunction
  const byte zeroSubFunction_False = 0x00;
  const byte zeroSubFunction_True = 0x80;
  const byte ISOSAEReserved_0x3E = 0x01;
  
  //Diagnostic objects
  diagRequest BasicDiagnosticsEcu.UDS_Diagnostic_Services_Generic.TesterPresent_Process Req_0x3E;
  diagResponse BasicDiagnosticsEcu.UDS_Diagnostic_Services_Generic.TesterPresent_Process Resp_0x3E;
}
void service0x3E_req(byte expected_NRC,byte session_req)
{
  long ret;
  long ret1;
  diagInitialize(Req_0x3E);
  //diagSetParameter(Req_0x3E,"zeroSubFunction",session_req);
  if(session_req == zeroSubFunction_True)
  {
    diagSetTarget("BasicDiagnosticsEcu");
    ret1 = diagsetSuppressResp(Req_0x3E,1);
    testStep("","Debug ret = %d",ret1);
  }
  else if(session_req == zeroSubFunction_False)
  {
    diagSetTarget("BasicDiagnosticsEcu");
    ret1 = diagsetSuppressResp(Req_0x3E,0);
    testStep("","Debug ret = %d",ret1);
  }
  else diagSetParameter(Req_0x3E,"zeroSubFunction",session_req);
  
  ret = sendDiagObject(Req_0x3E);
  
  
  if(ret == 0)
  {
    if(session_req == zeroSubFunction_True)
    {
      testStepPass("","No response received when request for zeroSubFunction: 0x%02X",session_req);
      //testWaitForTimeout(10000);
      return;
    }
    else testStepFail("","No response received!");
  }

Simplified code:

testcase tc()
{
  long ret;
  diagInitialize(Req_0x3E);
  diagsetSuppressResp(Req_0x3E,1);
  diagSendRequest(Req_0x3E);
  ret = testWaitForDiagRequestSent(Req_0x3E,2000);
    if (ret == 1) 
    {
      testStepPass("Tx","-\tSuccessfully send Diagnostic request message.");
    }
    else
    {
      TestStepFail("Tx","-\tDiagnostic request timeout error! Error code: %ld",ret);
    }
  diagInitialize(Req_0x3E);
  diagsetSuppressResp(Req_0x3E,0);
  diagSendRequest(Req_0x3E);
  ret = testWaitForDiagRequestSent(Req_0x3E,2000);
    if (ret == 1) 
    {
      testStepPass("Tx","-\tSuccessfully send Diagnostic request message.");
    }
    else
    {
      TestStepFail("Tx","-\tDiagnostic request timeout error! Error code: %ld",ret);
    }
}
Dragoni
  • 1
  • 2
  • What is in `sendDiagObject`? – MSpiller May 11 '23 at 08:54
  • testWaitForDiagRequestSent to wait for successful send and testWaitForDiagResponse to wait for successful receive. – Dragoni May 12 '23 at 09:50
  • Could you please add the complete code to the question, including the error code you get from `testWaitForDiagRequestSent`. In general, you have to use `diagSetSuppressResp`, else CANoe does not know that the suppressPosRspMsgIndicationBit is set and will "block" the channel as you have described. Your code seems to be correct, however, we cannot see how you call `service0x3E_req`, the implementation of `sendDiagObject` and the behavior you observe. Additionally, check the trace window, whether the suppressPosRspMsgIndicationBit is seen as set for your request. – MSpiller May 12 '23 at 09:56
  • Hello, it seems like you have experience in this subject. The error code I get from testWaitForDiagRequestSent is -92, and the wait time for this is 3s which is less than the P2 client timing (5s) - This is what is inside that `sendDiagObject `. During this 5s interval, all my UDS request is not blocked but get queued and sent after. As the suppressPosRspMsgIndicationBit, it is set because I use diagGetSuppressResp to observe it. But I don't know how to use the diagsetSuppressResp function effectively and its purpose, because I can set this suppress bit by raw bytes. – Dragoni May 13 '23 at 10:25
  • My current solution is to set the wait time for `testWaitForDiagRequestSent(message,diagGetP2timer(0)*1.1)` greater than this P2 client timing. Additionally, please explain the P2 client and P2 sever timing in CANoe. This confuses me pretty much. – Dragoni May 13 '23 at 10:31
  • As said, you should use `diagSetSuppressResp`, else CANoe does not know, that no response is expected and keeps waiting for P2. Your usage of this functions looks about right, what is the problem? P2 client is used when CANoe acts as tester, P2 server is used when CANoe acts as a ECU. – MSpiller May 15 '23 at 14:38
  • My problem is that I try to use `diagSetSuppressResp` and expect CANoe no to wait for P2 anymore. But still CANoe wait for P2 and delay subsequent request. – Dragoni May 16 '23 at 02:55
  • Could you provide a small example that shows your error. Only the code needed, no if-statements, no function calls, etc. As already said, we do not know, how your function above is called nor what is inside the called functions. – MSpiller May 16 '23 at 08:33
  • I added a simplified version – Dragoni May 19 '23 at 02:53
  • The 1st request is success but the next request get error code -92 – Dragoni May 19 '23 at 06:37
  • Hmm, looks good to me. Can you check the trace window, whether the second request got sent? Also, what is the output in the write window? When the diagnostic channel is "busy", i.e. CANoe waits for the answer of a request, you should get `-91`, not `-92`. – MSpiller May 22 '23 at 08:11

0 Answers0