It's more like documentation update request. Halt, freeze, disable, etc. It is not 100% clear which bits can be toggled simultaneously and in which conditions. I started from FlexCAN_s32k144/8 and FlexCAN_FD_s32k144/8 examples provided by S32 Design Studio. After playing a bit with CAN FD I started adding the rest of required CAN protocol stack and faced weird phenomenon. With FDEN=0 (CAN FD disabled) CAN 2.0 communications were well, but with FDEN=1 and everything else untouched some CAN TX send requests for unknown reasons were delayed until the next CAN RX event, which comes few seconds later if my node doesn't reply. I made me sure all Tx MB setup is complete in time, no errors, just empty timestamp field and mailbox interrupt flag not set for given Tx MB. The problem seems that FDEN and few other bits were toggled in the same write cycle to MCR like write of HALT=FRZ=0. Setting up all MCR bits, and then unfreezing solves all problems! If you check S32 Studio examples, they suggest unfreezing and setting FDEN from 0 to 1 in the same write cycle:
CAN0->MCR = 0x0000081F; /* Negate FlexCAN 1 halt state & enable CAN FD for 32 MBs */
Prior to this ^^ write to MCR line, only MDIS is toggled high and then low, you won't find other write accesses to MCR. Out of reset FRZ and HALT bits are set, FDEN is clear, 0x0000081F bit pattern clears both FRZ and HALT and sets FDEN. If this example is correct, then why I could see delayed Tx? If not, then I'd like to know what MCR bits should be kept unchanged while toggling some other MCR bits, all restrictions please, thanks.