PEAK-System Forum

Is it possible to change the timing parameters (N_AS,N_AR,N_BS,N_BR,N_CS,N_CR) for a UDS session

using the peak uds and peak iso tp api ?

Hello,

for ISO-TP it is possible to change following timing values:

• PCANTP_PARAM_SEPARATION_TIME: This value is used to set the SeparationTime (STmin) parameter defined in the ISO‐TP standard: it indicates the minimum time the sender is to wait between the transmissions of two Consecutive Frames.

for UDS it is possible to change following timing values:

• PUDS_PARAM_TIMEOUT_REQUEST: This value defines the maximum waiting time to receive a confirmation of a transmission. It is used in UDS utility functions like UDS_WaitForService
• PUDS_PARAM_TIMEOUT_RESPONSE: This value defines the maximum waiting time to receive a response indication. Note that the exact timeout value is the sum of this parameter and the timeout defined in the active diagnostic session. It is used in UDS utility functions like UDS_WaitForService.
• PUDS_PARAM_SEPARATION_TIME: This value is used to set the SeparationTime (STmin) parameter defined in the ISO‐TP standard: it indicates the minimum time the sender is to wait between the transmissions of two Consecutive Frames.

other values are not possible to be changed.

from the manufacturer of the ecu i got following information ...
but i can't seem to setup an uds session... the ecu never responds...
Could it be that they are deviating from the iso standard ?

TP Parameters
Parameter Value
N_AS 20
N_AR 20
N_BS 250
N_BR 30
N_CS 250
N_CR 250
Padding No Padding
ST_Min 10
BS 0

UDS Parameters
Parameter Value
TX Frame 0x75F
RX Frame 0x65F

Hello,

yes, it seems as they are using non-standard values for the timing. The values used by our ISO-TP are the recommended values, as appears in the document "ISO_15765-2;2004" (ISO 15765-2):
N_AS 1000
N_AR 1000
N_BS 1000
N_BR -
N_CS -
N_CR 1000

so if I understand correct.. i can't use the iso tp and uds api to setup the session ?
is there another way to setup this UDS session ?

as said before, this API implements the standard ISO-TP/UDS as documented in the norms ISO 15765-2 and ISO 15765-3. If the ECU is compilant to those standards, then it should work.

Actually, there is no reason to say that a session cannot be set up. Setting up an UDS session is a 1 frame request. Since the transmission of this frame doesn't use any timeout, the setup should work. The problem could occur at receiving time, since the ECU may transmit a segmented response, and so the timeouts could occur.

In order to check if the ECU is responding, just connect a PCAN-VIew to the same PCAN-USB you are using for UDS communication and take a look of the communication generated.

Otherwise the problem may be elsewhere, for example, a wrong network information. Note that the Rx/Tx frame 0x75F/0x65F are non-standard. Maybe you will need to configure ISO-TP to handle those CAN ID mappings.

Yes,

you were correct ... it seems I had to send a can cyclicity command before i could enter diagnostic mode.

now when is send
ID=1887 (0x75f) ,Type=D,DLC=3,Data=2 16 1 (0x02 0x10 0x01)
I get as response
ID=1631 (0x65f) ,Type=D,DLC=7,Data=6 80 1 0 200 0 20 (0x06 0x50 0x01 0x00 0xc8 0x00 0x14)

now when i use the api I need to send
status = UDSApi.SvcDiagnosticSessionControl(canchannel, ref Message, UDSApi.TPUDSSvcParamDSC.PUDS_SVC_PARAM_DSC_DS);
and wait for a valid response using the following command
status = UDSApi.WaitForService(canchannel, out MessageResponse, ref Message, out MessageReqBuffer);

but here the status is always PUDS_ERROR_NO_MESSAGE although the timeout seems to be correct,
if i switch off the dut, the function will wait 2S... if the dut is switched on the function is finished almost instantly.

Here below you can also see my can mapping and netinfo

TPCANTPStatus result = CanTpApi.AddMapping(canchannel,0x75f,0x65f,
TPCANTPIdType.PCANTP_ID_CAN_11BIT,TPCANTPFormatType.PCANTP_FORMAT_NORMAL,
TPCANTPMessageType.PCANTP_MESSAGE_DIAGNOSTIC,
0xF1,
0x13,
TPCANTPAddressingType.PCANTP_ADDRESSING_FUNCTIONAL, 0x52)

TPUDSNetAddrInfo NetInfo;
NetInfo.SA = 0xF1;
NetInfo.TA = 0x13;
NetInfo.TA_TYPE = TPUDSAddressingType.PUDS_ADDRESSING_FUNCTIONAL;
NetInfo.RA = 0x52;
NetInfo.PROTOCOL = TPUDSProtocol.PUDS_PROTOCOL_ISO_15765_2_11B;


any idea what could be the problem ?

Hello,

I think you have forgotten to define some ISO-TP mappings or mixed up things with the one you defined:
- A mapping using a functional addressing cannot have a mapped CAN ID response, because in ISO-TP it is forbidden to reply to a functionally addressed message with a functionnally addressed message.
- In fact to define a 2-way communication with an ECU and include support for functional messages, you need to define 3 mappings:
1. One (physical) mapping allowing communication from your external test equipment to the ECU (request)
2. One (physical) mapping allowing communication from the ECU to your external test equipment (reply)
3. One (functional) mapping allowing communication from your external test to any ECUs on the bus CAN (broadcast message).

What may be confusing is that our API function AddMapping takes a parameter called canIDResponse. But it only informs the API that when a segmented message is transmitted the target will send CAN frames with canIDResponse as its CAN ID. But those CAN frames are not the response you expect: it is used by the ISO-TP protocol to define things like Minimum Separation Time, Block Size, busy status, etc.. In fact it's protocol stuff and for the end-user it is invisible (as if the target never replied).
That's why you need to define a 2nd physical mapping if you expect a real response from the target.

Now here is how your configuration should look like: Notice that I have also removed the RA parameter, since it is not allowed with the format type PCANTP_FORMAT_NORMAL.

yes...

you are right...

forgot to add the mapping for the response...

now it's working.