SvcWriteDataByIdentifier Timeout

[Rommel]

Hi

here my try to send Data to an ECU by

status = UDSApi.SvcWriteDataByIdentifier_2013(tp_handle, config, out request, (uds_svc_param_di)0, data_record, data_record_size);
if (UDSApi.StatusIsOk_2013(status))
status = UDSApi.WaitForService_2013(tp_handle, ref request, out response, out confirmation);

status = UDSApi.GetErrorText_2013(status, 0, buffer, BUFFER_SIZE);

CAN traffic
PEAKCAN: 10 0A 2E 00 00 ....
ECU: 30 0F 00
PEAKCAN: 21 ...
PEAKCAN: Timeout

when I use Readby Identifentifer and ECU sends more than 8 bytes PEakcan is not answering after last 2nd Frame
what Peakcan is expecting after last 2nd Frame?

[F.Vergnaud]

Hello,

Most probably, you haven't configured the required mappings to identify the segmented communication between your application and the ECU.
Only standardized ISO-15675-4 CAN IDs are configured by default, please check the documentation §4.3 "UDS and ISO-TP Network Addressing Information" (starting p.770).
You'll find a configuration example in §4.3.3 for a communication with CAN IDs 0x326/0x626.

[Rommel]

I mapped the messages by

Code: Select all

                        uds_mapping requestMapping = new uds_mapping();
                        requestMapping.can_id = 0x18DA017E;
                        requestMapping.can_id_flow_ctrl = 0x18DA7E01;
                        requestMapping.can_msgtype = config.can_msgtype;
                        requestMapping.can_tx_dlc = 8;
                        requestMapping.nai = config.nai;

                        uds_mapping responseMapping = requestMapping;
                        responseMapping.can_id = requestMapping.can_id_flow_ctrl;
                        responseMapping.can_id_flow_ctrl = requestMapping.can_id;

                        responseMapping.nai.source_addr = requestMapping.nai.target_addr;
                        responseMapping.nai.target_addr = requestMapping.nai.source_addr;

with testerpresent and flowcontrol its working fine

[F.Vergnaud]

CAN IDs 0x18DAxxyy are reserved and standardized for ISOTP FIXED NORMAL addressing.
You can check "§4.3 UDS and ISO-TP Network Addressing Information" page 771 for more information.

You don't need to configure mappings with this configuration, but this means that your node address is either 0x01 or 0x7e which is not the default TESTER_EQUIPMENT address.
You should configure the correct address (parameter PUDS_PARAMETER_SERVER_ADDRESS) or add it to the listened address (parameter PUDS_PARAMETER_ADD_LISTENED_ADDRESS): see "§4.3.1 Usage in a Non-Standardized Context".

[Rommel]

Hi
now I am little bit confused. I thought if I use 29b if have to add mapping.Only 11Bit id is premapped
I changed now the canid but I still have that issue. UDS is working fine except Write by Identifier. Request is send ECU answers by 0x30, all Data is send to ecu but than a time out occurs

config = new uds_msgconfig();
config.can_id = 0x18DA01F1;
config.can_msgtype = cantp_can_msgtype.PCANTP_CAN_MSGTYPE_STANDARD;
config.nai.protocol = uds_msgprotocol.PUDS_MSGPROTOCOL_ISO_15765_2_29B_NORMAL;
config.nai.target_type = cantp_isotp_addressing.PCANTP_ISOTP_ADDRESSING_PHYSICAL;
config.type = uds_msgtype. PUDS_MSGTYPE_USDT;
config.nai.source_addr = 0xF1;// (UInt16)uds_address.PUDS_ADDRESS_ISO_15765_4_ADDR_TEST_EQUIPMENT;
config.nai.target_addr = 0x01;// (UInt16)uds_address.PUDS_ADDRESS_ISO_15765_4_ADDR_ECU_1;
config.nai.extension_addr = 0x0;

uds_mapping requestMapping = new uds_mapping();
requestMapping.can_id = 0x18DA01F1;
requestMapping.can_id_flow_ctrl = 0x18DAF101;
requestMapping.can_msgtype = config.can_msgtype;
requestMapping.nai = config.nai;


uds_mapping responseMapping = requestMapping;
responseMapping.can_id = requestMapping.can_id_flow_ctrl;
responseMapping.can_id_flow_ctrl = requestMapping.can_id;
responseMapping.nai.source_addr = requestMapping.nai.target_addr;
responseMapping.nai.target_addr = requestMapping.nai.source_addr;

[F.Vergnaud]

Hello,

Be careful with your nai.protocol configuration, you're using:

config.nai.protocol = uds_msgprotocol.PUDS_MSGPROTOCOL_ISO_15765_2_29B_NORMAL;

this mode indeed requires a mapping, but due to the CAN IDs you are using it should be best to use 29B_FIXED_NORMAL which does not require mapping:

Code: Select all

  config.nai.protocol = uds_msgprotocol.PUDS_MSGPROTOCOL_ISO_15765_2_29B_FIXED_NORMAL; 

Also, the can_msgtype is wrong (11bit is set instead of 29bit):

config.can_msgtype = cantp_can_msgtype.PCANTP_CAN_MSGTYPE_STANDARD;

it should be:

Code: Select all

 config.can_msgtype = cantp_can_msgtype.PCANTP_CAN_MSGTYPE_EXTENDED;

UDS is working fine except Write by Identifier. Request is send ECU answers by 0x30, all Data is send to ecu but than a time out occurs

To help understand your issue, please provide precise information: what function are you using (ex: UDS_WaitForService)? what is the error code? also include an excerpt of the CAN trace showing the problem.
As is, it feels like the request is correctly transmitted but the ECU is taking time to process it and your application reports a timeout.

[Rommel]

Mapping is working fine now without extra mapping.

But still timout issue


status = UDSApi.SvcWriteDataByIdentifier_2013(tp_handle, config, out request, (uds_svc_param_di)1, data_record, data_record_size);
if (UDSApi.StatusIsOk_2013(status))
status = UDSApi.WaitForService_2013(tp_handle, ref request, out response, out confirmation);

Data transfer is working
Tester 10 0C 2E ...
ECU 30 0F 00
Tester 21 ....
after a while: Timeout while waiting request message responce

[F.Vergnaud]

Your request is sent : size is 0x0C, so it fits in 2 frames "10 0C 2E ..." and "21 ...".
As your trace doesn't show anything else, please check if the ECU is actually responding to your request. If not, then the API is consistent: you have an error code "timeout response" (PUDS_STATUS_SERVICE_TIMEOUT_RESPONSE) because no response is received...

[Rommel]

Yes tester sends 10 0C 2E ...
ECU 30 0F 00 sends
and Tester sends 21 ....

After that ECU is not sending anything. Does ECU has to send a 2E+40?
I checked with svc load there ECU sends more than 100 bytes but TesterPeakAPI is not sending anything after last Message too

[F.Vergnaud]

An ECU should always respond (either positively or negatively) to a UDS request.
If it is positive, response must include (Service_ID + 0x40) in the UDS PCI bytes, this is defined in UDS standard (ISO-14229).
Please keep in mind that explanation of UDS standards is out of scope of our support.

I checked with svc load there ECU sends more than 100 bytes but TesterPeakAPI is not sending anything after last Message too

I don't know what "svc load" is, or may be you mean UDS service "ReadDataByIdentifier"? Please once again be more precise in your statements.

It feels like you are confusing ISOTP protocol and UDS protocol:
- UDS API helps you handle UDS requests and responses,
- your application has to handle those: PCAN-UDS API will not respond automatically to UDS requests.
- a UDS message is transported via ISOTP protocol. Message can be segmented in multiple CAN frames: it is handled internally by the API. This corresponds to the trace you mention (10 0C 2e .../ 30 0F 00 / 21 ...)