1.问题描述
问题：导入DBC后，配置了两个Basic CAN用来接收普通CAN报文。Davinci工具校验通过后上板测试发现ECU能发出CAN报文，但是接收不到CAN报文，且CAN报文的接收中断都没有产生。
分析：能正常发送报文，则CAN收发器肯定是没有问题的，CAN协议栈之上的BSW模块也是没有问题的，问题肯定还是出在CAN Driver模块。
2.直接原因
直接原因：一个Can Controller配置了两个Rx Basic CanHardwareObjects就一定要勾选Multiple Basic CAN Objects这个配置选项，实际是没有勾选这个配置选项的。
初步分析：因为一个一个Can Controller配置了两个Rx Basic CanHardwareObjects后就会启动TC3xx芯片的Rx FIFO1, 没有勾选Multiple Basic CAN Objects这个配置选项就不会使能FIFO1的中断，所以使用Rx FIFO1接收的CAN报文就不能产生接收中断。
详细的代码和原理分析见后文。
注意：TC3xx芯片的一个CAN Controller（CAN uinit的一个CAN Node）最多可以配置两个Rx Basic CAN.因为TC3xx芯片只有两个物理Rx FIFO.
4.芯片原理
TC3xx芯片CAN模块的详细介绍请参考《TC3xx芯片CAN模块详解》一文。
TC3xx芯片的CAN模块有两个物理Rx FIFO. FIFO 0和FIFO 1.
正常情况下CAN Controller接收到报文后先进行硬件过滤器过滤，过滤通过后，就会往报文配置的Rx FIFOx(x=0, 1)送。
FIFOx(0, 1)接收到报文后一般都产生New Message Interrupt, 产生中断的前提是需要RFONE和RF1NE配置使能。
RFONE: Rx FIFO 0 New Message Interrupt Enable
RF1NE: Rx FIFO 1 New Message Interrupt Enable
5.代码分析
Rx FIFO 0的New Message Interrupt默认是Enable的，而Rx FIFO 1的New Message Interrupt的使能需要配置C_ENABLE_MULTIPLE_BASICCAN参数。
而C_ENABLE_MULTIPLE_BASICCAN参数的定义就和Davinci上的Multiple Basic CAN Objects配置选项一一对应。
也就说，一个CAN Controller配置使用了两个Rx Basic CAN就会启用FIFO 0和FIFO1，而FIFO 1使能接收中断的前提是配置了Multiple Basic CAN Objects参数。这也就说本文的根本原因所在了。
5.CAN Driver配置隐藏规则
TC37x芯片有两个CAN Uinit/Module, 一个CAN Unit/Module下有4个CAN Node.一个CAN Unit/Module共用一块Message RAM.假设我们使用一个CAN Unit/Module上的两个CAN Node (Node A, Node B)分析AUTOSAR架构下CAN Controller模块Rx Basic CAN和TC3xx芯片的Rx FIFO的对应关系：
CAN Node A Rx Basic CAN配置数量 | CAN Node B Rx Basic CAN配置数量 | TC3xx芯片的FIFO 0是否使用 | TC3xx芯片的FIFO 1是否使用 |
0 | 1 | Yes | No |
0 | 2 | Yes | Yes |
1 | 0 | Yes | No |
1 | 1 | Yes | No |
1 | 2 | Yes | Yes |
2 | 0 | Yes | Yes |
2 | 1 | Yes | Yes |
2 | 2 | Yes | Yes |
6.总结
本文描述的问题的直接原因就是Multiple Basic CAN Objects参数没有勾选，其背后的原理依赖具体的芯片特性和CAN Driver的实现逻辑。通过本文也反应了一个AUTOSAR MCAL的难点所在，也就说AUTOSAR架构下的MCAL标准概念和具体芯片的对应规则会因芯片不同而不同，但是，往往这些对应规则在MCAL文档中又没有说明，很容易让人迷惑而产生问题。
End
