PEAK-System Forum

Hi , we use the PCAN-UDS samples --> C# 06_client_all_request, try to get can_data try to get can_data

    config.can_id = (UInt32)0x18DA2EF9;
    config.can_msgtype = cantp_can_msgtype.PCANTP_CAN_MSGTYPE_STANDARD;

    config.nai.protocol = uds_msgprotocol.PUDS_MSGPROTOCOL_ISO_15765_2_29B_FIXED_NORMAL;  //1019
    config.nai.extension_addr = 0x0;
    config.nai.target_type = cantp_isotp_addressing.PCANTP_ISOTP_ADDRESSING_PHYSICAL;
    config.type = uds_msgtype.PUDS_MSGTYPE_USDT;
    config.nai.source_addr = (UInt16)uds_address.PUDS_ADDRESS_ISO_15765_4_ADDR_TEST_EQUIPMENT;
    config.nai.target_addr = (UInt16)uds_address.PUDS_ADDRESS_ISO_15765_4_ADDR_ECU_1;

    testReadDataByIdentifier(client_handle, config);

But we get the result as follow:

TX/RX ID DLC Data Byte(s)
TX 0x18DA2EF9 8 03 22 F1 90 00 00 00 00
RX 0x18DAF91E 4 03 7F 22 78
RX 0x18DAF91E 8 10 14 62 F1 90 00 00 00
TX 0x18DA2EF9 8 30 00 00 55 55 55 55 55

We expected to get the following message:

TX/RX ID DLC Data Byte(s)
TX 0x18DA2EF9 8 03 22 F1 90 00 00 00 00
RX 0x18DAF91E 4 03 7F 22 78
RX 0x18DAF91E 8 10 14 62 F1 90 00 00 00
TX 0x18DA2EF9 8 30 00 14 00 00 00 00 00
RX 0x18DAF91E 8 21 00 00 00 00 00 00 00
RX 0x18DAF91E 8 22 00 00 00 00 00 00 00

Could you help to point out the cause of the error or where it needs to be corrected?

By the way, do we need to "AddMapping_2013" before using "SvcReadDataByIdentifier_2013" API ?

Thx

Hello,

First of all please make sure you're using the latest version of PCAN-UDS API (at least v2.1.1.118): we could not reproduce your issue based on your inputs.

The case you're describing is quite odd and would need some double checkings.
Your expected trace seems invalid (considering you are using ISOTP FIXED NORMAL addressing):

TX/RX ID DLC Data Byte(s)
TX 0x18DA2EF9 8 03 22 F1 90 00 00 00 00 <-- Request from Tester (0xF9) to ECU (0x2E): 0x2E seems to be a functionnal address or maybe an additionnal address from ECU(0xE1) ?
RX 0x18DAF91E 4 03 7F 22 78 <-- Temporary Response from ECU 0x1E (ECU wants more time) (this means that the ECU is listening to 0x2E address)
RX 0x18DAF91E 8 10 14 62 F1 90 00 00 00 <-- Response from ECU 0x1E to Tester 0xF9 (First frame)
TX 0x18DA2EF9 8 30 00 14 00 00 00 00 00 <-- Flow control frame from Tester (0xF9) to 0x2E: this is invalid, the target must be equal to the source address of the First Frame (0x1E).
RX 0x18DAF91E 8 21 00 00 00 00 00 00 00 <-- Consecutive frame #1 from 0x1E to Tester 0xF9
RX 0x18DAF91E 8 22 00 00 00 00 00 00 00 <-- Consecutive frame #1 from 0x1E to Tester 0xF9

Here is a proposal to your configuration:

config.can_id = -1; // can ID is computed automatically when using FIXED NORMAL addressing
config.can_msgtype = cantp_can_msgtype.PCANTP_CAN_MSGTYPE_STANDARD;

config.nai.protocol = uds_msgprotocol.PUDS_MSGPROTOCOL_ISO_15765_2_29B_FIXED_NORMAL;
config.nai.extension_addr = 0x0;
config.nai.target_type = cantp_isotp_addressing.PCANTP_ISOTP_ADDRESSING_PHYSICAL;
config.type = uds_msgtype.PUDS_MSGTYPE_USDT;
config.nai.source_addr = (UInt16) 0xF9;
config.nai.target_addr = (UInt16) 0x1E; // if Physical addressing is wanted, it should match the actual address of the ECU

If you need to communicate with target address 0x2E, then you should make a funtional request as another address is responding to the request.

Finally about the can_data from the Tester's flow control response, this can be configured with parameters PUDS_PARAMETER_BLOCK_SIZE and PUDS_PARAMETER_SEPARATION_TIME (byte #3 is the minimum separation time and should be set to 0x14).

Hi Vergnaud

Thanks for your feedback. It's useful for us.
We also changed the source mapping can_id and response mapping can_id, the communication was normal.

Best regards,
Jerry

PEAK-System Forum

"SvcReadDataByIdentifier_2013" API can't get right can_data

"SvcReadDataByIdentifier_2013" API can't get right can_data

Re: "SvcReadDataByIdentifier_2013" API can't get right can_data

Re: "SvcReadDataByIdentifier_2013" API can't get right can_data