Those experimenting with CAN FD on an i.MX RT1064 or similar will have noticed that the 'Enhanced' registers of the CAN FD capable 'FlexCAN3' peripheral are either not implemented at all, or are not working properly (as far as know on 2019-09, this concerns the 'Enhanced FIFO' and the 'Enhanced bit timing registers', they all throw HardFaults when trying to acess them).
So we have to stick to the 'Extended' bit timing registers, which have less "bits" for the CAN timing segments tSeg1, tSeg2. The result is relaively coarse (and few) time quanta for each CAN / CAN FD data bit, especially for combinations with a low bitrate for the arbitration phase (e.g. message ID sent at 500 kbit/sec) and high bitrate for data (say 4 Mbit/sec). CiA (CAN in Automation), but also NXP themselves recommend to use THE SAME prescaler setting for both phases. In the RT1064 Processor Reference Manual Rev 0.1 on page 2768, there's a tiny note in the description of the CAN FD bit timing register ("FDCBT") which says:
> NOTE: To minimize errors when processing FD frames, use the same value for FPRESDIV and
> PRESDIV (in CAN_CBT or CAN_CTRL1).
This is easier said than done when the 'Enhanced' registers (with more bits for the propagation segment, tSeg1, and tSeg2) are absent, or don't work as described in the reference manual (Rev 0.1). In fact, I have got the 500 / 4000 kBaud combination working to some degree, but the CAN FD "brs" (bitrate switch) causes an awful lot of error frames that always arrive in bursts, and the sending note sets its "ESI" (error state indicator) bit in the CAN FD frame very often.
But there's another strange effect: My first steps with CAN FD on an RT1064 were based on the 'CANFD interrupt transfer' demo, which uses a "debug console" using LPUART1. I removed the debug console because I don't use it, and the UART will be occupied for other tasks later. This caused FlexCAN3 to stop working ! After spending hours searching for all kinds of reasons, the problem could be narrowed down to the following:
Before initialising "CANFD/FlexCAN3", it's not enough to call CLOCK_EnableClock() for the FlexCAN unit... it seems to be necessary enable the clock for LPUART1 (at least for FlexCAN3) by setting the 2-bit-group "CG12" in register "CCM_CCGR5" by either of the two commands (but basically do the same):
CCM->CCGR5 |= 3 << (2 * 12); // set 2-bit-group "CG12" alias "lpuart1_clk_enable" in register "CCM_CCGR5"
Without this, the initialisation code for FlexCAN3 got stuck when trying to enter or exit from 'Freeze' mode (that's the only mode in which you can configure certain registers in any FlexCAN unit).
The effect was verified as follows:
Pause the RT1064 via debugger, then (in Keil's "Peripheral") view, clear 2-bit-group "CG12" in "CCM_CGR5", let the RT1064 continue
-> no more CAN FD transmissions from FlexCAN3,
CAN frames pending for transmission (in the TX buffer) don't get transmitted.
Pause the RT1064 via debugger again, *set* 2-bit-group "CG12" in "CCM_CGR5" to '3' = "enable LPUPART1 clock" in Keil's "Peripheral" view, let the RT1064 continue again
-> et voila, FlexCAN3 is able to transmit messages again.
I hope this "observation" can save fellow developers some time... to summarize : Even if you use LPUART1 or not, enable its clock in the CCM unit, before initialising FlexCAN3, and keep that peripheral clock enabled.
I also hope that NXP comes up with a Processor Reference Manual (for the RT1064) that really matches the registers inside the chip (this doesn't only apply to FlexCAN1 / 2 / 3).
(keep this thread open for other 'observations' related to the RT106x's CANFD/FlexCAN3 unit... e.g. how to realize "good" bit timing combinations for CAN FD with high data bitrate / arbitration bitrate ratios without the non-functional 'Enhanced' timing registers, which currently give some headaches here)