UDS Secruity Access issues with fragmented messages

[Root.W]

Hello,

I have some issues regarding the security access to an ecu.
In generell everything seems to work fine until I have to send the key -16 bytes of data-.
I use PCAN-View to monitor the communication and I realized, that the message-flow starts correctly.
The application sends the first frame and the ECU responds with a FC frame, but that's all. The function UDS_WaitForService returns PUDSStatus = 0x7 NO_MSG.
I use non standard CAN IDs, which I have mapped accordingly to example 4.3.3.
I tested the mappings with the function SvcReadDataByIdentifier (received multiple frames with correct tester fc frame) and UDS_WaitForService returns the correct data.

I'll try to explain my source code with some kind of pseudo code.

Code: Select all

TPUDSStatus result;
TPUDSCANCHandle  uds_channel = 0x51; //USBBUS1
TPUDSMsg  MSG;
MSG.NETADDRINFO.SA = 0xF1;
MSG.NETADDRINFO.TA = 0x01;
MSG.NETADDRINFO.RA = 0x00;
MSG.NETADDRINFO.TA_TYPE = PUDS_ADDRESSING_PHYSICAL;
MSG.NETADDRINFO.PROTOCOL = PUDS_PROTOCOL_ISO_15765_2_11B;

// Note: Channel is properly initialized with UDS_Initialize(..)

// set custom Can ID tester ->ecu
MSG.DATA.RAW[0] = 0;
MSG.DATA.RAW[1] = 0;
MSG.DATA.RAW[2] = 0x02;
MSG.DATA.RAW[3] = 0x34;
MSG.DATA.RAW[4] = 0;
MSG.DATA.RAW[5] = 0;
MSG.DATA.RAW[6] = 0x06;
MSG.DATA.RAW[7] = 0x78;

result = UDS_SetValue(uds_channel, PUDS_PARAM_MAPPING_ADD, &MSG, sizeof(MSG));

// add custom Can ID ecu -> tester
MSG.NETADDRINFO.SA = 0x01;
MSG.NETADDRINFO.TA = 0xF1;
MSG.DATA.RAW[0] = 0;
MSG.DATA.RAW[1] = 0;
MSG.DATA.RAW[2] = 0x06;
MSG.DATA.RAW[3] = 0x78;
MSG.DATA.RAW[4] = 0;
MSG.DATA.RAW[5] = 0;
MSG.DATA.RAW[6] = 02;
MSG.DATA.RAW[7] = 34;
result = UDS_SetValue(uds_channel, PUDS_PARAM_MAPPING_ADD, &MSG, sizeof(MSG));

MSG.NETADDRINFO.SA = 0xF1;
MSG.NETADDRINFO.TA = 0x01;

// use MSG.NETADDRINFO with a new TPUDSMsg
TPUDSMsg Testmsg;
Testmsg.NETADDRINFO = MSG.NETADDRINFO;

//succeeds every time
//read bytes  e.g. ECU first frame -> tester flow control -> ECU cons. frames
result = UDS_SvcReadDataByIdentifer(uds_channel, Testmsg ,0x2494, 2); 

//change session to extended
//CAN tracing showed that tester present is sent periodically.
result = UDS_SvcDiagnosticSessionControl(uds_channel, Testmsg, 0x03);

// This request succeeds. 
// I am able to receive 16 bytes
result = UDS_SvcSecurityAccess(uds_channel, Testmsg, PUDS_SVC_PARAM_SA_RSD_3, null, 0); 

// magical things done with seed.  [...]
// further called Buffer[16]

TPUDSMsg request ;
result = UDS_SvcSecurityAccess(uds_channel,Testmsg,PUDS_SVCPARAM_SK_4, Buffer, sizeof(Buffer))

	if(result == PUDS_ERROR_OK)
	{
		// this function returns "NO MESSAGE" in this particular case
		//the CAN trace shows that the first frame was correct
		//0x234  :: 10 12 27 xx xx xx xx xx  <- tester  XX XX -> correct first bytes of Buffer[16]
		//0x677  :: 30 08 0A 01 xx xx xx xx <- ecu
		// no furhter tester communciation
		//expected communication 
		//0x234 :: 21 ....                             <- tester missing bytes till all bytes are transmitted
		//0x234 :: 22 ....
		//0x677 :: 02 67 ...                         <- ecu
		// function return happens pritty fast, way less than 10 seconds.
		result = UDS_WaitForService(uds_channel, &Testmsg, &request, null);
	};

Unfortunately I dont have any clue, what I'm doing or maybe using wrong trying to achieve that multiple frames are sent correctly.
I have no issues receiving many ISO TP frames.
Do I use the wrong function in this case?
Tester hast to send multiple messages and has to react to a FC frame correclty?
Does the DiagnosticSessionControl function change the overall behavior and do i have to do some kind of remapping, after changing the session?

Maybe you can help me in this case, if I'm missing some infos regarding the uds.dll.

Thank you very much.

[K.Wagner]

Hello,

As I can see, you are using the UDS revision 2006 (in our API implemented as PCAN-UDS version 1.x). Even when newer UDS versions remains compatible with UDS v1.x, there have been some imcompatibilities that were corrected in the last two years. So please, check that you are using the latest versions of the dlls needed. The current versions are:

• PCAN-Basic (PCANBasic.dll): v4.6.0
• ISO-TP (PCAN-ISO-TP.dll): v3.2.0
• UDS (PCAN-UDS.dll): v2.2.0

As far as I can see, the code looks OK. Our test also shows that a response using PUDS_SVC_PARAM_SA_SK_4 is also received. The only thing I cannot see is the initialization of the TPUDSMsg before calling UDS_SvcSecurityAccess. Be sure you are configuring it to receive a response, i.e., you are not setting the field NO_POSITIVE_RESPONSE_MSG to other different than 0. For instance, use something like:

Code: Select all

        TPUDSMsg Testmsg = {};
...
	result = UDS_SvcSecurityAccess(uds_channel, &Testmsg , PUDS_SVC_PARAM_SA_SK_4, Buffer, sizeof(Buffer));

[Root.W]

Hello,

thank you for the reply.

I checked all DLL versions and I am using the latest versions.

I also checked

Code: Select all

TPUDSMsg Testmsg = {};

My Testmsg is configured:

Code: Select all

Testmsg.NO_POSITIVE_RESPONSE_MSG = PUDS_KEEP_POS_RSP_MSG_INDICIATION_BIT; // (0x0)

I tried to finish the communication myself using PCANBasic.dll (Read + Write) and I figured something out, which may be helpfull.

Using the initialized PUDS_handle:

I am able to send the message with my custom CAN ID 0x234 but the READ function does not receive any frame from 0x678. The api seems to ignore/swallows the mapped ID completely.
PCAN-View showed the received FC frame

Code: Select all

   0x234   10 12 27 ...
   0x678   30 08 0A 01 01 ...

Uninitializing the PUDS_handle and initializing a "new" TPCANhandle (PCAN Basic).

I am able to transmit and receive all frames. I scripted the ISO TP communication to check if I'd be able to unlock my device which worked perfectly fine, but the missing "auto-tester present" keeps this solution limited for a few seconds.

[K.Wagner]

Hello,

note that when using the same handle in both APIs for reading, it cause them to contest for messages (there is only one queue, since this is the same channel). If you read over PCAN-Basic, then UDS never gets that message. This makes the communication in UDS to fail, so it is not advisble to do this.

We do not have an ECU with secure access for testing, but an emulator. If I use the data you provided, I got following communication:

Test with PUDS_SVC_PARAM_SA_SK_4

UDS_Test.PNG (36.38 KiB) Viewed 3591 times

I have no other idea what could be happenning on your side to cause this problem. Just for curiosity, did you get a negative response when sending a wrong key?

[Root.W]

Hello,

thank you for the advice checking a negative response.

The WaitForService functions returns "PUDS_ERROR_NO_MESSAGE" in both cases.

I got curios too and used the SvcWriteDataByIdentifer function. The reply should be a single frame positive response.

Code: Select all

//request uses the nettaddrinfo with custom mappings
//SA = 0xF1;
//TA = 0x01;
//RA = 0x00;
//TA_TYPE = PUDS_ADDRESSING_PHYSICAL;
//PROTOCOL = PUDS_PROTOCOL_ISO_15765_2_11B;
// RESULT = 0; 
// NO_POSITIVE_RESPONSE_MSG = 0;
// MSGTYPE = 0;
// DATA[] = {};

TPUDSMsg request;
TPUDSMsg response = {};

result = SvcWriteDataByIdentifier(puds_channel, &request, 0x1234, 2);

if(result == PUDS_ERROR_OK)
	{
		// timeout 10sec. -> "PUDS_ERROR_NO_MESSAGE"
		result = UDS_WaitForService(uds_channel, &request, &response, null);
	}

Code: Select all

0x234 04 2E 12 34 //
0x678 03 6E 12 34 //<-PCAN View

The api returns "PUDS_ERROR_NO_MESSAGE" after the regular 10sec timeout. The trace with PCAN-View showed the correct ECU response.

[K.Wagner]

Hello,

using UDS_SvcWriteDataByIdentifier on my side also works as expected. Here the trace in PCAN-View:
.

Trace of communication by WriteByIdentifier

WriteByIdentifier.PNG (28.36 KiB) Viewed 3567 times

The only difference I see (if you have not edited the PCAN-View data you have posted), is that the data appears to come from the ECU with no padding bytes. The API uses padding by default (see the picture above, Length is always 8 and padding bytes have the value 0x55). If padding is used in the API and responses come without padding, the API might mark them as invalid and discard them.