PEAK-System Forum

Hello,

We are using PCAN-UDS 2.x API for development.
Library : PCAN-UDS.lib,PCAN-ISO-TP.lib, PCANBasic.lib
headers: PCAN-UDS_2013.h,PCAN-ISO-TP_2016.h, PCANBasic.h

When bus load is high (around 80%),
We are facing issue of while sending data transfer service of UDS it got failed and we got NRC as 73: Wrong Block Sequence Counter. Which is not allowing to flash controller Question :
1)How we can handle such scenario using PCAN UDS_2.x UDS APIs?
2) Can we increase timeout value to handle such scenario?
// Define TimeOuts
TimeoutBuffer =UDS_SET_ULBUFFER_VALUE; (10000)
StatusConfigMsg = UDS_SetValue_2013(channel, PUDS_PARAMETER_TIMEOUT_REQUEST, &TimeoutBuffer, sizeof(TimeoutBuffer));
StatusConfigMsg = UDS_SetValue_2013(channel, PUDS_PARAMETER_TIMEOUT_RESPONSE, &TimeoutBuffer, sizeof(TimeoutBuffer));

Hello,

1) When an ECU transmits NRC 0x73 (wrongBlockSequenceCounter) in response to Service TransferData, it means that an error was detected in the sequence of the UDS blockSequenceCounter:
In your case it is the block sequence #0. The UDS standard specifies that the sender should retransmit the request with that same blockSequenceCounter and the server shall accept it.
Are you sure of your sequence counter? #0 means that you have already sent 255 TransferData blocks successfully... As a reminder the 1st block for TransferData should always be #1.

2) I don't think your issue has something to do with TIMEOUT_REQUEST and TIMEOUT_RESPONSE parameters:
- the UDS fully transmits the request on the bus and the response is sent in about 10ms.
- regarding UDS communication the trace is OK.
You can assert this by checking the return code of your call to UDS_WaitForService_2013. If PUDS_STATUS_OK is returned then everything is fine, but the Negative UDS response means that the ECU could not process properly the request (check that the blockSequenceCounter is OK).

Hello,

1) Can u please elaborate how u find block sequece counter 0 ?

In your case it is the block sequence #0. The UDS standard specifies that the sender should retransmit the request with that same blockSequenceCounter and the server shall accept it.

Here u r telling we need to send with same sequence counter number but in other case,

2)

Are you sure of your sequence counter? #0 means that you have already sent 255 TransferData blocks successfully... As a reminder the 1st block for TransferData should always be #1.

-> here u r telling sequece counter block should transmit data with start with #1

3) If we send data chunk (4093*255) and then again we need to start sequence counter with #1 and then remaining data we need to send ?

4) If our hex file is more in size (4093 (chunk of data)*255 (sequence number)) we need to handle differently?

Continue the previous question

4) If our hex file is more in size (4093 (chunk of data)*255 (sequence number)) we need to handle differently?
149991 147386.611 DT 18DA21FA Rx 8 28 2F 28 0F 82 0F 02 F2
149992 147387.155 DT 18DA21FA Rx 8 29 00 55 55 55 55 55 55
149993 147388.731 DT 18DAFA21 Rx 8 02 76 FF 00 00 00 00 00
149994 147467.374 DT 18DA21FA Rx 8 1F FF 36 00 90 B9 44 02
149995 147468.802 DT 18DAFA21 Rx 8 30 00 00 00 00 00 00 00
149996 147469.726 DT 18DA21FA Rx 8 21 00 91 20 00 F6 D9 FF

In this scenario we need to start sequence counter once again with 01 instead of 00 and send remaining data?

Continue the previous question

Inspite sending data request with 0x1 instead of 0x00 we are getting problem in wrong sequence counter 0x73.
How to handle scenario when your sequence conuter reach 255 and again need to start with 0 or 1 ?

Shail wrote: ↑

Thu 6. Oct 2022, 19:55

172524 4253888.705 DT 18DA21FA Rx 8 27 6D FF FA FB F6 22 82
172525 4253889.265 DT 18DA21FA Rx 8 28 2F 28 0F 82 0F 02 F2
172526 4253889.809 DT 18DA21FA Rx 8 29 00 55 55 55 55 55 55
172527 4253891.570 DT 18DAFA21 Rx 8 02 76 FF 00 00 00 00 00
172528 4254037.510 DT 18DA21FA Rx 8 1F FF 36 01 90 B9 44 02
172529 4254038.690 DT 18DAFA21 Rx 8 30 00 00 00 00 00 00 00
....
....
....
173756 4278136.729 DT 18DA21FA Rx 8 29 40 55 55 55 55 55 55
173757 4278138.445 DT 18DAFA21 Rx 8 03 7F 36 73 00 00 00 00

Hello,

Please find below answers to your previous posts:
1) I thought blockSequenceCounter was 00 based on your trace, but I mixed up positive response and negative response parsing.
Please forgive me for this confusion. Contrary to a positive response to TransfertData which repeats the Service ID and the BlockSequence counter, the negative response does not include the blockSequenceCounter.
The ECU only informs that the last TransfertData request had a wrong block sequence counter but TransferData Request can and should be sent again with the correct counter.

2) & 3) & 4) As stated in the UDS standard:

The blockSequenceCounter parameter value starts at 01 with the first TransferData request that follows the RequestDownload or RequestUpload or RequestFileTransfer service. Its value is incremented by 1 for each subsequent TransferData request. At the value of FF the blockSequenceCounter rolls over and starts at 00 with the next TransferData request message.

Please check standard ISO 14229-1:2020 for more specific use case examples (note that explaining the UDS standard is out of our support scope).


To summarize, if the first 256 TransfertData requests were OK [from 0x00 to 0xFF] then the 257th should use blockSequenceCounter 0x00.
If your tests show that it fails with NRC wrongBlockSequenceCounter (using block sequence 0x00 or 0x01), I would suggest to ask to your ECU's manufacturer how the blockSequenceCounter is handled (maybe the firmware does not roll over after 0xFF and expect 0x100... which is not possible by UDS standard).

Hello,

"To summarize, if the first 256 TransfertData requests were OK [from 0x00 to 0xFF] then the 257th should use blockSequenceCounter 0x00.
If your tests show that it fails with NRC wrongBlockSequenceCounter (using block sequence 0x00 or 0x01), I would suggest to ask to your ECU's manufacturer how the blockSequenceCounter is handled (maybe the firmware does not roll over after 0xFF and expect 0x100... which is not possible by UDS standard)."

1) Problem is not only encountering when sequence counter roll over from 0xFF to 0x00. we are getting correct response when it roll over from 0xFF to 0x00. Since we are able to flash successfully 4 ECUs from total of 8 ECU. Even we are flashing same hex file for controller
Observation : IN certain use cases, when we use erase request that time OEM is trying to send request but flashing failed and restarting service from beginning.
While erasing happening at that time anywhere if bus heavy due to messages from other controller then any problem possible to encounter which make controller to go in restart state?

2) Is it problem of hardware or 120 Ohm or lose connection?

edit by Admin - please use quote for repeating text - see forum rules

Hello,

1) You should check your UDS workflow. It seems that when every request/response are OK the flashing runs as expecting.
However when ECU is responding with NRCs, those are not well handled:
* keep in mind that when wrongBlockSequenceCounter is responded, the ECU is still able to handle TransfertData. As stated in the standard you should retry the request.
* also take care to keep alive the session by sending tester present if it is not already handled automatically by the API.

IN certain use cases, when we use erase request that time OEM is trying to send request but flashing failed and restarting service from beginning.

We can't help you with description like "Flashing failed": the API provides a return status for UDS request and the network result of the ISOTP communication, you must analyse those to understand what is happening.

While erasing happening at that time anywhere if bus heavy due to messages from other controller then any problem possible to encounter which make controller to go in restart state?

I'm sorry but I don't fully grasp what you mean, please rephrase if I misunderstood:
Usually you order to stop communications from other components when you start a flashing procedure: to avoid bus heavy issues or firing of DTC.
If you have automatic Tester Present handled by the API that cause CAN bus errors because the ECU is unavailable, consider disabling the feature and handle the TesterPresent request manually.

2) You can find out if you have CAN bus issues by tracing the communication with another tool (like PCAN-View for instance).