Pcan validation skill

PCAN Validation

Overview

Validate PCAN interfaces with a physically looped two-channel bus and explicit evidence. The workflow separates functional coverage, concurrent load, recovery, and soak operation. A test passes only when expected frames are received and validated; successful API writes alone are never sufficient.

When to Use

Use this skill when:

• Qualifying a PCAN interface for bench, development, or automated-test use
• Verifying Classic CAN and CAN-FD timing combinations
• Investigating intermittent initialization or queue behavior
• Measuring data integrity, latency, timestamp monotonicity, or arbitration behavior
• Running a restart-tolerant multi-hour soak
• Comparing firmware, driver, USB port, cable, or host configurations

Do not connect these active tests to a vehicle, production system, or shared CAN network.

Required Bench

• Two independently controllable PCAN channels
• CH1 and CH2 connected to the same isolated CAN bus
• Correct termination, typically 120 ohms at each physical end and approximately 60 ohms measured across CANH/CANL while powered off
• No production ECU or other active node
• Windows host with PCANBasic and Python

Completion criteria: a 500 kbit/s Classic bidirectional canary passes before any stress phase.

Campaign Layers

Layer 1 — Canary

Send known payloads in both directions at:

• Classic 500 kbit/s, 8 bytes
• CAN-FD 500k/2M, 64 bytes, BRS

Fail immediately on open error, timeout, payload mismatch, or nonzero channel status.

Layer 2 — Functional Matrix

Cover:

• All supported Classic rates
• Standard ID boundaries and Extended ID boundaries
• DLC 0–8 for Classic
• RTR where supported
• FD valid lengths: 0–8, 12, 16, 20, 24, 32, 48, 64
• BRS on/off
• Multiple nominal/data timing pairs
• Acceptance filters with allow/reject/allow interleaving

Layer 3 — Boundary and Concurrency

Exercise burst counts around implementation boundaries:

1, 2, 15, 16, 17, 31, 32, 33, 63, 64, 65,
127, 128, 129, 255, 256, 257, 511, 512, 513,
1023, 1024, 1025

Start one sender and one continuous receiver per direction. Use disjoint ID spaces and payload direction/session/sequence fields.

Track separately:

• generated
• driver accepted
• received
• missing
• duplicate
• stale
• unexpected/status
• error frame
• payload/CRC mismatch

Layer 4 — Arbitration

Use different IDs in simultaneous streams. Reverse channel roles and include a Standard frame competing with an Extended frame that shares its 11-bit prefix.

Never transmit different payloads with the same CAN ID at the same time; that creates a data-phase collision rather than a valid arbitration test.

Completion criteria: both priority streams complete with zero corruption, unexplained loss, or starvation.

Layer 5 — Timestamp

Assert:

• Strict monotonicity within each channel
• No timestamp reversal across reopen
• Stable host API-to-receive latency distribution
• No invalid jump hidden by wall-clock adjustments

Use perf_counter_ns() for host intervals. Hardware/host clock-domain comparison requires an explicit epoch mapping.

Layer 6 — Reopen and Recovery

Alternate:

• Classic 500k
• Classic 1M
• FD 500k/2M
• FD 500k/12M when supported
• CH1-first and CH2-first opening order

Each cycle must carry an actual canary frame and end with status zero. Keep retry accounting separate from first-attempt success.

Recommended assertions:

• First-attempt success rate at least 99.5%
• No final failure after bounded retry
• Retry histogram by channel and mode
• Stop after 50 consecutive final failures to avoid hammering disconnected hardware

Layer 7 — Soak

A soak should combine repeated stress with periodic broad coverage, not merely repeat one frame:

• Concurrent production timing burst every cycle
• High-data-rate edge burst every cycle
• Latency sample every cycle
• Open/close and filter checks periodically
• Full Classic/FD matrix hourly
• Atomic checkpoint every 30–60 seconds

Keep high-frequency frame accounting in memory and write aggregate events, not one disk record per frame.

Payload Design

For long FD frames include:

• direction
• session/phase ID
• sequence
• deterministic body
• CRC32

For short frames, compare against an external expected table. Repeating one payload cannot distinguish a current frame from a stale or duplicated frame.

Controlled Faults

CAN transmitters may retry automatically when ACK is absent. A single mismatch write can create a sustained error storm.

Rules:

1. Use an isolated two-channel bench only.
2. Limit mismatch to one frame and a short observation window.
3. Shut down and uninitialize both channels immediately afterward.
4. Reopen at a known-good rate.
5. Send enough successful traffic to drive CAN error counters down.
6. Require a quiet interval, status zero, and consecutive clean canaries.
7. Classify injected errors separately from operational errors.

Do not use physical shorts or unsafe common-mode injection without a separately approved electrical test procedure.

Status Records

PCAN status messages use PCAN_MESSAGE_STATUS (0x80). Some high-level backends may render them like ordinary frames. Inspect raw MSGTYPE or disable status records before declaring unexpected wire traffic.

Status records are neither payload success nor payload corruption. Preserve their count and classification.

Checkpoint and Reporting

Use append-only JSONL for events and an atomic summary:

write summary.tmp → flush → os.replace(summary.tmp, summary.json)

A final report must distinguish:

• PASS — all required phases completed
• FAIL — completed with one or more failed assertions
• INTERRUPTED — campaign ended before required duration/phases

Never convert an interrupted campaign into PASS from partial statistics.

Acceptance Criteria

For normal matched phases, all must be zero:

• payload corruption
• duplicate
• unexplained sequence gap
• send error after retry policy
• queue overrun
• operational error frame
• error passive or bus-off
• unrecovered open/receive exception

Status messages and deliberately injected error records are reported separately.

Common Pitfalls

1. Sequential CH1→CH2 then CH2→CH1 testing mistaken for simultaneous load.
2. Draining queues before accounting for stale or unexpected records.
3. Treating send() success as successful transmission.
4. Starting senders before receiver readiness.
5. Performing JSON/file I/O in the receive hot path.
6. Retrying application frames and hiding loss or producing duplicates.
7. Using the same ID and different data simultaneously.
8. Running unrestricted mismatch tests with hardware auto-retransmission.
9. Using auto_reset=True and hiding bus-off.
10. Writing only a final result and losing all evidence on restart.
11. Comparing hardware timestamps directly to host time without clock mapping.
12. Letting Windows sleep or update restart invalidate unattended duration.

Verification Checklist

• Isolated and correctly terminated two-channel loopback
• Classic and FD canaries pass before stress
• Receiver threads are ready before senders start
• Direction/session/sequence and payload integrity are validated
• Status, stale, unexpected, error, and bad records are distinct
• FIFO boundaries include ±1 around powers of two
• Arbitration uses different IDs and reverses channel roles
• Timestamps are monotonic per channel
• Reopen statistics preserve first-attempt failures
• Fault injection is bounded and followed by known-good recovery
• Checkpoints are atomic and append-only events are flushed
• Final result states PASS, FAIL, or INTERRUPTED honestly
• Final known-good canary passes after all stress