Troubleshooting LIN Slave Frame Loss on PCAN-USB Pro FD

Problem Details

Symptom: a LIN slave node configured on a PEAK PCAN-USB Pro FD channel never receives a frame. The application reports no RX events, no header, no response — nothing on the wire. The engineer's first assumption is usually a software fault: wrong driver, wrong baud rate, wrong schedule table, or a broken master transmit path.

The reported environment in this case:

The decisive diagnostic data point: the same setup also fails under Windows with PLIN-View Pro. PLIN-View Pro is the vendor's own reference tool running on the vendor's own driver stack. When a fault reproduces identically across two independent OS/driver stacks with the same cabling, the defect is below the software layer — it is physical layer or supply.

Root Cause: Unpowered LIN Transceiver

LIN is a single-wire bus referenced to the node supply. The bus recessive level is pulled to V_BAT through the master's pull-up; a dominant level is a transistor pulling the line toward ground. The PC interface's LIN transceiver therefore cannot generate a valid recessive level, and cannot bias its receiver comparator thresholds, without an external supply voltage fed into the D-Sub connector. USB bus power runs the interface logic and the USB side — it does not power the LIN transceiver.

Consequence when V_BAT is absent:

• The master channel accepts the transmit request from the API and reports success — the frame is queued and clocked out of the protocol controller.
• No usable differential swing appears on the LIN wire, so the slave sees no break/sync/PID sequence.
• Application-level symptoms look exactly like "master never sent anything," which sends engineers down a software rabbit hole.

The PCAN-USB Pro FD user manual documents the LIN power supply requirement in its connector/power section (page 12 in the referenced revision). Read the manual page for your hardware revision and confirm the required voltage range and pin function before applying power.

Solution: D-Sub Pin Assignment and Wiring

Pin functions confirmed for the LIN channel on this interface family:

Ground pin question, answered: pins 5 and 6 are both ground. Connect one of them. There is no functional difference between them, and tying both changes nothing electrically. The vendor's LIN connection cable uses pin 5, so pin 5 is the safe default if you want to match standard accessories.

Commissioning sequence:

1. Power down the external supply and unplug the interface from USB.
2. Wire pin 4 to the LIN bus wire; wire pin 5 (or pin 6) to the common ground shared by the external supply and the LIN device under test.
3. Wire pin 9 to the positive output of the external supply, at the voltage stated in the user manual.
4. Verify with a DMM before connecting the D-Sub: measure supply-to-ground polarity and magnitude at the connector shell end of the harness.
5. Apply external supply first, then plug in USB, then start the application.

Verification

Verify in this order — each step isolates one layer.

1. Static line level. With the supply on and no traffic, measure pin 4 to ground. The line must sit at the recessive level, i.e. close to the applied V_BAT. A reading near 0 V means the pull-up path or the supply is missing; a floating/indeterminate reading means the ground is not common.
2. Master transmit, scope. Run the master schedule and capture pin 4 with an oscilloscope, ground clip on pin 5/6. You should see the break field (dominant > 13 bit times), the 0x55 sync byte, then the protected identifier. If the scope shows clean framing, the physical layer is proven and any remaining fault is protocol-level.
3. Vendor tool, Windows. Repeat with PLIN-View Pro. Confirm the master emits headers and the slave publishes a response. This is the baseline: do not move to the Linux application until this passes.
4. Linux application. Only after step 3 passes, re-run on the Linux host. Confirm the interface enumerates, the LIN channel opens at the intended baud rate, and RX events arrive.
5. Bit timing sanity. Measure one bit period on the scope and compare against the configured baud rate. A mismatch here points to a configuration error, not a wiring error.

Remaining Checks If Frames Still Do Not Arrive

With supply and grounding proven, work through the protocol layer:

Log every change and re-run the scope capture. A LIN segment fault that survives a correct scope capture is almost always a node configuration mismatch, not hardware.

Contrast: "Slave Not Receiving" on Other Fieldbuses

The LIN failure above is a supply fault that masquerades as a transmit fault. Other buses expose the same class of symptom through counters rather than silence, which is worth knowing so you apply the right diagnostic method.

On an EtherCAT slave, for example, TI's PRU-ICSS EtherCAT Slave Troubleshooting Guide (SPRACJ7) documents that register 0x300, the Invalid Frame Counter, increments on preamble, SFD, length, or FCS faults, while the RX Error and CRC error counters on the first open port that sees corruption localize the bad cable segment. If the addressed SyncManager memory is inaccessible, the Working Counter never increments (read-write +2, read or write +1), and the master reports a WKC mismatch rather than a link-down fault.

The transferable principle: on a bus with diagnostic counters, read the counters before touching the cable. On LIN, which gives you no such counters at the interface level, put a scope on the wire and prove the supply first.