flexCAN message buffer on MCF548x

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

flexCAN message buffer on MCF548x

Jump to solution
1,159 Views
winkck
Contributor I

Hi all,

I have a question about flexCAN message buffer on MCF548x.

flexCAN has 16 MBs for Tx and Rx.

I set 14 MBs(MB#0 ~MB#13) for Rx and 2MBs for Tx.

And, I set same ID(i.e. 0x4AA) to MB#2 and MB#7.

But, when a master send a packet data, flexCAN receive the packet data via only MB#2.

I want to know how I can use MB#2 and MB#7 on the same ID.

Thanks

1 Solution
979 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi,

Below description at MCF5485 reference manual about FlexCAN reception queue description is incorrect.

pastedImage_1.png

This feature functionality is confirmed does not exist at ColdFire (MCF548x) FlexCAN module.

The contents at reference manual is incorrect.

Sorry for the document issue may bring any inconvenience to you.


Have a great day,
Mike

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

View solution in original post

4 Replies
979 Views
TomE
Specialist II

Hui Ma already answered this question as it being a documentation error. That chapter in the manual has been partially edited to match the features in the next version of the FlexCAN module. Or, more likely the starting point was the chapter for the next version that then had the "new features" removed, but they missed that line.

That manual only has one match for "reception queue" in that one sentence in the Functional Overview. The MCF52277 and MCF5441X manuals have that sentence, plus FOUR other mentions in the chapter. One is in the "Feature List". Another is in the "Matching Process" section. It is also detailed in the "CANMCR[BCC]" bit, which the MCF5485 doesn't have. Also in "Initialisation". So those ones really have that feature and the manuals are correct for them.


The problem is that there have been a lot of different versions of the FlexCAN module, all of them different. There's also no list that I can find of the different versions, what features they have, and what chips they are in.

This is a big problem for the Linux FlexCAN driver writers. Here's a list of seven different variants with the different bugs that the drivers have to work around:

Linux source code: drivers/net/can/flexcan.c (v5.3.11) - Bootlin 

The above start with the FlexCAN module in the i.MX25, and that's a lot further along than the ones in the ColdFire chips.

The first and lowest-featured FlexCAN modules are the ones in the MCF5235, MCF5319, MCF548X and others. They have 16 Message Buffers and no FIFOs or "Reception Queueing".

The ones in the MCF5441X and MCF52277 added the "Reception Queue". They have the "BCC" bit in CANMCR to enable this.

Later ones (like in the i.MX53) have the "BCC" bit as well as a "FEN" bit that enables a six-deep reception FIFO. 26 of the 32 bits in the MCR register are implemented, while the MCF548X only has 10 bits implemented. So this one is quite further along.

Later ones in the i.MX6 have 64 Message Buffers, up from 16. But the FIFO is still only six deep. There may be other variants out there in other chips.

If you have the original one (as you do), then if you're building a device to receive ALL CAN IDs, and then filter them in software, you can only use two Message Buffers for reception - one for "normal" and one for "extended" IDs. You have to absolutely guarantee that your system worst-case interrupt latency is less than the minimum message size (50us at 1MHz) or you will lose messages. If you're building a simple device (unlikely with the MCF548X) then you have one message buffer per CAN ID that your device is interested in. Or a mixture of the two.

If you have the ones with the "Reception Queue" and try to use it you'll find it is very difficult to receive messages in order. They'll arrive out of order. If that's important (it usually is) then you have to buffer received messages and then sort them according to the timestamp fields.

If you have the FIFO one, then you can use that and have a more lenient interrupt latency. But it is only 300us at 1 MHz. And then on something like an i.MX53 running Linux, the usual latency is so large that you'll lose CAN messages anyway unless you rewrite the supplied driver and add "interrupt priority" to the OS, which it lacks.

The latest experimental drivers on the 64-buffer chips are using "Reception Queue with Timestamp Sorting" again to try and overcome the latency problems.

Tom

979 Views
winkck
Contributor I

Hi Tom,

Thanks a lot for your answer.

We use DNet for FlexCAN module.

"extended" IDs is available in DNet?

BR

0 Kudos
979 Views
TomE
Specialist II

"DNet"? Is that DeviceNet?

DeviceNet - Wikipedia 

> "extended" IDs is available in DNet?

Is that a question or a statement?

It seems like you're writing a driver. So handling Standard and Extended IDs at the hardware level is something you have to do.

Tom

0 Kudos
980 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi,

Below description at MCF5485 reference manual about FlexCAN reception queue description is incorrect.

pastedImage_1.png

This feature functionality is confirmed does not exist at ColdFire (MCF548x) FlexCAN module.

The contents at reference manual is incorrect.

Sorry for the document issue may bring any inconvenience to you.


Have a great day,
Mike

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------