EMX CAN messages out of order

I have two EMX modules talking over CAN bus and I’m not receiving messages in the same order in which I’m sending them. Is it supposed to be guaranteed that the order in which I post them is the order in which they should be put on the bus?
Specifically this happens when I’m sending more than 3 messages at one time, it seems internally you can only queue up 3, is this true? The behavior is as follows: the first two messages are always sent in the correct order, the third seems to be saved up while all intervening messages are sent and then the third message goes out. I receive the messages on the other end and examine their time stamps which properly reflect the order in which they are received which is not the order I’ve sent them. The code looks like this:


            int count = 0, sent = 0;
            while (count < messages.Length)
            {
                sent = Bus.PostMessages(messages, count, messages.Length - count);
                //Debug.Print(string.Concat("Sent: ", sent.ToString(), " messages."));
                count += sent;
            }

When I un-comment the Debug.Print statement and run it again the messages are sent in the correct order.
I also tried sending one message at a time and it has the same behavior, fails without the Debug.Print statement, works with it.
I don’t have a bus analyzer so I’m not sure if it’s in the sender or receiver but the debug statement behavior would make me suspect it’s the sending side.
I’m using SDK 1.0.17.

Thanks for your help.

I am not the CAN professional other developers might help you better.
But as far as I know that CAN messages are timestamped, aren’t they?

This is known issue and will be fixed in the next few days.

Glad to hear! Thanks for the quick reply.

Any updates on when I can get a fix for this issue?

We are working on it as we speak.

I am having an identical problem with a Silicon Labs C8051F560DK development board. This is the only mention of this issue I’ve found anywhere online.

What was the problem and is there any reason to believe the same issue is affecting my hardware?
What was the solution?

@ IckyT2012 - it will not be the same problem since we use a different hardware. An easy fix would be to use one hardware buffer in your controller.

To complete the thread, the issue was a firmware bug that was fixed.

To try to help you out: in general CAN bus hardware implementations tend to be very solid and won’t be able to mix the order of messages. Because of that any time this happens it is very likely in whatever handler is reading in messages from the CAN specific hardware to the general purpose hardware. That is to say the code that reads messages from the CAN bus message buffers to RAM. Usually this is in an interrupt handler which would commonly be just reading the message from the hardware buffers to an array in memory and possibly doing other things like adding a time-stamp. You probably just have a simple error here.

As a general note if you have a critical application that demands properly sequenced messages, consider solving that issue at a higher level than the bus. For example take a look at TCP/IP sequence numbers and handshaking and the ISO OSI layer 4.