Follow Up to "Sending Basic Packet with Flow Control"

[Just4242]

I have a follow-up to Sending Basic Packet with Flow Control (viewtopic.php?f=181&t=6230).

I have been trying to actually test out my HW with this and I am running in to an issue that I did not notice before since I was not testing for it.

In my system I have an CAN device which will loop back the data received by the device back to the sender(PC-USB1 Peak), EXCEPT that it will increment each character by 1. So if I send out "Peak", I would expect,"Qfbl" to come back. This is a simple way to modify the data and to make sure I am reading the correct data when doing loopback. My device is also sending data with msg_id "0xA1" and flow control with "0xA2". This can be seen in the lower right hand corner of the attached picture.

When I use the file that was attached to the thread(Sending Basic Packet with Flow Control), "client_ISO15765-2_normal_addressing.cpp", attached as well, the data in the rx_msg contains the original data in tx_msg ("PEAK-System - PCAN-ISO-TP Sample") and not the data that is on the bus. I ran into this issue when trying to use example "isotp_segmented_read_write.cpp", after I converted it to use my simple loopback device. In debugging, I re-ran the same test with the simple project that was posted in the previous thread ("client_ISO15765-2_normal_addressing.cpp") which has the exact same failure mode. In the attached image I tried to include all of the key data structures and the values.

In the attached picture, you can see the data being sent back to the Peak from the device has been modified by incrementing each character by 1.

The console log is

Code: Select all

PCAN-ISO-TP API Version: 3.0.1.186
Initialize: OK
Set STMIN = 600us: OK
Allocate tx message: OK
Add a simple mapping: OK
Add a simple mapping: OK
Initialize tx message: OK
Write "PEAK" message: OK
CANTP_Read_2016 (indication): OK, netstatus=00
CANTP_Read_2016 (complete): OK, netstatus=00

I have also noticed that the rx_msg contains data even if I don't loop the data back.

I have spent over a day on this and I don't know how to proceed. Do you have any suggestions?

Ken

[Just4242]

After debugging, this also seems to have something to do with the event's always returning true after the first transmission. After that the call "WaitForSingleObject(receive_event, 1000);" always returns true.

[K.Wagner]

Hello,

as far as I understand, it works as expected. Please note that what you see is the normal ISO 15765 messaging mechanism. When a (large) message is sent, a sending-indication is received; then, in case of success, a sent-confirmation is received, which actually is a copy of the message sent. This is what is shown in the example attached in the mentioned forum topic - please, check the ISO 15765 documentation.

If you want to actively read, then you need a loop for calling CANTP_Read_2016 (normally, this is done in a thread). In there you need to check for messages in the queue while this is not empty. In case a large message is being received, you will get a read-indication. You can then either wait until it is fully received, or just keep pooling the queue in generic form and show all messages you get. Code waiting for a large message to complete can be seen in the example "06_isotp_segmented_read_write":

Code: Select all

...

// Wait receive event and get a message
if (CANTP_StatusIsOk_2016(res, PCANTP_STATUS_OK, false) && receive_event != NULL) 
{
    wait_result = WaitForSingleObject(receive_event, 100);
	// If we receive something, read the message
	if (wait_result == WAIT_OBJECT_0) 
    {
        res |= CANTP_Read_2016(handle, msg_buffer, NULL, PCANTP_MSGTYPE_NONE);
        printf("Wait a message on %s: %s\n", cantp_handle_toShortString(handle), STATUS_OK_KO(res));

		// Check if the message is totaly received (only in ISOTP mode)
		if (CANTP_StatusIsOk_2016(res, PCANTP_STATUS_OK, false)
			&& (PCANTP_MSGTYPE_ISOTP & msg_buffer->type) > 0
			&& ((msg_buffer->msgdata.isotp->netaddrinfo.msgtype & PCANTP_ISOTP_MSGTYPE_FLAG_INDICATION_RX) == PCANTP_ISOTP_MSGTYPE_FLAG_INDICATION_RX)) 
        {
            // The message is being received, wait and show progress
			do {
                Sleep(300);
				res |= CANTP_GetMsgProgress_2016(handle, msg_buffer, PCANTP_MSGDIRECTION_RX, &progress);
				printf("RX Progress on %s = %d%%: %s\n", cantp_handle_toShortString(handle), progress.percentage, STATUS_OK_KO(res));
			} while (progress.state == PCANTP_MSGPROGRESS_STATE_PROCESSING);

			// The message is received, read it
			res |= CANTP_Read_2016(handle, msg_buffer, NULL, PCANTP_MSGTYPE_NONE);
		}
	}
}

...

Note that the example wait explicitly for one large message which was sent by itself (demo send/receive). In normal case you need a loop for reading all messages, as stated before.

[Just4242]

I think I may have this working now. Since I am new to this I did not understand the details of the spec or SW, did not understand I will always get this confirmation request after sending a command that needs to be cleared before I can read the response from the device I just queried with the command. So conceptually, I was expecting the flow to be TX Event, RX Event. But it's actually TX Event, RX Event, RX Event.

[PEAK-Support]

We could not explain High Layer Protocols in Detail for new users. When you use a High Layer protocol, you need know how this work in detail.
For the ISO 15765-2 we recommend to buy and read the official documents - this is a must if you want to work with this Tools. --> https://www.iso.org/standard/66574.html

Here some simple basics:
ISO-TP is a transport protocol defined in the ISO-Standard ISO15765-2 Road vehicles - Diagnostic communication over Controller Area Network (DoCAN)
Part2: Transport protocol and network layer services. As its name already implies, it is originally designed, and still used in road vehicle diagnostic over Controller Area Networks.
Nevertheless, it’s not limited to applications in road vehicles or the automotive domain.

This transport protocol extends the limited payload data size for classical CAN (8 bytes) and CAN-FD (64 bytes) to theoretically four gigabytes.
Additionally, it adds a flow control mechanism to influence the sender’s behavior. ISO-TP segments packets into small fragments depending on the payload size of the CAN frame.
The header of those segments is called Protocol Control Information (PCI).

Packets smaller or equal to seven bytes on Classical CAN are called single-frames (SF). They don’t need to fragment and do not have any flow-control.

Packets larger than that are segmented into a first-frame (FF) and as many consecutive-frames as required.
The FF contains information about the length of the entire payload data and additionally, the first few bytes of payload data.
The receiving peer sends back a flow-control-frame (FC) to either deny, postpone, or accept the following consecutive frames.
The FC also defines the conditions of sending, namely the block-size (BS) and the minimum separation time between frames (STmin).
The block size defines how many CF the sender is allowed to send, before he has to wait for another FC.

ISO-TP.JPG (28.57 KiB) Viewed 6248 times

( quelle: The Zephyr Project)

[Just4242]

The question I have is when will I get the LOOPBACK type of RX Events? After each Frame? Or just on the completion of the entire transfer? Now that I have the basics working I am trying to clean up my higher level SW architecture which is pretty basic right now.

[PEAK-Support]

As we wrote - please study the ISO 15765

See answer from Keneth:

When a (large) message is sent, a sending-indication is received; then, in case of success, a sent-confirmation is received, which actually is a copy of the message that was sent.
This is what is shown in the example attached in the mentioned forum topic - please, check the ISO 15765 documentation.

Pleas understand that we could deliver the Tools, but we could not deliver the knowledge. If you use such a protocol you need to know the specification and use the ISO 15765 documents.

*topic locked*