The FlexCan MBs received a same frame twice

[yuanlijun]

Hello:

I am using can bus for three can nodes' datas transmission. Two can nodes' are MCF54418 with the SN65HVD230(3.3V), And the third can node is MCF5213 with the PCA82C250(5V).
My datas transmission design as following:
1) Two 54418 can nodes's named A and B, the 5213 can node named C;
2) The can speed is 1Mbps;
3) A Send a can short frame to C interval 10ms, and C reply a short frame to A immediately;
A->C frame: 88 01 04 01 40 a1 06 54 3f 00 00 a0 7e
C->A frame: 88 04 01 04 10 75 06 54 3f c9 3e f0 d5
4) B send a can short frame to C interval 100ms, C receive but don't reply to A;
B->C frame: 88 20 04 00 40 a1 06 00 00 00 08 91 44
5) The can frame priority that A send to C and C reply to A are 0(highest), B send to C is 1;

Here happend a problem with above system: While A and B send can frame to C at the same time(then C reply to A), the A Flexcan MBs will receive the same can frame twice which replied from C, but actually, C just replied one can frame to A(I monitored the can bus data with another device). And the two same frame's receive time are very nearly,just 20-30us.

Do you need any other information?

Looking forward to your help,Thinks.

[TomE]

> A->C frame: 88 01 04 01 40 a1 06 54 3f 00 00 a0 7e

That's a problem as a CAN Frame can only have 8 bytes in it, and there's 13 bytes listed.

So I'm guessing some of the above is the CAN ID and some is the data frame.

You should be clear on what numers are CAN ID and what is data.

It isn't possible to "send a frame from A to B". CAN frames are BROADCAST and received by all devices. Whether they copy that frame into a message buffer depends on the filters that are applied in the receiver.

So you need to list the filters and the filter setup you're using.

Are you reading the CAN messages under interrupts, or are you POLLING the MBs?

There are multiple different versions of FlexCAN in the different versions of the chips. Some have 16 MBs and others have up to 64. Some have Receive FIFOs and others don't. Some allow multiple MBs to receive the same messages (if one is full then the next one will receive), but most don't.

The MCF5441x FlexCAN has 16 masks and also supports a receive FIFO. It also seems to be able to support receiving the same CAN ID into multiple MBs, but you have to use the timestamps to work out the reception order.

The MCF5213 has the most primitive FlexCAN module. It can't use a FIFO and it can't receive into multiple MBs. It only has THREE masks, so it can only be programmed to receive three different messages into three different buffers in hardware.

That means it has to be programmed to "receive everything" and the software has to perform the filtering on the ID. That also means that at 1 MBPS you have to guarantee that under all (and worst-case) circumstances your code can respond to a received message and empty the MB within 50us (for zero-byte messages, you have 100us or so for ones with 8 data bytes). So you really have to use high-priority interrupts and empty the MBs in those interrupts. Worse, if you want to receive both Standard and Extended IDs, you probably have to dedicate MBs 14 and 15 for that and set one to receive Standard and the other to receive Extended.

But you're having problems with apparent duplication on "A", and not on "C". The FlexCAN module on "A" has all the new features listed previously

You should probably be using the FIFO mode on "A" and "B". That is easier unless you trigger the "misaligned mask bit bug" in that chip. Watch out for Errata SECF193.

Otherwise you may be handing the MBs wrongly. There's a very special sequence that has to be use to "Lock" and "Unlock" them. Get this wrong and you have have problems like you're seeing. Read "Locking and Releasing Message Buffers". There's an example there of multiple message reception.

If all else fails, check the FlexCAN driver code in Linux for clues on how to use these chips.

Tom

[yuanlijun]

Dear Tom:
Thinks for your detailed replies.
Due to other work delays.Sorry for I didn't answer you timely.My further Information as following:
1) 13 bytes Can frame include a Extended Frame Format(EFF) byte, two identifier bytes,and ten data bytes;
I transplant this can frame format(source format from SJA1000) from another product.
2) All the nodes on the can bus use the same Extended Frame Format.
3) The words "send a frame from A to B" means application layer,not means the can bus physical layer.Sorry, my description is not very precise.I understand that can frames are BROADCAST and received by all can nodes. And my receive MBs register are not config hard ID filter,All received can frames are filetered by my application software.
4) I am reading the can frame by POLLING the MBs, and for the node A, I configed the MB0 for send MB, MB1-MB15 for receive MBs.
5) All my nodes are not use the FIFO mode.
6) Yes, in the MCF5213(node C), I handle the MBs just in time, and here is no problem with it.
7) For all the can nodes are not use the FIFO mode, so, here are no the "misaligned mask bit bug" problem.
8) My reading MBs abided by the "Lock" and "Unlock" sequence.

My application (node A) read the MBs as following:
1) In my embed system,I read MBs in the highest priority interrupt which interval 250us.
2) In a 250us interrupt task, I read MBs for four times(one time read one MB which has received frame) cycle by the "while" C language, then if "While A and B send can frame to C at the same time(then C reply to A)" happen, My node A will read two same can frame (replied by C) from two different MBs.
3) If in a 250us interrupt task, I read MBs for just one time, and there won't read two same can frame.
4) In addition, "In a 250us interrupt task, I read MBs for four times" is beause of here are others can nodes(I didn't describe above) send can frames to A, so A must handle the can frames quickly.

I don't know why I read MBs interval a little time,here will be occur  same frame question? Any idea?

[TomE]

Any ideas? Yes. Don't POLL the MBs. They may not like it. As well, if you're not using multiple MBs for different filtered IDs (which you aren't) and you don't need to implement some sort of FIFO because your code can't guarantee timing (which your one can), then don't program more than one MB to receive. Just simply program one MB and then poll it ONCE every 250us. That is a lot simpler and might be more reliable. But it may not.

How are you "polling the MBs"? What registers are you reading? You shouldn't read the MBs at all once you've made one "ready to receive" or "ready to transmit", but should leave it alone. There are other status registers that give a summary of what has completed.

A lot of these peripherals are very complicated internally, and are often a little CPU internally, running a fixed program that "emulates" the peripheral. One of the things they have to do is to service read and write requests to the shared registers. There can be TWO different classes of problems with this, both of which I've seen. But let me say I haven't seen in in the FlexCAN peripheral because I'd never deliberately write code to cause these problems.

Firstly, with some peripherals, when you read a register to poll the chip it delays the internal operation of that chip. If you poll it too quickly you might overload it so it doesn't work properly. This was first famously seen in an old Western Digital FD1771 Floppy Disk Controller (yes, I've written code for that and its later friends). The best solution to these problems is to NEVER poll these chips. Or any controllers in case that causes a problem. You wait for the Interrupt. When that happens you have a guarantee that the MB isn't busy and you can poll/read/write it. If you don't want to write your code that way, then set up the interrupts and poll the interrupt status bit in the interrupt controller instead. Or you may be able to poll the FlexCAN Status register. Just don't poll the MBs.

The later FlexCAN chips have other problems. The most advanced one has 64 MBs and can handle multiple MBs receiving the same message. But not all of them. There's a very complicated table in the manuals for them that gives the maximum number of MBs the chip can handle at particular baud-rates and clock rates without getting overloaded, because it has to internally POLL all of them in sequence, and TWICE when a message arrives.

Secondly, with a LOT of peripherals, they don't handle simultaneous access to the register from the "internal machine" and the external CPU. If the internal machine is about to update a bit in a status register, then it has to write to a shared memory location (which is the register) to change that bit. If the CPU reads or writes the same register in the same cycle - well there SHOULD be hardware in place to make sure those operations still happen properly. But in a lot of cases that hardware is missing and they don't. For instance, in the MCF5329 LCD controller [1] it is impossible to read the status register without losing status bits. It has this problem. If you are reading the register to see if a bit is set while it is trying to write that bit (or some other bit) then that write silently fails and your code fails. That makes it really hard to use properly, and it needs horrible undocumented workarounds. The Freescale MSCAN chip has a free-running timestamp register in it that can be used to timestamp the CAN messages. Unfortunately it has two problems. Firstly there's no way to READ the timestamp, so it can't be compared to anything. Secondly, the code that increments the timestamp register gets blocked when the timestamp is read (by the MSCAN hardware) to write to an MB, so the timestamp "slips" bu a count on every receive and transmit message. So it can't keep proper time either! [2]

As I said, I don't know if the FlexCAN chip has problems like these, but unless you like spending weeks writing tests to find these sort of problems, it is a lot more productive to write you code so it can't cause these problems.

Suggestions:

1 - Program one receive MB only.

2A - Don't poll the MBs. Poll the IFLAG register. If that works, you're done [3].

2B - If that still has problems, enable the MB interrupt in IMASK, but disable it in IMRL1 and poll IPLR1.

3 - If that doesn't fix it you may have a bug in your code.

4 - If you don't have a bug in your code you may have found a new one with the FlexCAN controller.

Note 1: MCF5239 LCDC Problems

MCF5329 LCDC: Reading ISR register loses events 

Note 2: MSCAN Timestamp Problems

https://community.nxp.com/message/91157

Note 3: If you're polling IFLAG or IPLR1, then when the status bit sets you have to ack it by writing 1 to that same bit in the IFLAG register so it is now clear for next time.

Tom

[yuanlijun]

Hi Tom:
Thanks for your replies.
As you say,I was POLL the IFFAG register(not " POLL the MBs",that is my description error), and I cleared the bit by writing 1 to it.
I will try your other suggestions those days, If I have new information, I will communicate with you.
Thanks again.