From e69df3d913f8ca3a96f3b7a12c9bd7e9462d5c2c Mon Sep 17 00:00:00 2001 From: Jessy Diamond Exum Date: Mon, 9 Oct 2017 00:07:47 -0700 Subject: [PATCH] J2534_WIN: Added missing docs. Current implementation is wrong. --- drivers/windows/docs/other notes.txt | 35 ++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/drivers/windows/docs/other notes.txt b/drivers/windows/docs/other notes.txt index 12a2553..a066d26 100644 --- a/drivers/windows/docs/other notes.txt +++ b/drivers/windows/docs/other notes.txt @@ -191,6 +191,41 @@ DLL using the Win32 Registry mechanism described in this section. +A.1 Flow Control Overview +ISO 15765-2 was designed to send blocks of up to 4095 bytes on top of the limited 8-byte payload of raw +CAN frames. If the data is small enough, it can fit in a single frame and be transmitted like a raw CAN +message with additional headers. Otherwise, the block is broken up into segments and becomes a +segmented transmission, generating CAN frames in both directions. For flexibility, the receiver of the +segments can control the rate at which the segments are sent. + +Each transmission is actually part of a conversation between two nodes. There is no discovery +mechanism for conversation partners. Therefore, each desired conversation must be pre-defined on each +side before the conversation can start. Conversations are symmetric, meaning that either side can send a +block of data to the other. A conversation can only have one transfer (in one direction) in progress at a +time. One transfer must complete before the next transfer (in the same or in a different direction) can +start. The device must support multiple transfers at once, as long as each one is part of a different +conversation. Raw CAN frames are not allowed when using ISO15765-2. + +A key feature of a conversation is that each side has a unique CAN ID, and each side uses their unique +CAN ID for all transmissions during the conversation. No other CAN IDs are part of the conversation. +Even though the useful data is only flowing in one direction, both sides are transmitting. One side is +sending the flow control message to pace the segments of data coming from the other side. + +For example, during OBD communication, a pass-thru device and an ECU might have a conversation. +The pass-thru device will use the "Tester1" physical CAN ID ($241), and the first ECU will use the +"ECU1" physical CAN ID ($641). During a multi-segment transfer, both sides will be transmitting using +only their respective IDs. It does not matter if the data is being sent by the ECU or by the Tester, the IDs +remain the same. + +It is important to understand the difference between OBD Requests/Responses and ISO 15765-2 +transfers. The OBD Request is transmitted from the Tester to the ECU using functional addressing. +Because segmented transfer is not possible on functional addresses, the message must fit in a single +frame. The OBD Response is a message from the ECU to the Tester using physical addressing. Unlike +other protocols, the responses are not sequential. In fact, the responses can overlap, as if each ECU +were having a private conversation with the Tester. Some of the responses may fit in a single frame, +while others will require a segmented transfer from the ECU to the tester. + + A.2 Transmitting a Segmented Message When PassThruWrite is called, the API will search the list of flow control filters, looking for a pFlowControlMsg that matches the CAN ID (and possible extended address) of the message being sent.