Error-8257 about ADCS

[markZL]

When i use I/O control UDS command, there is Error-8257(out-of-sequence frame received by transport layer) happened after received FlowControl frame from ECU. The message log see attached pic.

[JefeL]

Hi MarkZL,

I'm a little confused by your log file as the timestamps seem to be out of order. Is the first frame received at the bottom or at the top of the log?

Are there any other ECUs communicating on the bus that could be conflicting with our expected response? In other words, is communication limited to ADCS and the target ECU? Is the bus monitor used below filtering out additional messages that aren't shown?

If the earliest received frame is at the top, then ADCS would be sending out the first frame of a multi frame command in the frame with a first byte of 0x10. The response from the ECU beginning with 0x30 appears to ba a valid flow control frame indicating clear to send all remaing frames.

[markZL]

Hi Jeff, thanks for your reply.

The timestamp in my log is the relative time(inteval time between 2 messages), not absolute time. And the message sequence is from top to end.And the log show all the messages on the bus, which means no message filter and no other messages from other ECU communication.

So that's the strange why the error pops up, where the message flow is normal, normal first frame, normal flow control and normal timing without timeout.

[JefeL]

I would like to try and reproduce the issue you are seeing with hardware on hand.

Can you provide me with the versions of LabVIEW, ADCS, and XNET/NI-CAN that you are using?

Knowing what hardware you are using the toolkit with will be helpfull as well.

[Ash_Tesla]

What was the outcome/solution ? I am encountering an similar issue when I am trying to use the routine control.

[TiBr]

I have nearly the same problem.

Here the block size in the flow control frame* is set to "0". I think in this case LabVIEW doesn't send a consecutive frame. But in my case after the correct control frame no consecutive frame will be send:

10 0C 2E F1 5A 17 07 05   REQ
30 0F 00 AA AA AA AA AA RESP

...nothing

* 30 00 0A 00 00 00 00 00

  Byte1 -> Bit 7..4: 0x3=FlowControl

  Byte 1 -> Bit 3..0: flow status (0=ClearToSend; 1=Wait; 2=Overflow)

  Byte 2: block size of the following consecutive frames (0..FF)

  Byte 3: min. separation time in ms (0..FF)

[TiBr]

Okay, I discoverd a problem before this request. An earlier request already results in an error...