S32K144 CANFD BUSOFF

[NanMo1]

I configured the CANFD application for S32K144. To handle the busoff situation, the following code was added. It was found that the sending status could be restored after a single short circuit. However, if there were multiple consecutive short circuits, it was eventually discovered that the message sending stopped. What is the reason for this?

it is my code 

CANFD_BUSOFF = (CAN0->ESR1 & CAN_ESR1_FLTCONF_MASK) >> CAN_ESR1_FLTCONF_SHIFT;

//BUSOFF STATE
if(CANFD_BUSOFF == 0x03)
{
// 置位软件复位位
CAN0->MCR |= CAN_MCR_SOFTRST_MASK;

//等待复位完成（硬件自动清除此位
while(CAN0->MCR & CAN_MCR_SOFTRST_MASK) {}

//写1清除所有错误标志
CAN0->ESR1 = 0xFFFFFFFF;

//反初始化驱动
FLEXCAN_DRV_Deinit(INST_FLEXCAN_CONFIG_1);

//重新初始化驱动和邮箱（完全重现启动配置）
HAL_setupCAN();
}
else//NORMAL STATE
{
//数据接收
HAL_readCAN_Message(&canMsg_handle->RX_0x0101); //调用驱动接收报文

//数据发送
canMsg_handle->TX_0x0201.msgData[0] = canMsg_handle->RX_0x0101.msgData[0];
canMsg_handle->TX_0x0201.msgData[1] = canMsg_handle->RX_0x0101.msgData[1];
canMsg_handle->TX_0x0201.msgData[2] = canMsg_handle->RX_0x0101.msgData[2];
canMsg_handle->TX_0x0201.msgData[3] = canMsg_handle->RX_0x0101.msgData[3];
canMsg_handle->TX_0x0201.msgData[4] = canMsg_handle->RX_0x0101.msgData[4];
canMsg_handle->TX_0x0201.msgData[5] = canMsg_handle->RX_0x0101.msgData[5];
canMsg_handle->TX_0x0201.msgData[6] = canMsg_handle->RX_0x0101.msgData[6];
canMsg_handle->TX_0x0201.msgData[7] = canMsg_handle->RX_0x0101.msgData[7];

canMsg_handle->TX_0x0201.msgData[21] = canMsg_handle->RX_0x0101.msgData[21];
canMsg_handle->TX_0x0201.msgData[22] = canMsg_handle->RX_0x0101.msgData[22];
canMsg_handle->TX_0x0201.msgData[23] = canMsg_handle->RX_0x0101.msgData[23];

canMsg_handle->TX_0x0201.msgData[61] = canMsg_handle->RX_0x0101.msgData[61];
canMsg_handle->TX_0x0201.msgData[62] = canMsg_handle->RX_0x0101.msgData[62];
canMsg_handle->TX_0x0201.msgData[63] = canMsg_handle->RX_0x0101.msgData[63];
HAL_sendCAN_Message(canMsg_handle->TX_0x0201); //调用驱动发送报文
}

[PetrS]

Hi,

it’s not entirely clear how frequently you are checking the fault state or what the HAL functions are doing internally.

In general, I recommend relying on the Bus-Off flag instead of the FLTCONF field, and enabling the Error/Bus-Off interrupt for better handling.

You can refer to the following example for a simple implementation:
https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K144-FlexCAN-TX-RX-Error-ISR-test-S32DS2...

After Bus-Off is detected, it’s not always necessary to perform a SOFT reset followed by deinit/init of the module. If your application requires reinitialization, just use deinit/init.
Alternatively, you may simply abort the message as shown in the example.

BR, Petr

[NanMo1]

I reviewed the sample code and found that it only stops sending the message to mailbox 1 when there is a failure. The description states that the sending of messages resumed after the short circuit fault was removed. The main reason for adding the reset was that if I didn't handle the sending status, the system would freeze and no more messages would be sent. Even if I added this reset processing, the message sending status would stop and not recover after a certain CANH and CANL short circuit occurred.

[NanMo1]

I've identified the problem. My colleague initially registered the callback function and then cleared some flags after the busoff operation. This caused the SDK state machine to be unable to handle the state by itself.