MPC5748G - FlexCan Tx High bus load

[bassduty]

Hello NXP team,

I would like some precisions regarding FlexCan transmission.

Before setting the message fields of the mailbox, what is the best way to check if an TX MB is still busy without having to abort it? We want to make sure the previous message have been sent before updating the data field.

Sequence 1

1. Check IFLAG and clear it if needed
2. Check CS CODE, if different than “INACTIVE” then return and retry later
3. If “INACTIVE” then prepare the rest of the MB (ID DLC … and finally CODE = DATA)

Or Sequence 2

1. Check CS CODE, if different than “INACTIVE” then return and retry later
2. If “INACTIVE” then check IFLAG and clear it if needed
3. Then prepare the rest of the MB (ID DLC … and finally CODE = DATA)

The reason I ask this is because I first used the sequence 2. But I noticed that it’s not what the reference manual recommends:

It recommends to first check the interrupt (so IFLAG) and then checks CS CODE. So I switch the sequence1 and I started to encounter problem.

With a quiet CAN bus there is no problem but on loaded bus (bus load +-50%) some frames are simply not transmitted at all and the MB returns to the inactive state without any warning that the frame has not been transmitted.  This error occurs when we try to transmit while another device is sending on the bus at the same time.

It looks like arbitration does not take place and the can controller will not retry later.

Actually what is the difference between checking if IFLAG is set or check CS CODE == INACTIVE?

From my understanding, if IFLAG is set it means that a message has been transmitted and therefore the MB should have returned back to INACTIVE state.  But does it mean the message have been sent or does it mean that the message have been transmitted to the flexcan controller?

We noticed in some of the NXP code example, that you are forcing CS CODE to INACTIVE just before preparing the MB:

Is it really necessary and why ?

Another question: The RM says this:

What is the exact meaning of “unconditionally once” here?

• Does it mean the frame will be transmitted one time?
• Does it mean it will attempt to transmit the frame one time and if it fails it won’t do anything?

 What is the strategy when FlexCan losses arbitration? Does it retry sending? How much time will it retries? Is there a timeout or a counter?

Finally, can you confirm how many CAN MB are available on the MPC5748G( without using Rx FIFO) ?

The RM is mentioning 96 MB

But with the debugger I can see only 64 occurrences of MB but 96 occurrences of RXIMR.

Thanks for your answers.

Best regards.

[PetrS]

Hi,

the procedure, described in the RM, assumes the Abort feature is enabled, MCR[AEN] bit is set. In that case you need to check and clear the flag before writing to MB because if flag is set the MB is blocked for writing. If AEN is cleared the procedure can be the one you mentioned. It does not matter if CODE or flag is checked first.

The flag is set after successful transmission on the bus, without any error, moreover CODE is changed to INACTIVE.

Writing INACTIVE at the beginning of transmit function is not needed if user know the message in this MB was already transmitted and the MB will not be included into arbitration process. Then writing to the MB is safe.

The "unconditionally" means the MB will be transmitted once, but must be transmitted, after it wins the arbitration and on the first opportunity window on the bus. So the CODE "0xC" is kept until frame is really transmitted, without error. Then CODE becomes INACTIVE and flag is set.

The MPC5648G supports up to 96 MBs on each FlexCAN module.

BR, Petr

[bassduty]

Hi Petr,

thanks a lot for your answers. It's more clear now.

Best regards !