CB34-EX CAN (controller area network) performance

[patpat]

I'd like to know about the CAN reception performance; I understand CB34-EX FlexCAN does not implement a "normal" receiving message buffer, fact that leads to received messages being overwritten on heavy load buses.
Is there any available netburner report on this issue?
Is anyone out there using the CB34-EX having experince on this topic?

Thanks
Pat

[rnixon]

Hi,

Exactly what are the differences between the flexcan and "normal"? I think flexcan just relates to the hardware, and I'm not sure how that affects buffering. Does other hardware you have used include a hardware buffer?

[patpat]

if you use a SJA1000 CAN controller you get an RX "hardware" FIFO buffer. if you use a CB34-EX (MC5234) you get a Freescale FlexCAN CAN architecture that does not have an RX hardware FIFO buffer; It has some "mysterious" Message Buffer arrangement able to hold “only one” message each; No FIFO.
The point is when the CAN bus is under heavy load the CB34-EX will overwrite the (only one CAN packet size) reception buffer.

Then, for me to evaluate correctly the CB34-EX, I'd like to know the receiving packet rate threshold when the CB34-EX starts overwriting packets. Of course these figures do not depend just only on the MC5234 performance but also in the Netburner CAN Library running over it .


Unfortunately not having a hardware RX buffer implies the FlexCAN RX registers will be overwritten when:
( CAN bus inter package delay ) < ( uCOS interrupt latency + the time needed for moving the received frame from the FlexCAN registers to the uCOS FIFO)

On the other hand if the netburner would add a simple SJA1000 we’d get a hardware RX FIFO buffer able to hold up to 6 CAN Frames (8 data bytes each) and now the equation for an overwritten RX buffer is something like:
6 * ( CAN bus inter package delay + CAN Frame "total" bits/ Bus speed in bps ) < (uCOS interrupt latency + time needed for moving the received frames from the SJA1000 RX FIFO buffer to the Netburner uCOS FIFO)

The difference says it all…


pat

[donericb50]

I've used the CAN capabilities on the 5282 for about 4 years and the 5234 for about 18 months and they work fine for me. I think that this is because I use global filtering and channel assignment features to limit the bus traffic to the parameters that I wish to monitor. By creating a high priority dedicated task for servicing the incoming CAN stream I have no problem with dropouts on 250,000Baud CAN2.0b buses even using the 5282 with the 65Mhz clock. I do not have experience with 500K bus speeds. Perhaps someone else can address this.
The CAN interface feature ( flexcan ) is a part of the coldfire chip architecture so there is no additional cost to have it. All the details of its operation are included in the MCF5282 user manual in chapter 25 and the MCF5234 in chapter 21. These are in the documentation subdirectory labeled \docs\FreescaleManuals in the latest installation. The addition of a SJA1000 would mean new board layout, larger board, and additional cost for the CAN chip, board manufacture and assembly.

[patpat]

considering CAN 2.0b dataframes (and disregarding bit stuffing)

the smallest dataframe is 1+29+6+0+16+2+7= 61 bits
The biggest dataframe is 1+29+6+8*8+16+2+7= 125 bits

Considering a 1Mb/s bus

the smallest dataframe takes on the bus => 61 uS
The biggest dataframe takes on the bus=> 125 uS

That tells me that the worst case scenario is a bus load = 100% (delay between consecutive dataframes = 0 Sec) and the affluence of just only the shortest dataframes ( 0 data bytes)
On this situation we have 61uS or less for retrieving the CAN packet from the FlexCAN registers and moving them to the Netburner uCOS FIFO before the next CAN dataframe arrives.
If the OS take longer that 61uSec on doing that there’ll be overwritten packages.

Despite there are many projects that can be done using Netburner it would be good getting some quantitative figures.
Does anybody knows how long it takes from the occurrence of the FlexCAN RX interrupt to get the CAN packet into the uCOS FIFO? How does this figure compare to 61 uSec ?

Pat


PS:
About cost I agree with donericb50, the point is tryng to get a platform exactly as the CB34-EX but able to deal with a 100% bus load. On a CAN arena who cares having a CPU @ 150 Mhz if we cannot deal with a 100% 1Mb/s bus ?

[rnixon]

Even if you have a h/w buffer, if you have an overrun issue there is always the possibility it could be sustained long enough to have a problem as well. I would not consider it a robust system to rely on a 64 byte fifo in h/w, rather than a overall system design with low latency to keep up in the first place. donericb50 has the right idea, use a high priority task or interrupt to handle incoming data. Seems likely this would be the same concept even with the small h/w buffer. Even if you did miss one, isn't it part of the CAN spec to handle that?

There is a lot of async. stuff going on in a network application, so the only timing that matters is how fast *your* specific application can handle the data. For the largest packet size the 64 byte buffer can only buffer up to 4 messages. If you system is not fast enough, your still going to lose data for a sustained full load. A 150MHz processor is fast enough. I would be wary of any engineer who claimed a 4 message buffer would solve his/her full load issues, that just means the product will appear to work in the lab, but fail in the field.

[lgitlitz]

considering CAN 2.0b dataframes (and disregarding bit stuffing)

the smallest dataframe is 1+29+6+0+16+2+7= 61 bits
The biggest dataframe is 1+29+6+8*8+16+2+7= 125 bits

Considering a 1Mb/s bus

the smallest dataframe takes on the bus => 61 uS
The biggest dataframe takes on the bus=> 125 uS

That tells me that the worst case scenario is a bus load = 100% (delay between consecutive dataframes = 0 Sec) and the affluence of just only the shortest dataframes ( 0 data bytes)
On this situation we have 61uS or less for retrieving the CAN packet from the FlexCAN registers and moving them to the Netburner uCOS FIFO before the next CAN dataframe arrives.
If the OS take longer that 61uSec on doing that there’ll be overwritten packages.

Despite there are many projects that can be done using Netburner it would be good getting some quantitative figures.
Does anybody knows how long it takes from the occurrence of the FlexCAN RX interrupt to get the CAN packet into the uCOS FIFO? How does this figure compare to 61 uSec ?

Here are the rough latency calculations from a benchmark application I posted to the group. The interrupt latency on any product with a 70 or 34 processor is about 4.59uS if SRAM is not enabled. By default SRAM is enabled and the interrupt latency is 0.83uS. If the task stack that is current is not located in SRAM but all other OS variables are in SRAM then the latency is somewhere between these two latencies.

I think this should be enough overhead to meet the smallest CAN packet size with no data. Also, one of the first things done in the receive ISR is locking the CAN message buffer so it can not be overwritten. The time required to copy the data is not needed in the latency equation.

-Larry

[patpat]

Even if you have a h/w buffer, if you have an overrun issue there is always the possibility it could be sustained long enough to have a problem as well. I would not consider it a robust system to rely on a 64 byte fifo in h/w, rather than a overall system design with low latency to keep up in the first place.

As I said before, I’d like to move this conversation from the speculative arena to the factual world; do you have any figures supporting your “considerations”?

The SJA1000 64 byte RX buffer gives you about 8 packets x 61uSec = .5 mSec to get the RX buffer empty w/o overwriting packets worst condition… that’s EIGHT times FlexCAN performance….
In order to know if 64 bytes are good enough we have to compare 61 uSec and .5 mSec with the time that uCOS takes to move the received packets to the uCOS FIFO.
At this point we need figures.

donericb50 has the right idea, use a high priority task or interrupt to handle incoming data. Seems likely this would be the same concept even with the small h/w buffer.

in order to know if it's the "right" approach I have to know it's a "good enough" approach.... so far we do not know...

Even if you did miss one, isn't it part of the CAN spec to handle that?

CAN as defined by BOSCH/ ISO 11898 does not mention any corrective action for missing or buffer overwritten packages

There is a lot of async. stuff going on in a network application, so the only timing that matters is how fast *your* specific application can handle the data. For the largest packet size the 64 byte buffer can only buffer up to 4 messages. If you system is not fast enough, your still going to lose data for a sustained full load. A 150MHz processor is fast enough. I would be wary of any engineer who claimed a 4 message buffer would solve his/her full load issues, that just means the product will appear to work in the lab, but fail in the field.

I'm an EE and I would even say a 2 message buffer solve my problem if I got the figures supporting my sayings.

[patpat]

Here are the rough latency calculations from a benchmark application I posted to the group. The interrupt latency on any product with a 70 or 34 processor is about 4.59uS if SRAM is not enabled. By default SRAM is enabled and the interrupt latency is 0.83uS. If the task stack that is current is not located in SRAM but all other OS variables are in SRAM then the latency is somewhere between these two latencies.

This is good info, the Int Latency is about 10% of the available time; thanks. But now we need to add the time that the task takes for moving the received CAN packet from the FlexCAN registers to the uCOS FIFO...

I think this should be enough overhead to meet the smallest CAN packet size with no data.

No really, there are info about Packet ID, time stamp, etc that have to be moved to the uCOS FIFO; that takes a time that so far we do not know.

Also, one of the first things done in the receive ISR is locking the CAN message buffer so it can not be overwritten. The time required to copy the data is not needed in the latency equation.
-Larry

That does not help much, a locked buffer preserves the received packet but not the one that arrives before the buffer is unlocked....
We need the time involved on moving the received CAN packet to the uCOS FIFO..
Pat

[rnixon]

Its not 8 times performance, and it only works if the processor can catch up, which may not happen if you have a sustained full load. Although there is some benefit to reading two or more messages at one time in an isr/task if they are buffered, you will still eventually run out of buffer on a sustained full load if the system can't keep up. If this is still a concern you can either test it yourself on a CB34EX, or maybe build a system using a NetBurner module like the Mod5234 and add the buffer chip you like to it. Wouldn't that approach work?