This memo provides information about how to exchange data with the UDS protocol through the OOBD firmware. Distribution of this memo is unlimited.

Copyright (C) OOBD Team (2017). All Rights Reserved.

The CAN UDS mode supports:

• exchanging data on the bus following the UDS protocol
• logs module answers addresses (Ping mode)

(example for HS-CAN setup)

Select the CANraw mode protocol

p 1 1 1 0

This activates the CAN UDS mode protocol, set the parameters to its defaults and sets the CAN bus into “invisible listen” mode

Select the HS-CAN interface

p 8 4 0

Select HS-CAN bus speed to 500kbit/s (for other bitrates please have a look to the firmware syntax here: The OOBD Firmware Syntax)

p 8 3 3

Set CAN filter Start address

p 8 10 1 $000

Set CAN filter mask (here: all frames $000 - $7FF are enabled)

p 8 11 1 $000

Set CAN-Transceiver to normal operating mode

p 8 2 3

You can send your data, as usual formatted as hexadecimal coded string

 00112233445566.....

The input buffers covers maximal 4095 bytes, which should be sufficient for quite complex CAN telegram sequences.

The ping mode is a prioritary extension to the normal UDS handling. It is used to identify the actual active modules on the bus.

To use it, set all parameters (adress, timeout etc.) as if you would like to do a normal broadcast. Then set the Ping flag with

p 6 11 1

This flag is set until the next data is sent or it's reset back again with

p 6 11 0

When then the next data block is send, then only the first frame is sent. After send that first frame, the software is collecting the answers, following the conditions

• only the first received frame from a module is stored
• it's only stored if the total buffer size is not exceeded
• it's only stored if it's a single, first or flow control frame. Consecutive frames will not be stored

After the answer timeout is reached, the data of all received frames will be returned

When any module has answered, the result is returned in blocks of 12 Bytes

The data consists of one or more blocks:

Block_1 [Block_2 .. Block_n]

Each block consists of the following Byte sequence:

CAN-ID_Byte3 (MSB) CAN-ID_Byte2 CAN-ID_Byte1 CAN-ID_Byte0 (LSB) Data_Byte_0 .. Data_Byte_8

Following the scheme above, there can be so much blocks send in one go as fit into the input buffer of 4095 bytes.

explain errors

give samples

This RFC raises security issues. Sending frames on the bus might create unexpected reactions .

Steffen Koehler

Phone: +49 172 410 35 98

EMail:steffen@koehlers.de

Copyright (C) OOBD Team (2017). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the OOBD Team organizations, except as needed for the purpose of developing standards in which case the procedures for copyrights defined in the Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the OOBD Team or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and THE OOBD TEAM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.“ Relation to other RFCs

The OOBD-RFC announcements are distributed via the oobd-commit-messages@googlegroups.com mailing list.

To join (or quit) the list goto https://groups.google.com/forum/?hl=de&fromgroups=#!forum/oobd-commit-messages