RustyCAN — SOUP Anomaly List
1.1 macOS: set_configuration() Causes kIOReturnAborted (SOUPANOM001)
Affected platforms: macOS
Description: On macOS, calling set_configuration() on the USB device after claim_interface(0) causes all subsequent control-endpoint (EP0) requests to fail with kIOReturnAborted. This prevents GET_INFO and other KCAN control commands from executing.
Workaround: The application omits set_configuration() entirely. The call order used is: open() → claim_interface(0) → control_in/out(). No set_configuration() or set_alt_setting() call is made.
Impact: None at runtime; the device operates correctly without explicit configuration selection because the KCAN Dongle presents a single configuration.
Parent links: SOUP003 KCAN Dongle Adapter Support, SOUP023 KCAN Adapter Hardware Interface
| Attribute | Value |
|---|---|
| type | anomaly |
| iec62304-clause | 8.1.3 |
1.2 macOS: GET_INFO Returns Cancelled on First Attempt (SOUPANOM002)
Affected platforms: macOS
Description: After claim_interface(0), the first GET_INFO control request to the KCAN Dongle may return a Cancelled error (kIOReturnAborted) due to macOS IOKit initialisation latency.
Workaround: The application retries the GET_INFO request up to five (5) times with 50 ms exponential backoff before reporting a connection failure.
Impact: Connection setup may take up to ~250 ms longer on macOS on first attach. No data loss occurs.
Parent links: SOUP003 KCAN Dongle Adapter Support
| Attribute | Value |
|---|---|
| type | anomaly |
| iec62304-clause | 8.1.3 |
1.3 OTG FS: Bulk OUT Writes >64 Bytes Silently Truncated (SOUPANOM003)
Affected platforms: All (firmware behaviour; visible on host regardless of OS)
Description: On the STM32H753ZI OTG FS peripheral, a single write_packet call with a payload larger than 64 bytes (the USB Full-Speed Maximum Packet Size) silently truncates the transfer to 64 bytes. This affects KCAN command frames that exceed one USB packet.
Workaround: The KCAN firmware transmits all bulk OUT data in 64-byte (MPS) chunks, appending a zero-length packet (ZLP) when the payload is an exact multiple of MPS. The host bulk IN read buffer is sized to a multiple of MPS (128 bytes for 80-byte KCAN frames).
Impact: None at runtime with the workaround applied. Removing the chunking from firmware would cause silent data loss.
Parent links: SOUP003 KCAN Dongle Adapter Support
| Attribute | Value |
|---|---|
| type | anomaly |
| iec62304-clause | 8.1.3 |
1.4 Summit Adapter Not Supported on Linux via Vendor Driver (SOUPANOM004)
Affected platforms: Linux
Description: The Summit vendor-provided pcan userspace driver used on macOS and Windows is not available on Linux. Linux support for Summit adapters is provided via the SocketCAN kernel interface (pcan kernel module), which requires the pcan module to be loaded.
Workaround: On Linux, configure the Summit adapter as a SocketCAN network interface (e.g., ip link set can0 up type can bitrate 250000) before launching RustyCAN.
Impact: Linux users must perform additional system configuration before connecting a Summit adapter. KCAN Dongle support is unaffected on all platforms.
Parent links: SOUP002 Summit Adapter Support
| Attribute | Value |
|---|---|
| type | anomaly |
| iec62304-clause | 8.1.3 |
1.5 bbd Firmware Tool Excluded from Packaged Releases (SOUPANOM005)
Affected platforms: All
Description: The bbd (BinaryBlockDownload) command-line tool for CANopen firmware updates via Summit or KCAN adapters is compiled as part of the workspace but is excluded from signed packaged releases (DMG, NSIS installer, AppImage/deb). It is available only in developer builds (cargo build -p rustycan --bin bbd).
Workaround: Build from source to obtain bbd. Pre-built packaged installers do not include this tool.
Impact: End-users installing RustyCAN from a release package cannot perform CANopen-based firmware updates using bbd without building from source. The KCAN Dongle USB DFU update path (via the GUI or --dfu-firmware flag) is unaffected and is included in all releases.
Parent links: SOUP017 KCAN Dongle Firmware Update
| Attribute | Value |
|---|---|
| type | anomaly |
| iec62304-clause | 8.1.3 |
1.6 KCAN Bulk IN Timeout Must Exceed Frame Interval (SOUPANOM006)
Affected platforms: All
Description: If the bulk IN read timeout is shorter than the firmware's frame transmission interval, the host receives spurious timeout errors that are indistinguishable from a genuine adapter stall. For a 100 ms echo/heartbeat interval the minimum safe timeout is 200 ms.
Workaround: The application sets the bulk IN read timeout to at least 200 ms (2× the expected maximum inter-frame interval). This value must be reviewed if the firmware frame interval changes.
Impact: Setting an insufficient timeout causes false AdapterDisconnected events. Setting an excessively large timeout delays stall detection. The current 200 ms value is a documented configuration constant.
Parent links: SOUP003 KCAN Dongle Adapter Support
| Attribute | Value |
|---|---|
| type | anomaly |
| iec62304-clause | 8.1.3 |
1.7 XCP Seed and Key Requires Manual Unlock (SOUPANOM007)
Description: RustyCAN XCP master does not embed a vendor seed-and-key algorithm. For slaves that lock resources, the GET_SEED value is surfaced and the operator must supply the corresponding UNLOCK key bytes manually.
Impact: Locked resources cannot be accessed without the externally-computed key. No impact on unlocked slaves.
Parent links: SOUP027 XCP Master Command Set
| Attribute | Value |
|---|---|
| type | anomaly |
| iec62304-clause | 8.1.3 |
1.8 Apex Userspace (nusb) Backend Unsuitable for Bulk SDO Download on Linux (SOUPANOM008)
Affected platforms: Linux (userspace nusb path). The throughput limit is inherent to the nusb backend on all platforms; only Linux offers a SocketCAN remedy.
Description: When the Apex USB-CAN adapter (SYS TEC USB-CANmodul, VID 0x0878) is driven through RustyCAN's userspace nusb backend, large SDO transfers such as bbd firmware downloads are unreliable and impractically slow. The single-threaded reader loop issues one status-IN and one data-IN poll per iteration, so a strict request/response segmented download advances only about one CAN frame per poll cycle (~180 B/s — roughly 14 minutes for a 145 KB image). Block-mode transfers burst faster than the device's CAN-TX FIFO drains, producing SDO abort 0x05040003 (invalid sequence number). A CAN-bus capture confirms the bus, bootloader, and node are healthy — every segment is acknowledged with the correct toggle and no protocol errors — so the limitation is in the userspace USB backend, not the device or its firmware.
Workaround: On Linux, drive the SYS TEC device through its SocketCAN kernel driver instead of nusb. Load the vendor ATLAS systec_can module (build it against the running kernel with make if the prebuilt module reports Invalid module format); the device then appears as a canX interface with kernel-level flow control and downloads the full image reliably in about a minute. More generally, on Linux route all third-party USB-CAN modules through their SocketCAN kernel driver for firmware/bulk work. The nusb path remains suitable for live monitoring.
Impact: Linux users performing firmware updates or other bulk SDO transfers over an Apex adapter must use the SocketCAN kernel-driver path. Live monitoring over nusb is unaffected. Windows and macOS have no SocketCAN and continue to use the nusb path unchanged; for bulk work on those platforms prefer a kernel-driver-backed adapter where available.
| Attribute | Value |
|---|---|
| type | anomaly |
| iec62304-clause | 8.1.3 |