Diese Website verwendet Cookies für Analysen, die Anmeldung im Online-Shop und im Forum sowie die Durchführung einer Bestellung. Durch die Nutzung dieser Website erklären Sie sich mit der Verwendung von Cookies einverstanden. Detaillierte Informationen über deren Einsatz finden Sie in unserer Datenschutzerklärung.

OK Datenschutz

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

2014-08-27 - Version 3.13.0


  • Added support for PCAN-ExpressCard 34
  • Added support for PCAN-PCI Express OEM hardware
  • Hardware parameters CAN_PARAM_FIRMWARE_REVISION and CAN_PARAM_HARDWARE_REVISION can now also be used with with FPGA-based PCIe cards
  • Maximum number of clients (MAX_HCANCLIENT) increased from 32 to 64
  • New possibility to assign a Net to a specific hardware through its Device ID and controller number parameters. On plug-in of a CAN hardware, the Net does not connect to a fixed hardware handle, but searches for a hardware that has the required Device ID and controller number
  • Two new client parameters CAN_PARAM_RCVRTRFRAMES and CAN_PARAM_RCVSTATUSFRAMES to control whether a client receives Remote Request Frames and Status Frames

Bug fixes:

  • Fixes in Acceptance Code & Mask logic: mask is now always limited to 29 bits
  • Configuring the client filter caused unnecessary CAN controller reset cycles in connected hardware, which could affect other clients connected to the same hardware

2012-01-23 - Version 3.8.2

  • Bug fix USB: CAN_PARAM_BUSON cleared listen-only and set filter mode to "dual"
  • Added support for the new PCAN-miniPCIe CAN interface
  • Added SpinLock for FPU access

2011-11-04 - Version 3.7.2

  • Bug fix: An idle USB Pro device infrequently caused errors in PRIME95 and some 3rd party software. Error frequency 1-3 h. Evalution of calibration timestamps involves floating point arithmetic in the driver. The FPU is protected by calls to KeSaveFloatingPointState()/KeRestoreFloatingPointState(). KeSaveFloatingPointState()/KeRestoreFloatingPointState() was called twice, properly nested. Fix: FPU lock moved to locking.c, and usage is limited to only ONE pair of KeSaveFloatingPointState()/KeRestoreFloatingPointState()
  • Bug fix: If a client called CAN_SetClientFilter() for a net it was not connected to, the hardware was always reinitialized. This could result in unintended baud rate changes
  • More parameters for the CAN controller can be set directly and before BUSON: CAN_PARAM_BAUDRATE, CAN_PARAM_LISTEN_ONLY, CAN_PARAM_ERROR_WARNING_LIMIT. These parameters could be read/written with CAN_Set|GetHwParam(). Now these parameters can also be read/written with CAN_Set|GetNetParam(). If these parameters are changed for a hardware, they are also changed for the net. On CAN_ConnectToNet()/BUSON, the CAN controller is initialized with the net parameters. After CAN_DisconnectFromNet() of the last client, the net parameters are reset to their default values. Default values are defined at system start or in CAN_RegisterNet(). CAN_PARAM_BAUDRATE: from Registry,
  • CAN_PARAM_RCVERRFRAMES is set by clients. The effective setting for the hardware can be queried via net parameter CAN_PARAM_RCVERRFRAMES
  • Data length code of CAN messages can be 0..15, but data byte count is only 0..8. For USB, the driver truncated DLC > 8 to 8. Now the received/transmitted DLC is always preserved
  • All drivers: Illegal CAN messages were received on a system with PCAN_USB.SYS and NEC USB 3.0 host controller driver "nusb3xhc.sys". As a result, the 11-bit exact message filter was indexed with id > 0x7ff => BSOD. Now there's an extra test against illegal message IDs
  • Bug fix: CAN_Write() did not test whether client was connected to net (all drivers)
  • Bug fix: If a net was used by another client, the result of CAN_DisconnectFromNet() was the result of _controller_buson_passive(). Now all CAN bus related error bits are cleared in result by "RunAsync_MapResult()" (all drivers)
  • Nicer output of CAN_Msg2Text()
  • USB Pro: If two clients were connected to same net and then one client was disconnected, all message filters were set to "receive all", which caused a hardware reset. Reason: acceptance filter in hardware was detected to change, since changes in unused bits 31..29 occurred. Fixed in _accfilter_register_filter_aux()
  • Bug fix in USB: While going "Stand-by", EvtDeviceD=Exit() could run parallel with PeakUsbDevice__Pipe_CanControllerAll_In_Complete new LOCK "UsbPipeComplete"
  • Bug fix in USB: While going "Stand-by", PeakUsbDevice__Pipe_CanControllerAll_In_Complete() could be called with CANController == NULL (VIPA)

2011-02-07 - Version 3.6.3

  • Bugfix: setting CAN_PARAM_BUSLOAD_SAMPLETIME with device in BUSOFF state now results in CAN_ERR_ILLPARAMVAL
  • Bugfix: arithmetic rounding error in micro_time(), fixed by rearranging levels of parthenteses in macro MULDIV64: CAN_GetSystemTime() was 7-10% slower than KeQueryPerformanceCounter(). Depends on PerformanceFrequency and hardware, error was seen only on Gigabyte G31M-S2L mainboard so far
  • Bugfix USBPRO: if PARAM_HW_DEVICENR was set for 2nd controller, it was not written into EEPROM
  • Bugfix: in CAN controller enumeration, processing of registry keys "Hardware1", "Hardware2", ... was stopped if a gap in the numbers existed. Therefore, e.g. a single "Hardware13" was not processed
  • Bugfix PCCARD: after plug-in, the DC/DC converter needs time to stabilize. New Parameter CAN_PARAM_PCCARD_PLUGIN_DELAY controls this delay. Default value is 200ms. Absolute minimum on IBM ThinkPad R52 was 100ms
  • Bugfix on delayed xmt: parallel execution of SJA1000__hw_activate() (over async _controller_buson_passive(), hw_plugged_in()) and hw_msgwrite() (over WriteDelayedMsg() => WriteMsgNow()). Solution: SJA1000 may not process any hw_buserr(), hw_msgwrite() etc. if ishw_activate_ready is not yet 1

2010-10-12 - Version 3.5.4

  • Bugfix in handling of CAN_PARAM_ONRCV_EVENT_HANDLE
  • PCCARD triggers ISR on surprise removal, which must be terminated by ISRTimeout
  • ISRTIMEOUT is setup now for each device in "devicetypes.js", and is set to maximum of all devices in .inf file "generix.inx"
  • New client parameter CAN_PARAM_DELAYXMTQUEUE_ERR_QXMTFULL_COUNT: Counts ERR_QXMTFULL errors, if sending from DelayXmtQueue fails
  • Bugfix: in _WriteDelayedMsg() a parallel CAN_RemoveClient() could cause BSOD
  • New: PCCARD driver (32-bit)
  • Bugfix: CAN_SetClientParam(rcverrorframes) modifies hardware settings, but Hw->CANController.controllersettings was not copied to Hw->controllersettings because CAN_SetHwParam_complete() was not called
  • Bugfix USB: on some machines flash mode terminated with error. Reason: CAN_InternRead() scheduled an asynchronuos ControlURB, which was run and termianted undelayed, so the WDfRequest was completed before IoCtl was ready. While this is not an error for itself, "buffersize = 16" was set after WdfRequest was already completed, so buffer size was invalid
  • Bugfix USB Pro: Busload data received for second CAN controller received and evaluated BEFORE CAN_registerHardware_intern() completed. BSOD because: Hw->CANController == NULL, but stateDasync already 1 (from 1st controller)

    Solution: Change all "if (pDeviceContext->stateD0_async)" to "if (pDeviceContext->stateD0_async && Hw->installed)"
  • USB Pro: serial number CAN_PARAM_HW_SERNR can also be set now

2010-05-10 - Version 3.4.0

  • Identification of hardware in DriverEvtDeviceAdd() changed from "DevicePropertyDeviceDescription" to "DevicePropertyHardwareID"
  • PCI/ExpressCard: ExpressCard is now recognized by typecode, not by EEPROM pattern testing
  • CAN_RemoveAllMsgs() does no longer evaluate parameter 'hNet'. It is still in the parameter list, for compatibility reasons
  • BSOD on CAN_PARAM_ON_RCV_EVENT_HANDLE: if user set an illegal handle, an internal error message was generated, but handle was still used for KeEventSewt(): BSOD.
    Now the illegal handle is reset to 0, with error CAN_ERR_ILLPARAMVAL
  • USB Pro: Transmitting messages to CANController #1 used the endpoint 2 of controller #0. Now: transmission to controller #1 uses it's own endpoint 3
  • USB Pro: Control of LEDs in adapted to firmware v1.1.1.0
  • New PCAN_VIRTUAL driver type without any hardware support
  • USB Pro: Bug in busload calculation fixed
  • USB Pro: New parameter CAN_PARAM_BUSERRORGENERATION, which can be used to create Error Frames on the CAN bus
  • Release for x64 and x86 platforms

2010-02-11 - Version 3.2.4

  • First release (x64 platforms only)