FlexCAN MCR, which bits can be set up simultaneously?

[kef2]

Hi,

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:

\S32DS_ARM_v2018.R1\eclipse\plugins\com.nxp.s32ds.arm.examples.descriptor_1.0.0.201801242132\Examples\S32K144\FlexCAN_FD_s32k144\src\FlexCAN_FD.c

  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.

[PetrS]

Hi,

I have never seen an issue when testing this demo example, and to be honest have no idea why in your case the TX operation should be delayed until module receives a message.

For the MCR access; I am not aware of any restriction for simultaneous bit setting, however as many of bits can be written in Freeze mode only I would rather not use single instruction when the function is selected and freeze exit is requested. I would recommend to initialize all functionality in Freeze mode and finally clear just HALT bit followed by checking FRZACK/NOTRDY flags to be sure of Freeze mode exit.

BR, Petr

[kef2]

Hi,

• I have never seen an issue when testing this demo example, and to be honest have no idea why in your case the TX operation should be delayed until module receives a message.

I tried changing everything, for example TASD from min to max. It had some influence, up to not replying at all, but clearly not TASD was the culprit. After making MCR unfreezing by clearing just HALT bit - everything started working, even with odd TASD. Code also worked keeping FDEN bit in reset default state. But writing MCR to the value which changes FDEN 0->1 and HALT 1->0 in the same write cycle made module misbehaving. 

• I have never seen an issue when testing this demo example, and to be honest have no idea why in your case the TX operation should be delayed until module receives a message.

Yes, sure. I did it so previously for Vybrid MCU. But I think that if it matters which bits can be changed in the same write cycle, then certainly it should be documented.

Regards!