PEAK-System Forum

Recently, I am starting to use your company PEAK-USB product.
We use the PEAK-USB to issue command from PC window 64bit to a STM32 MCU who have already been
implemented the ISO-TP protocol that supports up to 4096 data transfer.
As long as our MCU powers up, our MCU actively send "Rdy" CAN message to PC side( PCAN-ISO-TP.)
but PCAN-ISO-TP (Using C# Example) never receive any message from MCU side, I use Visual studio 2017 to
debug the PCAN-ISO-TP(c#), it always get the "PCANTP_ERROR_NO_MESSAGE"
but When I use the PCAN-View, I can get the CAN message from MCU. also I can issue command
and get some feedback
BUT I don't want to use PCAN-view, because it can not support up to 4096 bytes data.

Could help me why the PCAN-ISO-TP does NOT work?
and I have another question is that
I just want to use the PCAN-ISO-TP to issue some commands from PC to MCU and get some data from MCU.

But it seems PCAN-ISO-TP force us to do the Address Mapping(source address, target address, CAN_ID response).
I really don't know what is the source address and target address. I just know only the CAN ID.
How can we skip the Address mapping? i just want to only do simple read and write with CAN_I which is similar to PCAN-View but support up 4096 bytes.

Hello,

xenos wrote:As long as our MCU powers up, our MCU actively send "Rdy" CAN message to PC side( PCAN-ISO-TP.)
but PCAN-ISO-TP (Using C# Example) never receive any message from MCU side, I use Visual studio 2017 to
debug the PCAN-ISO-TP(c#), it always get the "PCANTP_ERROR_NO_MESSAGE"

You have to define address mappings to be able to receive messages

xenos wrote:also I can issue command
and get some feedback
BUT I don't want to use PCAN-view, because it can not support up to 4096 bytes data.

PCAN-View is a "raw CAN viewer application", i.e. with no support for high CAN layer protocols.

xenos wrote:But it seems PCAN-ISO-TP force us to do the Address Mapping(source address, target address, CAN_ID response).

Yes, since this is part of the protocol

xenos wrote:I really don't know what is the source address and target address. I just know only the CAN ID.
How can we skip the Address mapping? i just want to only do simple read and write with CAN_I which is similar to PCAN-View but support up 4096 bytes.

The source/target addresses are used to tie the CAN-IDs with a "direction" (sender->receiver, receiver->sender). You need to define two (2) address mapping (one for each direction) using the CAN-IDs you need, one address as source, and another as target. In this way the API is able to get, decode, and process the messages.

For instance, if your application uses the ID 310h for sending, then it will use the ID 300h for receiving. You may use for your application as Source-Address 1 and for the ECU, 2. In this way, the mappings would be as follow:

Hello,

Also should you want to send a "simple write command", you can find how to transmit a standard CAN message in the documentation page 29, §3.5.8.
But as Mr Wagner described, the configuration of mappings is the way to solve your issue.

Note: To send an unsegmented CAN message with PCAN-ISO-TP API, the FORMAT member of a
TPCANTPMsg must be set with the value PCANTP_FORMAT_NONE.
Since the ISO-TP message structure doesn’t contain a field to define the CAN ID, it must be stored in the
four first bytes of the DATA structure (Fourth byte corresponds to the Least Significant Byte).

The following C++ example shows how to transmit a standard CAN message with ISO-TP:

Code: Select all

TPCANTPMsg msg;
int i, idx;
memset(&msg, 0, sizeof(msg));
msg.FORMAT = PCANTP_FORMAT_NONE;
msg.MSGTYPE = PCANTP_MESSAGE_UNKNOWN;
msg.TA_TYPE = PCANTP_ADDRESSING_UNKNOWN;
msg.IDTYPE = PCANTP_ID_CAN_29BIT;
// Sending CAN frame with CAN ID : 0x3FAB0123.
idx = 0;
msg.DATA[idx++] = 0x3F;
msg.DATA[idx++] = 0xAB;
msg.DATA[idx++] = 0x01;
msg.DATA[idx++] = 0x23;
// Initialize CAN DATA.
msg.LEN = idx + 8;
for (i = idx; i < msg.LEN; i++) {
    msg.DATA[i] = 0xA1 + i;
}
// Transmit message.
sts = CANTP_Write(channel, &msg);
if (sts == PCANTP_ERROR_OK) {
    // Message added to transmit queue.
}

Also if you wish to receive standard CAN messages (max. size 8) via PCAN-ISO-TP, you need to set the parameter PCANTP_PARAM_CAN_UNSEGMENTED to PCANTP_CAN_UNSEGMENTED_ON. See the documentation §3.5.11, p.38:

PCANTP_PARAM_CAN_UNSEGMENTED
Description: This parameter is used to define how the API will handle non ISO-TP messages. The default
behavior is PCANTP_CAN_UNSEGMENTED_OFF: all non ISO-TP CAN message will be discarded. If
PCANTP_CAN_UNSEGMENTED_ON is set then non ISO-TP messages can be read with the ISO-TP read
function.
Finally, if the parameter is set to PCANTP_CAN_UNSEGMENTED_ALL_FRAMES then the receive queue
will contain ISO-TP messages, non ISO-TP messages, and all the segmented frames of an ISO-TP
message, it is recommended to use this mode for debugging purpose only.
Possible values: PCANTP_CAN_UNSEGMENTED_OFF, PCANTP_CAN_UNSEGMENTED_ON,
PCANTP_CAN_UNSEGMENTED_ALL_FRAMES.
Default value: 0x00 (PCANTP_CAN_UNSEGMENTED_OFF).
PCAN-Device: All PCAN devices (excluding PCANTP_NONEBUS channel).
See also: Parameter Value Defintions on page 106.

Hello ,
Thank you for your great support so that right now I got these problems fixed.
but there is another problem.
I found the timestamp of each messages are disorder. it seems they don't come out in a time sequence.
When I send the command "AT+GMM", I should get:
AT+GMM
BG96
OK

But I got:
OK
AT+GMM
BG96

I just added below sentences in the readMessage() member function in your PCAN ISO-TP C# Example. I just display them on Text Area after CanTpApi.Read(m_pctpHandle, out msg, out ts);

I think the timestamp along with message should comes out in a time sequence other than disorder.
What happened?

Hello,

In order to understand what exactly is your context and problem, could you confirm the following statements:

0. Your application is using the adress 0xF1 for ISO-TP communication and an ECU on the CAN bus is using 0x13.
1. You're sending an ISO-TP message from 0xF1 to 0x13 corresponding to what you call a command "AT+GMM" ?
2. You then receive an ISO-TP confirmation (from 0xF1 to 0x13) stating your message "AT+GMM" is physically transmitted. This is what I understand as your "OK" message.
3. Next an ECU responds and you receive an ISO-TP indication (from 0x13 to 0xF1) stating you are receiving a segmented message. Is it what you call "BG96"?
4. Finally you receive the full ISO-TP message (from 0x13 to 0xF1). Still "BG96"?

I'm not sure what you mean by your "OK" message. Do you expect the request's confirmation to be received after the response of the ECU?
Also, please be aware that the indication messages may not always be fetched if your application slowly polls the receive queue: if a segmented message is fully received (i.e. it awaits to be fetched by the API user) and the message indication has not yet been fetched, then that indication message will be discarded.

In order to get clear, you can enable PCANBasic trace features through PCAN-ISO-TP by adding the following code after you call CanTpApi.Initialize. FYI, the parameter value 0x14 and 0x12 are from PCANBasic.cs library, I just used the raw value so that you don't have to include that file.
It will output all the CAN frames in a .TRC file. You can then submit it here, so that I can analyze the CAN trafic.

F.Vergnaud wrote: 0. Your application is using the adress 0xF1 for ISO-TP communication and an ECU on the CAN bus is using 0x13.

Yes. but it is NOT ECU, it is my MCU. We used ISO-TP application to commnucate with MCU.

F.Vergnaud wrote: 1. You're sending an ISO-TP message from 0xF1 to 0x13 corresponding to what you call a command "AT+GMM" ?

Yes

F.Vergnaud wrote: 2. You then receive an ISO-TP confirmation (from 0xF1 to 0x13) stating your message "AT+GMM" is physically transmitted. This is what I understand as your "OK" message.

No, I do NOT use the confirmation as a "OK" message. I totally ignore the confirmation.
But I read the "DIAGNOSTIC" message

F.Vergnaud wrote: 3. Next an ECU responds and you receive an ISO-TP indication (from 0x13 to 0xF1) stating you are receiving a segmented message. Is it what you call "BG96"?

No, I received a segmented message from my MCU , This message is consisted of 3 lines.
AT+GMM
BG96
OK

F.Vergnaud wrote: 4. Finally you receive the full ISO-TP message (from 0x13 to 0xF1). Still "BG96"?

Finally it must be:
AT+GMM
BG96
OK

but sometimes I got the wrong sequence message:
OK
AT+GMM
BG96

the "OK" goes to the beginning, it must be the end of message.
you can check my attached picture for the timestamp.

F.Vergnaud wrote: I'm not sure what you mean by your "OK" message. Do you expect the request's confirmation to be received after the response of the ECU?

I never expect the request's confirmation. but I expect the "DIAGNOSTIC" message.

F.Vergnaud wrote: Also, please be aware that the indication messages may not always be fetched if your application slowly polls the receive queue: if a segmented message is fully received (i.e. it awaits to be fetched by the API user) and the message indication has not yet been fetched, then that indication message will be discarded.

In order to get clear, you can enable PCANBasic trace features through PCAN-ISO-TP by adding the following code after you call CanTpApi.Initialize. FYI, the parameter value 0x14 and 0x12 are from PCANBasic.cs library, I just used the raw value so that you don't have to include that file.
It will output all the CAN frames in a .TRC file. You can then submit it here, so that I can analyze the CAN trafic.

Robin: I will do it later.