MSCAN Timestamp

[patti]

Hi, I have noticed that there is a Timestamp register for rx can frames with the MSCAN controller. But how do I do something usefull of that? The data I am reading is very flucturating, somethimes it is 200, other 3, 125. how do I know, how the counter works? Is it millisecounds? miqro? How do I get support for a larger value that 16 bit?
thanks in advance Patrik

[Lundin]

I believe it is a superfluous feature originating from muddy thinking, just as many other things in MSCAN. The MSCAN module is indeed using an internal clock, which you cannot access. You can use the time stamp register as a fairly effective random number generator in your CAN applications, but that's about the only usage.

Another example of dumb, useless things is the tx priority register. Instead of making use of the stadardized CAN bus bit arbitration, they invented a 8-bit register, effectively narrowing down the number of priorities your message can have, from 11/29 bit to 8 bit. The controller will pick the message with highest tx priority, its identifier is completely ignored. If priorities are equal, the tx buffers will work as a FIFO, again ignoring CAN identifier. As it happens, all  industry standard higher layer CAN bus protocols like CANopen, Devicenet etc rely on standard CAN bus arbitration of id for priorities. In the cold harsh reality of real-world applications, this means that you can only use a single one of the MSCAN tx hardware buffers at a time, or your CAN protocol will not behave as expected by fieldbus standards.

Way to go, Freescale.

[TomE]

> Another example of dumb, useless things is the tx priority register.

Yes, agreed. It won't send them with "the proper priority". You can assign priorities yourself to try and get different IDs going in the right order, but it is a pain.

It is often more important (when sending diagnostic or debug messages) to have them send in the right order, rather than in a priority order based on the IDs. Some protocols use a range of IDs where the lower bits are the "message counter number", so they have to be sent with the priority based on the ID ignored.

> If priorities are equal, the tx buffers will work as a FIFO

Wrong. They don't. A FIFO implies the last one you push in is the last one to go out. It would be very nice if it did work like a FIFO, but it doesn't. If you load up Transmit Buffers 1, 2 and 3 in that order (with the same priorities) and leave it alone it will send them in that order. But if you take an interrupt when "1" goes empty, and put another one in there, IT will now be the "highest priority" one and it will go before "3".

So what you have to do is to put your "sequential messages" in with incrementing priorities, until you get to 255. Then you have to wait until they've all been sent, and only then can you "reset the priorities" back to zero and start again.

> Another example of dumb, useless things is the tx priority register.

But it would be far worse if that register didn't exist. At least you can use it to try and work around all the other problems. Without it you could only ever send "one message at a time using one transmit buffer". At least this lets you send them "three at a time", which is another way to use the available hardware.

Don't get me started on FlexCAN though...

Tom

[PaulPorter]

Hi Patti

I can partly answer your question, but I have some more questions to ask.
The Timestamp register you are reading is driver by the CAN bit clock, so you can calculate how much each incriment is in "Real Time"

I am concerned that you cannot read this CAN bit clock directly. What value is the timestamp if you cannot compare it to the current value of the counter -> This way you could work out interrupt latencys, etc,etc.

If anyone knows how the internal timer can be read please let me know.

Regards

[TomE]

Paul wrote:

> I am concerned that you cannot read this CAN bit clock directly.

>What value is the timestamp if you cannot compare it to the

>current value of the counter

We were looking at this (on an MPC5200) and have had the same realisation. What is the use if the "timestamp" can't be referenced to anything.

The manual says "Timer is reset (all bits set to 0) during initialization mode".

Maybe we're meant to start a 32-bit timer clocked at the CAN bit-rate at the same time the contoller exits this mode - either when INITRQ is set to zero or when INITACK goes to zero (or between sometime). Then we'd have a reference.

Has anyone tried this? Does any of the sample code demonstrate use of the Timestamp?

Tom

[TomE]

Well, it is a bit over 6 years later and I'm looking at this again.

I *REALLY* need an accurate timestamp on received and transmitted CAN messages.

> Maybe we're meant to start a 32-bit timer clocked at the CAN bit-rate at the same time the contoller exits this mode

Yes, done that. I'm comparing the arrival timestamp on the CAN message (at a baud rate of 1MHz) with a microsecond clock derived from the CPU Timebase. This is on an MPC5200.

With no CAN traffic I'm seeing the following deltas between the two timestamps at 1 second intervals:. The first column is the difference between the two counters, and the second column is the differences between them.

       48773
       48777  4
       48781  4
       48788  7
       48790  2
       48797  7

That's strange and inconvenient, but it is nothing compared to what happens when I've got 3400 CAN Messages per second of traffic on the port:

       48006
       46235    1771
       44673    1562
       42904    1769
       41150    1754
       39381    1769
       37813    1568
       36048    1765
       34289    1759
       32515    1774
       30737    1778

That looks suspicious. With about 3400 messages per second the counter is slipping about 1700 counts per second. It looks like the counter is consistently losing one count for every two messages.

That would suggest the counter in the controller can't be READ and INCREMENTED in the same cycle, and so when the controller reads the timestamp to write it to the message it prevents it from counting. Altogether useless.

The MSCAN controller in the MPC5200 has two errata items. The clock-select bit doesn't work properly and it can't match extended IDs with stuff bits in the wrong place, but there's nothing to say the timestamp doesn't work properly. Maybe nobody has attempted to use it (as it is hard without being able to read it), so nobody has found this problem before.

Tom