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

2022-08-31 - Version 4.3.1

Improvements:

• General code optimizations
• The CAN_PARAM_HARDWARE_TYP parameter can be now queried for PCAN-USB adaptors

Bug fixes:

• No notification about changed hardware parameters CAN_PARAM_TIMESTAMP_SOF, CAN_PARAM_TX_SELF_ACK and CAN_PARAM_BRS_IGNORE were sent to other connected clients
• The PCAN_LAN driver allowed FD connections on non-FD PCAN-LAN channels

Changes:

• The CAN_PARAM_BRS_IGNORE parameter can no longer be queried from non-FD net
  
  

Download Driver Setup

2021-12-13 - Version 4.3.0

Improvements:

• PCAN-USB adaptors with firmware version >= 5.0 report a 3-digit firmware version
• General code enhancements

Bug fixes:

• When a message was sent with both MSGTYPE_SELFRECEIVE and MSGTYPE_HW_SELFRECEIVE flags set, the messages came back twice
• The MSGTYPE_HW_SELFRECEIVE flag could be set in a message received from an internal net and no hardware was involved in the self-receive process
• CAN_ConnectToHardware() does not create a CAN FD connection if nom_* and data_* parameters are specified that have identical values

Changes:

• Drivers are based on the Universal Driver Architecture
• Drivers are based on KMDF version 1.15 instead of v1.9
• Drivers require Windows 10 or higher
  
  

2021-05-04 - Version 4.2.3

Improvements:

• Hardware parameters TIMESTAMP_SOF, TX_SELF_ACK, BRS_IGNORE implemented for PCIe FD cards

Bug fixes:

• By setting the Device-ID of a PCAN-PC/104-Plus Quad card, the card could become inoperable the next time the computer is switched off and on, so that the firmware had to be flashed again
• Querying the hardware parameter CAN_PARAM_BUSERRORGENERATION returned 0 in all fields of the corresponding data structure, even if the parameter was previously set successfully with valid values
• The parameter CAN_PARAM_XMT_INTERFRAME_DURATION was not implemented for PCI-based PCAN hardware
• CAN_ConnectToHardware() could fail with error CAN_ERR_ILLNET if the net name was determined automatically
  
  

2021-01-26 - Version 4.2.2

Improvements:

• Added support for PCAN-Gateway FD devices
• Supports new event that is signaled when the transmit-queue of a client becomes empty
• General code enhancements

Bug fixes:

• Fixed a Blue Screen in PCAN-LAN, where an Access Violation occurred under some scenarios on plug-out events of Virtual Gateway routes
• Fixed a message distribution problem for PCAN-PCI, where a message was kept in the hardware reception queue and was not forwarded to the connected clients
• Fixed a problem where the hardware handles of PCAN-USB X6 hardware were not correctly enumerated
  
  

2020-07-20 - Version 4.2.1

Improvements:

• New CAN-API parameters implemented for PCAN-PCI Express FD and other PCI-based PCAN hardware equipped with flash memory: CAN_PARAM_USER_LOCATION_INFO, CAN_PARAM_OEM_CODE, CAN_PARAM_USERDATA
• New CAN-API parameter PARAM_PROTOCOLS implemented for all drivers
• General code enhancements

Bug fixes:

• The call for activating the bus error generation feature was taking too long
• Wrong CAN FD bit rate in FD hardware: incorrect bit timing parameters were forwarded to the hardware-internal FPGA
• Changing the Device ID of a hardware was causing problems if a PCAN net was bound to the Device ID

Changes:

• When setting a Device ID number greater than the maximum value a hardware supports now returns an error instead of truncating the specified value
• Internal storage of Device IDs in PCI-based PCAN hardware was enhanced to store individual values for different OS (Linux/Windows) without overriding each other
  
  

2019-11-04 - Version 4.2.0

Improvements:

• New possility to set a Device ID for PCI-based PCAN hardware
• New CAN_ConnectToHardware() CAN-API 4 function
• New possibility for FD-capable USB hardware to control the timing of USB IRQs

Bug fixes:

• Backward jumps of timestamps when using PCAN-PCI Express FD with the option CAN_PARAM_DELAYED_MESSAGE_DISTRIBUTION
• A PCAN client received too many Bus-On status messages after establishing a connection with a hardware
• Possible Blue Screen in PCAN-USB driver after waking a computer up from standby mode, if a connection with a PCAN-USB adaptor was active when the computer went into standby and the adaptor has been plugged out before the wake-up
• The Device ID of a multi-channel USB hardware was not correctly set for all hardware channels. Under Linux, each channel could have its own Device ID, but under Windows only the Device ID of the first channel was considered
• Automatic cleanup of orphaned PCAN clients did not work reliably
• Wrong Bus-On event in PCAN-LAN driver after a client was disconnected
• If CAN connect/reset/write was performed in quick succession on USB hardware, a response that was sent very fast from a module on the bus was discarded and could not be received by a client
• If the hardware status of a disconnected PCAN-USB adaptor with firmware version 8.4 was queried, the returned result could be different from CAN_ERR_OK if the hardware was in an error state before it was disconnected

Changes:

• The CAN-API 4 function CAN_RegisterNet() now returns the error CAN_ERR_ILLPARAMVAL if one of the bit rate parameters is not within the valid value range
• Setting the client parameter CAN_PARAM_ONRCV_EVENT_HANDLE returns CAN_ERR_ILLPARAMVAL if the handle is invalid
  
  

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
  
  

2017-09-14 - Version 4.1.3

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
  
  

2017-02-01 - Version 4.1.2

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
  
  

2016-09-13 - Version 4.1.1

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
  
  

2016-05-02 - Version 4.1.0

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:

• Drivers built with Windows Driver Kit 10
• Drivers now have SHA-256 signatures
  
  

2015-11-12 - Version 4.0.18

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
  
  

2015-07-01 - Version 4.0.16

• Bug fix: Binding PCAN nets to specific Device IDs did not work correctly
• Some minor internal improvements
  
  

2015-06-03 - Version 4.0.15

• First release of v4 PCAN drivers
• Support for CAN FD protocol added
• Handling of PCAN-USB Pro FD and PCAN-USB FD interfaces added