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

23.01.2012 - 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

 

4.11.2011 - 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_LISTEN_ONLY = 0,
    CAN_PARAM_ERROR_WARNING_LIMIT = 96
  • 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)

 

07.02.2011 - 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

 

12.10.2010 - 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

 

10.05.2010 - 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

 

11.02.2010 - Version 3.2.4

  • First release (x64 platforms only)

Back to Top