Data padding setting issue

[fretim]

Hi,
I try to use the UDS library and to activate the data padding.
I've started from the "02_client_resquest_ecu_reset_USDT" C# sample project and I've made some modification to adapt it to my need as you can see in the code below.
Unfortunately even with the parameter set to 0x01 value that corresponds to padding_ON, it doesn't work.
Do I use the "UDSApi.SetValue_2013" function in the right way ?

Thanks for support.

Regards.

Code: Select all

   // Print version informations
            status = UDSApi.GetValue_2013(cantp_handle.PCANTP_HANDLE_NONEBUS, uds_parameter.PUDS_PARAMETER_API_VERSION, buffer, BUFFER_SIZE);
            Console.WriteLine("PCAN-UDS API Version - {0}: {1}", buffer, STATUS_OK_KO(status));
            string bauderate = "f_clock=80000000, nom_brp=1, nom_tseg1=127, nom_tseg2=32, nom_sjw=32, data_brp=1, data_tseg1=31, data_tseg2=8, data_sjw=8";

            // Initialize client
            status = UDSApi.InitializeFD_2013(tp_handle, bauderate);
            Console.WriteLine("Initialize channel: {0}", STATUS_OK_KO(status));
            status = UDSApi.SetValue_2013(tp_handle, uds_parameter.PUDS_PARAMETER_CAN_DATA_PADDING, new byte[] {0x01}, 1);
            Console.WriteLine("Set Padding: {0}", STATUS_OK_KO(status));

            // Initialize a physical configuration
            config_physical.can_id = (UInt32)0x14DA65F1;
            config_physical.can_msgtype = cantp_can_msgtype.PCANTP_CAN_MSGTYPE_FD | cantp_can_msgtype.PCANTP_CAN_MSGTYPE_EXTENDED;
            config_physical.nai.protocol = uds_msgprotocol.PUDS_MSGPROTOCOL_ISO_15765_2_29B_EXTENDED;
            config_physical.nai.target_type = cantp_isotp_addressing.PCANTP_ISOTP_ADDRESSING_PHYSICAL;
            config_physical.type = uds_msgtype.PUDS_MSGTYPE_UUDT;
            //config_physical.nai.source_addr = (UInt16)uds_address.PUDS_ADDRESS_ISO_15765_4_ADDR_TEST_EQUIPMENT;
            //config_physical.nai.target_addr = (UInt16)uds_address.PUDS_ADDRESS_ISO_15765_4_ADDR_ECU_1;
            config_physical.nai.extension_addr = 0x52;

            // Execute ECUReset and wait response
            status = UDSApi.SvcECUReset_2013(tp_handle, config_physical, out msg_request, UDSApi.uds_svc_param_er.PUDS_SVC_PARAM_ER_HR);
            Console.WriteLine("Execute ECUReset service: {0}", STATUS_OK_KO(status));
            status = UDSApi.WaitForService_2013(tp_handle, ref msg_request, out response, out request_confirmation);
            Console.WriteLine("Wait for service: {0}", STATUS_OK_KO(status));
            

(edit for better reading by Admin)

[K.Wagner]

Hello,

the using of padding values is per default activated, so you actually must do nothing.

Documentation regarding padding values

PaddingHelp.PNG (48.16 KiB) Viewed 3327 times

When running the sample 02 as you mentioned without modifying it, then we can see 5 bytes padding, using the byte 0x55

Running sample 02_client_request_ecu_reset_USDT without changes

Padding1.PNG (20.06 KiB) Viewed 3327 times

To assert the padding is configurable, we use the parameter PUDS_PARAMETER_CAN_PADDING_VALUE to change the value for padding to 0xff. The result of it, below the code

Code: Select all

status = UDSApi.SetValue_2013(tp_handle, uds_parameter.PUDS_PARAMETER_CAN_PADDING_VALUE, new byte[] { 0xFF }, 1);
Console.WriteLine("Set Padding value to 0xFF: {0}", STATUS_OK_KO(status));

Running sample 02_client_request_ecu_reset_USDT with Paddig 0xFF

Padding2.PNG (19.64 KiB) Viewed 3327 times

If we use the parameter PUDS_PARAMETER_CAN_DATA_PADDING to set the padding off, then padding is not used (picture shows only 3 bytes of data):

Code: Select all

status = UDSApi.SetValue_2013(tp_handle, uds_parameter.PUDS_PARAMETER_CAN_DATA_PADDING, new byte[] { 0x00 }, 1);
Console.WriteLine("Set Padding status: {0}", STATUS_OK_KO(status));

Running sample 02_client_request_ecu_reset_USDT with Paddig off

Padding.PNG (19.8 KiB) Viewed 3327 times

As far as I can say, the API is working as expected and you should also see padding bytes without changing anything in the sample code.

[F.Vergnaud]

Hello,

In complement to Keneth reply, you're also experiencing troubles due to your UDS message configuration:
you are configuring a UUDT message with a CAN identifier reserved for ISO-TP fixed-normal communications.
If you need to send a UUDT message, keep in ming that only can_id and can_msgtype are required (this is like writing a CAN frame):

Code: Select all

            config_physical.type = uds_msgtype.PUDS_MSGTYPE_UUDT;
            config_physical.can_id = (UInt32)0x14DA65F1;
            config_physical.can_msgtype = cantp_can_msgtype.PCANTP_CAN_MSGTYPE_FD | cantp_can_msgtype.PCANTP_CAN_MSGTYPE_EXTENDED;

But, since you are using WaitForService in your code, I assume you want a response from the ECU..
This is not possible with pure UUDT, otherwise you are in fact relying on a USDT design:
- you already know the CAN ID response of the ECU,
- and you should set this information in your code by defining a mapping.

Although you are using CAN ID 0x14DA65F1, but you set UDS message protocol to PUDS_MSGPROTOCOL_ISO_15765_2_29B_EXTENDED.
This is unfortunately not consistent, you either need to:
- use protocol PUDS_MSGPROTOCOL_ISO_15765_2_29B_FIXED_NORMAL with a USDT message (API will handle automatically the mapping configuration for you)
- or define a mapping for this CAN ID (keeping protocol PUDS_MSGPROTOCOL_ISO_15765_2_29B_EXTENDED). It will then override the default handling for this reserved CAN ID.

[fretim]

HI,
thanks for your explanation.
I finally succeded to send an UDS service and get the Ecu response.
I've reconfigured the UDS message to usdt and made a mapping with specifics known request ans response ids.

Regards.