PEAK-System Forum

We have a solution working with PEAK-ISO-API v3.0.1.186 with both CAN and CAN-FD.

We just updated to the v3.1.1.227 DLL. The CAN portion still works. The CAN-FD no longer works. We did not change anything on our usage.

None of the APIs are returning errors, but no messages come out on the bus. We have been viewing the lines with a logic analyzer and there isn't any signaling on the CAN lines with this DLL update despite the Write() function returning success. Changing the DLL version back to v3.0.1.186 gives us full communication back.

Below is our initialization string if it is of use (the same is used between both DLLs):

DLL:[Initialize channel USB1: f_clock=80000000,nom_brp=4,nom_tseg1=31,nom_tseg2=8,nom_sjw=8,data_brp=1,data_tseg1=31,data_tseg2=8,data_sjw=8

I did not see a change log where I could see if there was something that changed between versions that needs to be addressed. Any suggestions/ideas?

Thanks,
David

Hello,

Thank you for your request.

To further assess the issue, we'll require some information:

Which Version of the PEAK-Device driver are you currently using?

Which version of the PCANBasic API is used in conjunction with PCAN-ISO TP API?

Best Regards

Marvin

The device driver version is
PCAN_USB 4.2.1.16433
(KMDF 1.9, x64, Desktop)
Copyright (C) 1995-2020 by
PEAK-System Technik GmbH, Darmstadt

We are not using the PCANBasic API. We are just using the PCAN-ISO TP API interface.

Hello,

In fact PCANBasic API is always involved when using the PCAN-ISO TP API,
as the PCAN-ISO TP relys on PCANBasic for the communication to the hardware.

This also mentioned on the product-page for PCAN-ISO TP API:

https://www.peak-system.com/PCAN-ISO-TP ... .html?&L=1

Please test the following:

Is this issue replicable using the latest driver package?

https://www.peak-system.com/quick/DrvSetup

Please make sure to check the "PCANbasic" option during installation:

: PCANBasic option during driver installation; SetupPcanBasic.png (28.88 KiB) Viewed 6120 times

Please report back to us with your findings.

Best Regards

Marvin

Marvin,

I updated the PCANBasic API to 4.2.2 as suggested in your post. No change in behavior.

CAN + ISO-API v3.0.1.186 = works
CAN + ISO-API v3.1.1.227 = works
CAN-FD + ISO-API v3.0.1.186 = works
CAN-FD + ISO-API v3.1.1.227 = does not work

Thanks,
David

Hello David,

In your application, can you globally enable debug message by calling function CANTP_SetValue_2016 with PCANTP_PARAMETER_DEBUG before any initialization?
Here is a C++ sample:

Code: Select all

		
		uint8_t buf;
		// set debug mode
		buf = PCANTP_VALUE_PARAMETER_ON;
		sts = CANTP_SetValue_2016(PCANTP_HANDLE_NONEBUS, PCANTP_PARAMETER_DEBUG, &buf, sizeof(buf));

The goal is to see if the generated log (PCANBasic.log) contains any ERROR messages and compare it with the returned statuses of the API calls.
The API seems to return OK when it should be an error status.

With this switch enabled I can see that the SetMapping() function is reporting an invalid mapping where it was valid in the last version. The function is properly reporting "KO". When we mapped the status returns of the functions to the UI console this function didn't get remapped and it was still printing to STDOUT instead of the UI console so the bad return was missed.

We'll look into our mapping settings. Are you aware of what might have changed with the map settings between these two versions of the driver that might narrow down our search?

Either way, this debug print has greatly helped us figure out how to move forward. Thank you!

David

I've traced it back to when we try to set the TXDL length of the mapping to 64 bytes in CAN-FD mode. If I don't touch the TXDL in mapping object it defaults to 8 and works, but transmits at 8 bytes. If I set the TXDL to 64 it fails to set the mapping with the latest driver (worked with the last driver version).

I have verified on the traces with the pcanview that the FD and BRS bits are set so 64 should be a valid TXDL as we are in CAN-FD mode when we are transmitting. The message type we are setting in our mapping is 0x0C (STANDARD | FD| BRS).

We have matched all other fields of the mapping to your examples to make sure we didn't make a logical error.

Here are the settings that "work" in CAN-FD mode, but transmit at 8 bytes only. The TXDL is not touched and 0 by default.

Code: Select all

[FINEST] 00:01:13.852 >
   DLL:[Set mapping: can_id=a1, flow_ctrl=a2, msgtype=c, txdl=0, ext_addr=0, format=1, isotp_msgtype=1, src=f1, dest=1, dest_type=1
, Add a simple mapping on channel USB1: OK

Here is the non-working when we set the TXDL to 64. This is the only line of code we changed, to set the TXDL length to 64, resulting in KO:

Code: Select all

[FINEST] 00:03:48.215 >
   DLL:[Set mapping: can_id=a1, flow_ctrl=a2, msgtype=c, txdl=64, ext_addr=0, format=1, isotp_msgtype=1, src=f1, dest=1, dest_type=1
, Add a simple mapping on channel USB1: KO

Thanks,
David

Hello David,

The field in cantp_mapping is can_tx_dlc: the value must be a valid DLC (and not a length), so you should change your value from 64 to 0x0F.

Fabrice,

Thank you for your patience. We always use TXDL in our software so even though this field is clearly DLC and not TXDL, we read it as TXDL. You are correct. Converting the TXDL to the DLC makes this work for the current and previous version of the driver for all valid lengths.

Thank you for helping us find our issue.

David

PEAK-System Forum

Issues with PEAK-ISO-API v3.1.1.227 with CAN-FD

Issues with PEAK-ISO-API v3.1.1.227 with CAN-FD

Re: Issues with PEAK-ISO-API v3.1.1.227 with CAN-FD

Re: Issues with PEAK-ISO-API v3.1.1.227 with CAN-FD

Re: Issues with PEAK-ISO-API v3.1.1.227 with CAN-FD

Re: Issues with PEAK-ISO-API v3.1.1.227 with CAN-FD

Re: Issues with PEAK-ISO-API v3.1.1.227 with CAN-FD

Re: Issues with PEAK-ISO-API v3.1.1.227 with CAN-FD

Re: Issues with PEAK-ISO-API v3.1.1.227 with CAN-FD

Re: Issues with PEAK-ISO-API v3.1.1.227 with CAN-FD

Re: Issues with PEAK-ISO-API v3.1.1.227 with CAN-FD