PCAN-USB Duplicate Frames: A USB Fault, Not CAN Echo

A CANopen SDO block transfer running at 30 KB/s payload, roughly 600 kbit/s of a 1 Mbit/s bus, ends with the last 40 frames appearing a second time, then again every second or so until the connector is pulled. The application aborts on the unexpected frames. Nothing on the wire changed. The fault is upstream of the CAN controller, in the USB transport between the adapter and the host, and the log itself proves it before any instrument is connected.

Duplicate-Frame Signature in the Trace

Read the timestamps first. In the captured segment the replay starts at a timestamp earlier than the frame printed above it:

170) 46070.8 Rx 0609 8 A1 00 00 00 00 00 00 00   <- transfer complete
171) 46372.7 Rx 0701 1 7F
172) 46767.0 Rx 0709 1 7F
173) 46050.5 Rx 0589 8 3B 44 45 46 47 48 49 4A   <- replay begins, t < line 172
174) 46050.6 Rx 0589 8 3C 4B 4C 4D 4E 4F 50 51
175) 46050.7 Rx 0589 8 3D 52 53 54 55 61 62 63

PCAN-USB stamps each received frame in the adapter, before the frame is packed into a USB bulk transfer. A timestamp that runs backwards therefore cannot be a second transmission on the CAN bus and cannot be generated by the receiving application. It is the same block of adapter-stamped data delivered to the host twice. The ~40-frame batch size matches the number of CAN frames that fit in the adapter's IN-endpoint buffering, which is the granularity at which a replay would occur.

One more discriminator, available for free on the requesting node: on that machine the echo contains only received frames, never the frames the application transmitted. A CAN-layer echo or a wiring reflection would repeat whatever was on the wire. A replayed device-to-host buffer repeats only the receive path. Do not move on until the trace shows both markers — backwards timestamp and RX-only content — because they together fix the fault location.

Bus-Side Confirmation with a Scope

Confirm on the differential pair before touching the PC.

1. Capture a window that spans the end of the block transfer and the first replay burst.
2. Match every logged frame to a bit-level burst on the pair. Heartbeats (, ) are convenient reference points because they arrive on a fixed period.
3. Verify that the replayed frames have no corresponding voltage activity.
4. On Linux, read the controller counters in the same window: ip -details -statistics link show can0. Error-warning, error-passive and bus-off counts staying at zero rules out a physical layer that is retransmitting after arbitration or ACK errors.

When the scope is quiet during the replay, the CAN segment, termination and the remote node are cleared. Two different adapters — order numbers IPEH-002022 and IPEH-002021 — reproducing the same behaviour clears the adapter hardware as well.

Observation-to-Cause Map

The dmesg lines are the load-bearing evidence. Enumeration failures on the port hosting the adapter mean the host controller is losing and re-attempting the device link while the application still holds the interface open. The queued IN transfer is re-issued against a buffer that was never acknowledged as consumed, and the same frames arrive again — with their original adapter timestamps — once per retry interval.

Host Controller and Port Topology Check

Establish exactly which controller the adapter is attached to. USB 3.0 xHCI host controllers with out-of-date BIOS or driver revisions are the dominant cause of intermittent enumeration failures for full-speed devices such as PCAN-USB.

1. Linux: lsusb -t. Read the branch containing the PEAK device and note the driver bound to the root hub — xhci_hcd is USB 3.0, ehci-pci or uhci_hcd is USB 2.0 or lower. Confirm the device is listed at 12M.
2. Linux: cat /proc/pcan to confirm the PEAK driver enumerated the channel, and dmesg -w in a second terminal for live enumeration errors during the transfer.
3. Windows: Device Manager > View > Devices by connection. Walk the tree from the PCAN-USB entry up to the root hub and record whether it is an xHCI or an EHCI controller.
4. Note every intermediate hub. An external hub between adapter and host adds a link that can drop independently and must be removed from the test path.

Do not proceed with driver-level debugging until this topology is written down. The versions already in use — Linux driver 7.8 with SocketCAN sources at SVN rev 1277, and PCAN-View 3.2 on Windows driver 3.8 — are current, so the remaining variable is the host controller, not the PEAK software stack.

BIOS and USB Host Driver Update

If the adapter sits on an xHCI controller, update in this order and re-test after each step so the change that fixes it is identifiable:

1. Flash the latest system BIOS/UEFI from the PC or mainboard vendor. xHCI initialisation and port-routing fixes ship in BIOS, not in the OS driver.
2. Install the chipset-vendor USB 3.0 host controller driver rather than the generic in-box driver on Windows. On Linux, move to a kernel with a current xhci_hcd; the Ubuntu 12.04 kernel line predates a large number of xHCI stability fixes.
3. Re-run the block transfer and watch dmesg -w. The check that matters is the absence of new enumeration lines, not the absence of duplicates in a short run.

PEAK-System publishes guidance specifically on USB 3.0 host behaviour with these adapters; treat a BIOS or host driver update as mandatory before escalating.

Fallback to a USB 2.0 Port and Power Management

If enumeration errors survive the updates, move the adapter to a native USB 2.0 port on the same machine — a port that resolves to an EHCI/UHCI controller in the topology dump, not a USB 3.0 port operating a device at full speed. Connect it directly, with no hub, using a short cable.

While the port is being changed, close the second common path to a dropped link — host-initiated suspend:

Re-run the transfer with dmesg open. Enumeration errors that disappear on the USB 2.0 port and return on the USB 3.0 port confirm the host controller as the fault, and the port assignment becomes a documented commissioning requirement for that machine.

Virtual Machine Passthrough Exclusion

The Windows VM that reproduces the fault on a single ~100-frame transfer is not a more sensitive test rig, it is a different transport. USB passthrough serialises every transfer through the hypervisor's virtual host controller, adding latency and jitter to transfer completion and shortening the window before the queued IN transfer is retried. Bench-qualify on bare metal only. If the deployed application must run inside a VM, the qualification has to be repeated there after the host-side fixes, and the VM's USB controller must be set to the generation that matches the physical port in use.

Load Ramp and Application-Layer Guard

Rebuild margin on the CAN side while the host fix is being validated, so a single marginal transfer does not stop the machine:

1. Repeat the block transfer at reduced offered load — lower the block size, insert inter-block delay, or drop the bit rate — and record the bus load at which duplicates first appear. This gives a quantified margin instead of pass/fail.
2. In the SDO client, validate the block sequence number in the first data byte before consuming a segment. In the captured trace the replayed frames carry sequence values , , , — already-consumed numbers that a correct client rejects rather than treats as protocol violations.
3. Reject any received frame whose adapter timestamp is older than the last accepted frame on the same channel. A monotonic-timestamp filter drops an entire replayed batch at the driver boundary and costs one comparison per frame.
4. Keep both guards enabled in production. They convert a host USB glitch into a logged anomaly instead of an aborted transfer.

End-to-End Verification

Qualify the repaired setup against the same case that broke it, at full rate, with the guards temporarily instrumented to count rather than silently discard.

1. Connect the adapter to the qualified port, no hub, and confirm with lsusb -t or Device Manager by connection that the topology is the one you tested.
2. Open dmesg -w on Linux, or the Windows event log filtered on USB sources, for the whole run.
3. Start a continuous capture: candump -ta any, or the PCAN-View trace with timestamps in absolute mode.
4. Post-process the capture for any timestamp that decreases relative to its predecessor on the same channel, and for any repeated sequence number within a block. Both counts must be zero.
5. Confirm zero new unable to enumerate USB device lines and zero increments in error-warning, error-passive or bus-off counters from ip -details -statistics link show can0.
6. If enumeration errors persist after BIOS, host driver and USB 2.0 port testing, package the topology dump, the dmesg extract, the driver and PCAN-View versions, the adapter order numbers and a raw trace containing a replay, and open a case with PEAK-System technical support at [email protected].

Frequently Asked Questions