PEAK-CAN & CAN-FD Device Driver (32/64-bit) Version History

2018-05-11 - Version 4.1.4

Improvements:

New functions for single-channel PCAN-Chip USB modules to get or set the state of 32 digital I/O pins, and to get the value of an analog input. Support for new CAN-API hardware parameters CAN_PARAM_IO_DIGITAL_CONFIG, CAN_PARAM_IO_DIGITAL_VALUE, CAN_PARAM_IO_DIGITAL_SET, CAN_PARAM_IO_DIGITAL_CLEAR, and CAN_PARAM_IO_ANALOG_VALUE
New possibility to configure the CAN FD ISO-mode for a net
Some minor internal improvements

Bug fixes:

CAN-API error code CAN_ERR_QXMTFULL was only returned by CAN_Write calls and not by CAN_GetHardwareStatus
Setting the hardware parameter CAN_PARAM_ERROR_WARNING_LIMIT failed with error code CAN_ERR_ILLPARAMVAL if the hardware was never active since plug-in. Additionally, after the hardware was initialized once, the result CAN_ERR_OK was always returned, even when the hardware was not in use. Now the new error code CAN_ERR_ILLMODE is returned when the hardware is not initialized, and CAN_ERR_OK when the hardware is in use

Improvements:

New feature to create artifical transmit pauses between individual transmit messages with new CAN-API 4 record can_interframespace_pause_t. New client parameter CAN_PARAM_XMT_INTERFRAME_DURATION to enable/disable the feature, capability query with hardware parameter CAN_PARAM_XMT_INTERFRAME_DURATION
Added support for PCAN-PCI/104-Express FD
Added CAN 2.0 A/B tolerance against r0 bit

Bug fixes:

Parameter CAN_PARAM_RCVBUSLOADFRAMES could not be queried for hardware (PCAN-USB Pro FD)
Generation of CAN-API 4 record can_event_fd_error_t only in case of plug-in, not for normal hardware/net checkup
Fixation of hardware handles to specific PCAN-PCI hardware channels via registry keys could fail if more than one multi-channel PCAN-PCI Express card was present in a computer
PCAN-USB X6 enumeration problem if using enabled CAN_PARAM_HW_ENUMERATION_LINEAR option
CAN_DisconnectFromNet() could return error code CAN_ERR_BUSPASSIVE if connected hardware was in error-passive state
Bus load value returned via CAN-API 4 function CAN_GetParam(..., CAN_PARAM_BUSLOAD,...) could be greater than 0 when the hardware was already disconnected
CAN_Status() / CAN_GetHardwareStatus() calls took too much time for newer PCAN-USB adaptors
PCAN-PCI Express FD channels remained bus-on after a connection was terminated

Changes:

For CAN-API 4, parameter CAN_PARAM_BUSLOAD_ENABLE is strictly 0 or 1, and not a sample time for PCAN-USB Pro. No change in CAN-API 2
New net parameter CAN_PARAM_NETHW_PRESET to query the hardware handle that was originally assigned to a net, if the matching hardware is not plugged-in at the moment. Net parameter CAN_PARAM_NETHW has been renamed to CAN_PARAM_NETHW_ACTIVE to better reflect its actual meaning
USB Activate Delay parameter introduced in driver version 2.41.10 in January 2003 no longer has any effect on FPGA-based USB hardware, and for PCAN-USB adaptors the parameter is ignored if the firmware version is greater or equal v8.0

Improvements:

Number of supported hardware handles raised to 64
New CAN-API 4 parameters CAN_PARAM_MAX_HCANHW, CAN_PARAM_MAX_HCANNET, and CAN_PARAM_MAX_HCANCLIENT to query the highest possible handle values for the individual object types from the driver
New CAN-API 4 parameter CAN_PARAM_HW_ENUMERATION_LINEAR to control how hardware handles are enumerated (16..1 and 17..n, or 1..n)

Bug fixes:

When an asynchronous request was cancelled, e.g. by terminating the calling process, the request was not completed internally, which resulted in a deadlock that required the computer to be rebooted
Sending a status message via CAN-API 4 function CAN_Write() (MSGTYPE_STATUS bit set) while the self-receive client option was enabled, subsequently calling CAN_Read() could result in a deadlock
If a message was sent while the self-receive client option and the Delayed Message Distribution hardware option was enabled, on PCAN-PCI or PCAN-PCI-Express hardware the timestamp of the self-received message was 0
Part numbers returned via CAN-API parameter CAN_PARAM_PARTNO were not correct for some hardware types
Number of bytes written returned from CAN-API 4 function CAN_Write() was wrong
Return value of CAN-API 4 function CAN_Write() was not correct when an FD message was sent on a non-FD net
CAN-API 4 function CAN_GetHardwareStatus() always returned CAN_ERR_OK when using a PCAN-PCI Express FD card even when the hardware was in BUSPASSIVE/BUSWARNING state
PCAN_LAN: Changing the hardware bit rate did not update the bit rate of a connected net
PCAN_LAN: CAN controller error states of remote PCAN-Gateways are now communicated from the VPOI service to the device driver
Fixed update of Net<->Hardware settings in various plug-in / disconnect / parameter change scenarios

Improvements:

Under Windows 10 separate catalog files are installed to ensure Windows Hardware Compatibility signatures for the different device drivers, to address driver installation issues with enabled Secure Boot UEFI feature

Bug fixes:

Fixed possible buffer overruns
Calling the CAN-API function CAN_CloseAll() triggered a Blue Screen
CAN_Read() (CAN-API 4): If buffer is too small for first record, now CAN_ERR_RESOURCE is returned instead of CAN_ERR_QRCVEMPTY
CAN_Write() (CAN-API 4): It was possible to send a CAN FD message on a non-FD net (net handle < 33). Now CAN_ERR_ILLARAMVAL is returned

Changes:

Drivers built with Windows Driver Kit 10.0.14393.0
Removed INF entry for PCAN-USB Pro FD flash mode device, which could possibly cause device installation problems

Improvement:

Added support for PCAN-PCI Express FD, PCAN-USB X6, and coming CAN FD interfaces

Bug fixes:

PCAN-LAN: Ghost channel 'PCAN-LAN': Was occurring because a record was overwritten. Communication between driver and service uses now a queue instead of only one record
PCAN-LAN: Querying the bitrate of a LAN channel over CAN_GetHwParam did not work
PCAN-LAN: Bitrate and Listen-only can now be set from the service
Registering an FD net with a net handle smaller than 33 did not return error CAN_ERR_ILLPARAMVAL
Incomplete plug-in procedure was causing to show an invalid abandoned channel

Changes:

Please note: Beginning with this revision, we stopped to support Windows^® Vista.

Improvements:

A client is tied to its creation process and automatically removed when the process ends
Firmware version of POI (PCAN-LAN) can now be read
CAN-API 4 CAN_Write() now returns ERR_ILLPARAMVAL if an invalid timestamp is detected in the buffer

Bug fixes:

USB continuous reader callback was being started too early, causing sometimes a null-pointer exception (Cummins)
FIFO overruns: Client new receives ERR_QOVERRUN as status message
Error code returned from CAN-API 2 CAN_Read() corresponds to status messages, as in 3.x drivers
Setting Listen-only mode for PCAN-LAN was not working properly
Querying the firmware version over CAN-API 2 for PCAN-LAN was not working
An assertion was triggered when checking bitrate data within the debug driver