doc:rfc_canuds-mode
no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
— | doc:rfc_canuds-mode [2017/03/18 13:42] (current) – created admin | ||
---|---|---|---|
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. | ||
+ | ===== Copyright Notice ===== | ||
+ | |||
+ | |||
+ | Copyright (C) OOBD Team (2017). | ||
+ | ===== Introduction ===== | ||
+ | |||
+ | The CAN UDS mode supports: | ||
+ | * exchanging data on the bus following the UDS protocol | ||
+ | * logs module answers addresses (Ping mode) | ||
+ | |||
+ | |||
+ | ===== Concept ===== | ||
+ | |||
+ | |||
+ | ==== Initialization ==== | ||
+ | |||
+ | | ||
+ | |||
+ | 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 " | ||
+ | |||
+ | 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: | ||
+ | |||
+ | 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 | ||
+ | |||
+ | | ||
+ | |||
+ | 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' | ||
+ | |||
+ | |||
+ | Steffen Koehler | ||
+ | |||
+ | Phone: +49 172 410 35 98 | ||
+ | |||
+ | EMail: | ||
+ | ===== Appendix ===== | ||
+ | | ||
+ | |||
+ | ===== Full Copyright Statement ===== | ||
+ | |||
+ | |||
+ | Copyright | ||
+ | |||
+ | 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, | ||
+ | |||
+ | 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." | ||
+ | | ||
+ | |||
+ | ===== 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:// |
doc/rfc_canuds-mode.txt · Last modified: 2017/03/18 13:42 by admin