Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ISO 14299 incorrect diagnostic message send #1311

Open
dskibarko opened this issue Feb 13, 2024 · 3 comments
Open

ISO 14299 incorrect diagnostic message send #1311

dskibarko opened this issue Feb 13, 2024 · 3 comments

Comments

@dskibarko
Copy link

The UDS messages should by a 8 bytes of CAN data allways. Not used bytes should be filled by paging data (0xAA value)/ It is a strong requirements but BusMaster can't support it.
For example command "Default diagnostic session" supported only this (0x02) 0x10 0x01 but not support strong ISO 8 bytes data (0x02) 0x10 0x01 0xAA 0xAA 0xAA 0xAA 0xAA.
I try to do manualy and observe strange multiframe transmitted instead of my data. Behavior is on the picture
BusMasterOpenSessionIssue

@reymor
Copy link

reymor commented Feb 18, 2024

Hello @dskibarko

  1. BusMaster does not have support any more. The last release was 7 years ago.
    image
  2. I do not understand your point here, maybe I'm wrong here but you are trying to send 8 bytes. This means you will need to use ISO-TP.

In your example, what could be "wrong" is that they do not 'clean' or 'set' the memory to a known value (AA, 00, or whatever), but you are trying to send 8 bytes which mean that this does not fit into 1 frame.

You could take this as reference.

image

When the payload exceeds 7 bytes, it needs to be split across multiple CAN frames. This is your case you are trying to send 8 bytes. You will need 2 CAN frames

image

This trace was is saying is:

  1. First message (FF)
    1 --> FF (First frame)
    008 --> Size (8bytes)
    Your data: 10 01 AA AA AA AA

  2. Flow control message (FC)
    03 01 00 00 00 00 00 00 (send by your ECU)

  3. Consecutive Frame (CF)
    2 --> CF (Consecutive frame)
    1 --> index
    Your remaining data (AA AA)

This reassemble into 10 01 AA AA AA AA AA AA --> Your original message

The other part is just the same as in the FF (This is, I think that it is "wrong"). However, I have seen this on some products.

About the padding, I'm not really sure, I've seen implementation in which they used 00s or AAs as you mention. However, I think that by ISO14299 they do not specify this as AAs.

Maybe, your misunderstanding is that when you put the databytes it means the bare frame. However, it means the data in UDS over CAN context.

@dskibarko
Copy link
Author

Hello @reymor !

Fine behavior should be same:
User define data for send diagnostic message 10 01 хх хх хх хх хх (7 bytes for diagnostic session 1 command send) and Busmaster should send to ECU eight data bytes 02 10 01 хх хх хх хх хх
Were 02 first byte is f lenght of diagnostic message (not CAN frame! CAN frame DLC should be 8),
and 10 is a open diagnostic session ID according ISO-14299 with parameter 01.
The eight data bytes for CAN-frame and requriments to use paged bytes is defined ISO 15765 -3/-4.
ISO_15765-3_8bytes

By the way, the Busmaster should to understund the first byte of data and if it a UDS service value (in this case the value 10 is a diagnostic session control service ID) do not send multiframe.

@reymor
Copy link

reymor commented Feb 20, 2024

As I said, it is said padded. It does not said padded with 0xAA. Anyway, this is not a "big" problem.

Here, I do not understad, if I set this to 10 01

image

It sent 02 10 01 00 00 00 00 00 which what you said. What is the problem with that?

You said that it shall be 02 10 01 AA AA AA AA AA, right? I think that in this case both are correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants