User Tools

Site Tools


doc:rfc_canuds-mode

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

doc:rfc_canuds-mode [2017/03/18 13:42] (current)
admin created
Line 1: Line 1:
 +====== CAN UDS Mode Protocol for the OOBD Firmware ======
  
 +
 +| OOBD Team | S. Koehler |
 +| Request for Comments:8 | 
 +| Obsoletes: -  |  | 
 +| Category: Draft Standard |  Apr 2017 | 
 +
 +
 +===== Status of this Memo =====
 + 
 +
 +This memo provides information about how to exchange data with the UDS protocol through the OOBD firmware. ​ Distribution of this memo is unlimited. ​
 +===== Copyright Notice =====
 + 
 +
 +Copyright (C) OOBD Team (2017). ​ All Rights Reserved. ​
 +===== Introduction =====
 + 
 +The CAN UDS mode supports:
 +  * exchanging data on the bus following the UDS protocol
 +  * logs module answers addresses (Ping mode)
 +
 +
 +===== Concept =====
 +
 +
 +==== Initialization ====
 +
 + ​(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: [[doc:​hw_commands|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
 +
 + 
 +==== Configuration ====
 +
 +FIXME 
 +
 +===== Commands ====
 +
 +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.
 +
 +
 +===== Ping Mode (Scan available Modules) ====
 +
 +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
 +
 +
 +=== The Data Format ===
 +
 +
 +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.
 +
 +
 +==== Errors ====
 +
 +FIXME explain errors
 +
 +
 +==== Examples ====
 +
 +
 +FIXME give samples
 +
 +===== Implementation Details =====
 +
 +
 +  ​
 +
 +
 +===== Security Considerations =====
 + 
 +
 +This RFC raises security issues. Sending frames on the bus might create unexpected reactions
 +
 +===== References =====
 + 
 +
 +===== Authors'​ Addresses =====
 + 
 +
 +Steffen Koehler
 +
 +Phone: +49 172 410 35 98
 +
 +EMail:​steffen@koehlers.de ​
 +===== Appendix =====
 +  ​
 +
 +===== Full Copyright Statement =====
 + 
 +
 +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 
 +
 +===== Updates =====
 + 
 +
 +===== Obsoletes =====
 + 
 +
 +===== Obsoleted-by =====
 + 
 +
 +===== Updated-by =====
 + 
 +
 +===== Contact =====
 + 
 +
 +===== Distribution Lists =====
 + 
 +
 + 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
doc/rfc_canuds-mode.txt ยท Last modified: 2017/03/18 13:42 by admin