CAN-FD controller vs channel clarification

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Vai
Level 1
Level 1
5 sign-ins First reply posted First question asked

Hi, 

Going thoroughly through CYT4BF datasheets and TRM, I see that the MCU has 2 M_TTCAN controller with 5 channels each. What are the limitations of such an arrangement? Typically, MCUs use a 1:1 mapping controller to channel. 

 

Basically I'm looking to answer these questions:

1. Does this arrangement have any hidden limitations that are not clear?

2. Can all channels operate independently at a different bit rate at full CAN-FD capacity of 5Mbps at the same time (that is - all 5 channels connected to active peripherals operating full speed of 5Mbps at the same time)?

3. If there are shared functions that cause performance impacts, what are they?

 

Thank you for your support!

Vai

 

0 Likes
1 Solution
Kavya_B
Moderator
Moderator
Moderator
100 replies posted 10 likes given 25 solutions authored

Hello Vai,

Please find answers to your questions below:

1) The main constraint while using all the channels available is shared message RAM. In addition, there are some clock limitations.
In the same instance, clocks for all CAN channels must be synchronous. This may be an additional limitations for the channels in the same instance if asynchronous clocks between different instances are to be be used.

2) Configuration-wise, it should be possible as far as constraint explained in (1) is taken care.

3) Shared message RAM may cause performance impacts. But, the through put of the RAM is high enough.
It wouldn't be a big impact.

 

Thanks,

Kavya

View solution in original post

0 Likes
5 Replies
Kavya_B
Moderator
Moderator
Moderator
100 replies posted 10 likes given 25 solutions authored

Hello Vai,

Please find answers to your questions below:

1) The main constraint while using all the channels available is shared message RAM. In addition, there are some clock limitations.
In the same instance, clocks for all CAN channels must be synchronous. This may be an additional limitations for the channels in the same instance if asynchronous clocks between different instances are to be be used.

2) Configuration-wise, it should be possible as far as constraint explained in (1) is taken care.

3) Shared message RAM may cause performance impacts. But, the through put of the RAM is high enough.
It wouldn't be a big impact.

 

Thanks,

Kavya

0 Likes
Vai
Level 1
Level 1
5 sign-ins First reply posted First question asked

Hi Kavya -

Thanks for your clear responses. I'd like to clarify (1) a little deeper. Could you explain the synchronous nature of CAN channels in a given instance? Where does this limitation come from and what does it mean in practice?

Thanks

Vai

0 Likes
Kavya_B
Moderator
Moderator
Moderator
100 replies posted 10 likes given 25 solutions authored

Hello Vai,

As you can see from the explanation given in Traveo II Arch TRM, each M_TTCAN channel has two clock inputs: PCLK_CANFD[x]_CLOCK_CAN[y] and CLK_GR5. The PCLK_CANFD[x]_CLOCK_CAN[y] (clk_cclk) is used for the CAN (or CAN FD) operation. The CLK_GR5 (CLK_SYS) is used for everything except CAN operation, such as register accesses and SRAM accesses. The peripheral clock (PCLK_CANFD[x]_CLOCK_CAN[y]) is the input for CAN FD operation which is being referred in the limitation. The frequencies set for each CAN channel should be integer multiple of the peripheral clock input. This is a limitation comes from IP interface specifications.

Thanks,

Kavya

0 Likes
Vai
Level 1
Level 1
5 sign-ins First reply posted First question asked

Thanks Kavya - PCLK_CANFD[x]_CLOCK_CAN[y] is per channel peripheral clock. Would this affect anything between channels? Since these clocks are independent for each channel, their configuration/use is also independent?

The register/core clock CLK_GR5, I understand.

 

Thanks

Vai

0 Likes
Kavya_B
Moderator
Moderator
Moderator
100 replies posted 10 likes given 25 solutions authored

Hello Vai,

Here, the clock constraint comes from CANFD IP, not from peripheral clock settings. PCLK_CANFD[x]_CLOCK_CAN[y] you set for CANFD channels are independent of each other with respect to clock configuration. But for the proper operation, you cannot chose random frequencies on PCLK_CANFD[x]_CLOCK_CAN[y] clock inputs you set for CANFD channels of one M_TTCAN instance.

The frequencies you configure for PCLK_CANFD[x]_CLOCK_CAN[y] clock inputs which are the operational clock inputs for CANFD channels should be integer multiples.

Thanks,

Kavya

0 Likes