BitTiming.from_sample_point rejects valid timing solutions due to hardcoded register limits #2083

Description

BitTiming.from_sample_point cannot find valid bit timings for some clock/bitrate combinations. The method calls iterate_from_sample_point, which constructs each BitTiming with strict=True. This parameter cannot be changed by the caller.

The _validate method enforces hardcoded register limits:

• tseg1 ≤ 16
• tseg2 ≤ 8
• brp ≤ 64

The strict mode tightens brp further to 32. These limits follow the CAN 2.0 minimum register specification. Many modern controllers support larger register ranges.

When a clock/bitrate combination produces timing values that all exceed at least one of these limits, the solver rejects every solution and raises ValueError.

Example

STM32G431 with candlelight v2.5 firmware from https://github.com/Elmue/CANable-2.5-firmware-Slcan-and-Candlelight has a 160 MHz CAN clock. The FDCAN peripheral supports brp up to 512 and tseg1 up to 256.

from can import BitTiming
bt = BitTiming.from_sample_point(f_clock=160_000_000, bitrate=250_000, sample_point=87.5)
# Raises: ValueError: No suitable bit timings found.

The valid solution is brp=40, tseg1=13, tseg2=2 (sample point = 87.5% exact). The solver finds this combination but rejects it because brp=40 exceeds the strict limit of 32.

All lower prescaler values produce tseg1 values that exceed 16:

Affected code

• bit_timing.py — iterate_from_sample_point passes strict=True with no option to override
• bit_timing.py — _restrict_to_minimum_range limits brp to 32
• bit_timing.py — _validate limits tseg1 to 16, tseg2 to 8, brp to 64

Suggested fix

Add optional limit parameters to from_sample_point and iterate_from_sample_point:

@classmethod
def from_sample_point(
    cls,
    f_clock: int,
    bitrate: int,
    sample_point: float = 69.0,
    tseg1_max: int = 16,
    tseg2_max: int = 8,
    brp_max: int = 64,
) -> "BitTiming":

Pass these limits through to _validate instead of using hardcoded values. This approach lets callers supply the actual register ranges reported by the hardware. The defaults remain unchanged, so existing behavior is not affected.

The gs_usb interface could populate these limits automatically from the device's GS_USB_BREQ_BT_CONST capability response, which already reports tseg1_max, tseg2_max, and brp_max.

Workaround

Construct the BitTiming object directly. The constructor defaults to strict=False:

bt = BitTiming(f_clock=160_000_000, brp=40, tseg1=13, tseg2=2, sjw=2)

Affected version

4.6.1 (also present on main)