英飞凌Tc275使用记录：Can邮箱号确认与Busoff寄存器设置方法

目录

1、消息后处理

2、消息暂存

3、Tc275 Busoff的寄存器手动处理

---

1、消息后处理

        消息对象成功接收或发送帧后，可以通知CPU对消息对象执行后处理。MultiCAN+模块的后处理由两个部分组成:

1. 消息中断触发后处理。
2. 消息挂起寄存器将挂起的消息中断收集到一个公共结构中进行后处理。

      消息后处理，一般都会到CanIf这个层面

        当接收到的帧存储到消息对象中或成功传输帧时，可以发出消息中断。对于每个消息对象，可以生成一个发送中断和一个接收中断，并将其路由到16条can中断输出线之一(如下图所示)。接收中断也发生在由FIFO或网关动作引起的帧存储事件之后。在消息对象状态寄存器中的状态位TXPND和RXPND总是在成功发送/接收后设置，无论是否使能各自的消息中断。

        提供了消息对象的第三个FIFO完全中断条件。如果位场为MOFCRn。设置了OVIE(溢出中断使能)，FIFO完全中断将根据实际消息对象类型被激活。

        在接收FIFO基础对象(MOFCRn)的情况下。MMC = 0001)， FIFO完全中断被路由到中断输出线INT_Om(由发送中断节点指针MOIPRn.TXINP定义)。

        在传输FIFO基础对象(MOFCRn)的情况下。MMC = 0010g)， FIFO完全中断被路由到中断输出线INT_Om，由接收中断节点指针MOIPRn.RXINP定义。        

2、消息暂存

        当一个消息中断请求产生时，在一个消息暂挂寄存器中设置一个消息暂挂位。有8个消息等待寄存器，MSPNDk (k= 0-7)，每个寄存器有32个等待位可用。下图给出了在芯片上实现最多8个message pending Registers的情况下，message pending bits的分配示意图。

        也是刚发现的一个地方，每个邮箱都可以设置为是否为中断的形式，见如下寄存器。

例如：TC275可以实现255个硬件邮箱的配置，假设第0、1、2、3、4、5、共6个发送邮箱使能中断，只需要配置

MOFCR0 = 0x00020000

MOFCR1 = 0x00020000

MOFCR2 = 0x00020000

MOFCR3 = 0x00020000

MOFCR4 = 0x00020000

MOFCR5 = 0x00020000

MSIMASK = 0x3F也就是 11 1111B，共6个bit在使用即可。

使用接收报文的话MSIMASK也是这样子的，获取邮箱号的寄存器是

一旦获取ID之后，也就是在中断里面执行的内容，需要清除对应的暂存寄存器，也就是

在上面的图示里面显示了，MSPND总共有8个，寄存器是32位的，代表着有256个邮箱。

例子里面用了6个邮箱（0~5），属于MSPND0，不管是发送还是接受，都需要在中断里面清除对应的MSPND位，例如3邮箱也就是将MSPND0的第三个bit清零即可。在中断里面配置的时候，可以通过MSID寄存器来读取邮箱号。

举个邮箱接受中断的例子

For(i = 0; i < 8; i++)/*此处为了轮询MSPND的255个邮箱，哪个在进中断来着*/
{
    MSIMASK = MASK[i];/*注意一下初始化的时候MASK[0] = 0x3F,其他的等于0，因为我们只初始化了0-5共6个邮箱*/
    While(MSID[i] ! = 0x00000020)/*MSID的默认值为0x20,所以当不等于0x20的时候就是已经等到邮箱寄存器准备好了*/
    {
        MailBoxId = 32*i +MSID[i];	/*获取邮箱号*/
        RXFunction(MailBoxId ); /*接收或者发送到CanIf的函数，函数内部用户根据MailBoxId 看下是用来做诊断还是XCP之类的*/
        MSPND[i] = ~(1<

3、Tc275 Busoff的寄存器手动处理

主要设置两个节点寄存器

下图寄存器显示了busoff与否，假设为1，就是BUSOFF

BusoffState = NCR & 0x0000 0001 ;

ALERT寄存器

ALER = ((NSR &0x0000 0020) >>5)

上述这两个寄存器为1表示处于busoff状态

Illd里面的解释如下：

/*

Bus-off error check:

---------------------

The ALERT bit is set upon the occurrence of one of the following events

(the same events which also trigger an alert interrupt if ALIE is set):

1. A change of bit NSRx.BOFF

2. A change of bit NSRx.EWRN

3. A List Length Error, which also sets bit NSRx.LLE

4. A List Object Error, which also sets bit NSRx.LOE

5. Bit INIT has been set by hardware

Note:

- List error occurance is ruled out because list is not changed at run

time by the driver. So LOE and LLE bits need not be checked.

- Points 1,2 and 5 constitute BusOff condition

In the driver EWRN level is set to be equal to BOFF error level.

So when EWRN triggers ALERT bit, it also means bus-off.

When bus-off happens, INIT is set by "hardware".

So is it enough to check ALERT bit alone to see if there was bus-off

event triggered? No. Resetting of EWRN and/or BOFF also triggers

ALERT bit to be set. To differentiate this scenario, both ALERT

and INIT bit should be checked.

*/

清除busoff的时候进行如下操作

NSR = 0x0000 03DF;

NCR = NCR & (~ 0x0000 00041);

以此达到清除busoff重启对应节点的目的。