S32K324 CANFD报文接收超限分析

babylemon828

前言

问题描述

原因分析

问题处理

总结

前言

随着汽车软件复杂度越来越高，传输的数据越来越多，CAN总线到CANFD总线已经是发展的必然了。CANFD总线中单个报文ID可以传递至多64byte数据，对CAN Driver来说，所需的MCU资源也将变多，对于NXP S32K3的CAN模块，如果是CANFD报文，能够接收的ID数量将大大减少。本文就基于开发中遇到的问题，来进行分析，并给出一个可行的解决方案。
问题描述

将MCAL中的CAN升级为CANFD后，Control需要配置CanRamBlock，将RamBlock全配置为64byte之后，再配置mailbox时，会报RamBlock溢出
报错示例如下：

报错之后无法生成代码，报错意思是RAM_BLOCK_1超了
原因分析

要弄清原因，需要搞清楚S32K324的FLEXCAN Canfd的关系。
如下图所示：


每个FlexCAN支持的buffer不一样，只有CAN0支持的最大，在CANFD的模式下，可以到21个mailbox
然后看下Ram block的定义
简单解释下：对于S32K324,有三个Ramblock，每个ramblock可以配置payload,不同的payload即表示能支持的最大mailbox,同时，payload越大，canfd支持传输的数据越多

通过FDCTRL为每个Block分配payload


payload只支持4种配置，8，16，32，64

•选择8字节payload时:−Block R0: 0x0080~0x027F, 512bytes，分配给MB0 ~ MB31。
−Block R1: 0x0280~0x047F, 512bytes，分配给MB32 ~ MB63。
−Block R2: 0x0480~0x067F, 512bytes，分配给MB64 ~ MB95。
•当选择64字节的payload时:
−Block R0: 0x0080~0x0277, 504bytes，分配给MB0 ~ MB6。
−Block R1: 0x0280~0x0477, 504bytes，分配给MB7 ~ MB13。
−Block R2: 0x0480~0x0677, 504bytes，分配给MB14 ~ MB20。
由上面的定义，可以知道之前报错的具体原因：
Ramblock1配置了payload为64，导致mailbox最大只有7个，而我们配置了8个，所以超了。

问题处理

知道了Ramblock的原理，如果全部配置为64byte,则最多只能配置21个mailbox(包括Tx和Rx)，但OEM给的通信矩阵中超过了这个数量。如何解决这个问题呢？
换芯片估计很难了。
我的思路是从需求出发，将通信矩阵中的每个报文的DLC统计（实际除了Nm报文，Xcp报文，其他应用报文和诊断报文，都是64byte），同时将实际使用的信号所在的位置记录，统计所需的最大报文长度。
统计完后，就可以分配Block了，示例:
分配2个64byte的Ramblock，1ge 16byte的Ramblock,可以装载14个64byte的报文，21个16byte的报文。
这样，我们最大可以处理35个Canfd报文。

然后按照统计好的数据，给对应的Mailbox分配Ramblock即可,此处示例分配给RAM_BLOCK_1


总结

这种方案不是完全解决的方案，如果需求的CAN报文数量更多的话，可能也无法满足。所以在最开始MCU选型的时候，最好将CAN的报文容量也考虑进去，而不是简单的只看CAN通道和是否支持CANFD，包括各路CAN的容量是不是一致的。（S32K3就只有CAN0能支持payload64到21byte）.如果在原理图设计阶段，没有选择CAN0，也是可能导致问题的原因。
参考：
17_S32K3xx_Communication_Modules_FlexCAN_Training.pdf