cpu/stm32/periph/fdcan: reread bittiming max values

[kfessel]

since the stm32 fdcan is quiet similar to the samd5 can (same ip core bosch mcan). i had a look at its configurartion and found the values quiet strage i reread them from the manual of stm32g0 and g4 (same) chapter 36 and 44 register (FDCAN_NBTP) and (FDCAN_DBTP)

especially the SJW values where strange.

Contribution description

update the bittiming max values to the values actually found in the manual

Testing procedure

read and compare

test with hardware

i do not have a test system with that cpu at the moment (g4 would use fdcan if asked for perpih_can)

especially unfit sjw values might work for some time unless clocks drift or other

Issues/PRs references

[crasbe]

I have a Nucleo-G474, how could I test this?

[kfessel]

If you also got a can interface.
Can communication should work as before ( the old wrong brp_max of 1024 is unlikely to be selected and cause errors for usual datarates and valid clock inputs) . e.g.: tests/drivers/candev
with this PR and the improved SJW calculation form #21756 the communication will be even more robust if the clock if slightly of errors show in frames being repeated often or error messages in candump -dex -ta -D any,0~0,#FFFFFFF" sadly not all devices expose everything or enough for the error message to linux some require an off kernel drive to open up a little more (peak with linux driver is slight less verbose than peak with peak driver, gs-can interfaces are also available at different levels.

[kfessel]

another way of verifying that this does what i claim would be to enable debug in sys/can/driver.c an compile one of our can tests tests/drivers/candev see the terminal ouput and use the stlink debugging interface to verify that the can register values DBTR and NBTR after can init are within the expected range (mcu manual) . maybe configure extrem low bitrates to make higher values be appled .

[riot-ci]

Murdock results

✔️ PASSED

4575585 cpu/stm32/periph/fdcan: reread bittiming max values

Success	Failures	Total	Runtime
10516	0	10516	12m:49s

Artifacts

• Documentation preview

[kfessel]

I just improved on the debug result print in #21756 that might help with the review

[kfessel]

the 1024 might have been read from a sentence in the manual The CAN time quantum can be programmed in the range of 1 to 1024 FDCAN kernel clock periods: tq = (BRP + 1) × FDCAN clock period fdcan_ker_ck
This sentence might be there because older mcan cores (prior 3.1.0) had an other BTP register that had a 10 Bit BRP and smaller TSEG(6 and 4 Bit). but that would not fit with the rest of the max values.

in that process the MCAN BTP register names where where chaged from BTP an FBTP (FD Dataphse) to NBTP (Nominal) and DBTP (FD Dataphase)

I am not sure if any of the G0 G4 was produced with an old mcan ip core (but even in that case the values would be wrong