[STM32CubeMX] Misleading FDCAN baud rate calculator when operating multiple FDCANs simultaneously

[vcu1]

Background: I am trying to bring up simultaneous operation of both FDCAN peripherals on an STM32G0, but due to a combination of unfamiliarity with the clock internals, and a misleading baud rate calculator, I spent a while trying to debug what I thought was a non-functioning FDCAN2 peripheral, but was actually working at an unexpected frequency.

FDCAN1 configuration:

FDCAN2 configuration (noting that the prescaler is 8, while the clock divider is 1):

with this configuration, FDCAN2 transmission works as expected (verified using a PEAK CAN dongle) at 250kbaud when I am running it on its own in normal operation -- started the FDCAN2 peripheral using HAL_FDCAN_Start(&hfdcan2). However, if I also start FDCAN1, then I can no longer read any transmissions from my CAN dongle.

After unsuccessfully attempting to debug the issue in firmware, probing my CAN lines revealed that FDCAN2 was operating at 30kbuad (250k/8 = 30k). Going back at the CubeMX configuration, I tried changing the nominal prescaler from 8 -> 1:

Thankfully, this was able to resolve my issue, and FDCAN2 resumed normal operation at 250kbaud.

Perhaps there is some change required in either the HAL or STM32CubeMX to address this? I feel that the configuration for one CAN peripheral should be accurate (in terms of the calculated kbaud), regardless of whether the other is actively running or not. 

Further, I was wondering if someone could clarify exactly what is happening here, "under the hood" as it is not immediately obvious to me. It seems like FDCAN1's clock division only occurs when the peripheral is actively running, but I can't seem to find anything in the reference manual explaining the clock division with respect to the operating mode of the CAN peripheral.

Thanks for reading.

[Tesla DeLorean]

My approach would be to code a routine to unpack the registers, and work back to the APB or peripheral clocks, per RCC and the clock tree, to report the baud rate as configured.

It's all synchronous so it's probably a matter of decoding the right clock source or mux, and the failure of CubeMX to catch an interdependency, or over-writing a register with a subsequent call / initialization.

[Tesla DeLorean]

They share a common clock source, so I'd watch that doesn't change between instances

RCC->RCC_CCIPR2 (HSE, PCLK/APB1, PLLQCLK)

At FDCAN_CKDIV via PDIV*, the block diagram show a bypass, but I don't see any register, but zero in PDIV is DIV1

Individually FDCAN_DBTP (NTSEG1,NTSEG2,NBRP, DTSEG1,DTSEG2,DBRP)

* "The clock divider is common to all FDCAN instances. Only FDCAN1 instance has
FDCAN_CKDIV register, which changes clock divider for all instances.
If several FDCAN instances are present, the input clock divider must be modified before
configuring the other FDCAN instances. "