LAUNCHXL-F280039C: CanFd bus off

Hi,

Could you check the contents of MCAN_ECR register to see which errors are accumulating before CAN bus goes into bus off condition?  I have not encountered any bus off condition when using mcan_ex9_transmit example (with brs=1; 500Kbps NOM; 1 Mbps data - original test settings) when using PCAN to receive data from the F280039 LaunchPad.

Regards,

Joseph

Hi Joseph，

This is the information in the ECR register, and the TEC register is almost filled

    //
    // Configure the MCAN Module.
    //
    MCANConfig();

    while(1)
    {
        //
        // Write message to Message RAM.
        //
        MCAN_writeMsgRam(MCANA_DRIVER_BASE, MCAN_MEM_TYPE_BUF, loopCnt,
                         &txMsg[loopCnt]);

        //
        // Add transmission request for Tx buffer 0
        //
        HWREG(MCANA_DRIVER_BASE + MCAN_TXBAR) = 0x00000001;

        //
        // Wait till the frame is successfully transmitted (and ACKnowledged)
        // "Tx Buffer Transmission Occurred" register is polled.

        while(HWREG(MCANA_DRIVER_BASE + MCAN_TXBTO) == 0x00000000)
        {
        }

        DEVICE_DELAY_US(1000000);
//        //
//        // Stop Application.
//        //
//        asm("   ESTOP0");
    }

Change the single send from the example to send every 1s

After the PC tool receives dozens of data, Canfd enters the bus off state

Hi,

The incrementing error is TEC which is during transmission.  This counter increments if there is a transmission error and transmission error occurs if there is no ACK sent by any receiving node.  With BRS=0, your receiving node (GCAN) is able to receive all data without errors, meaning that GCAN is able to send back ACK for all the frames sent at 1Mbps NOM and data rate.  Can you check on your GCAN settings to ensure that with BRS=1, NOM bit setting is 500Kbps and data rate is also 1Mbps?  This should be consistent with the MCAN settings on the Launchpad otherwise GCAN may not be able to send an ACK signal for a sent frame with NOM rate of 500Kbps and data rate of 1Mbps.

Regards,

Joseph 

Hi Joseph，

Do you mean that the TEC count may have increased due to the inability of the GCan tool to reply ACK bits for each frame?

Due to the imperfect function of GCan tool, it cannot display the error frame information in Canfd mode, so I grabbed some error frame data waveforms

data lenth = 1;

data[0] = 0x01;

txMsg[loopCnt].mm       = 0x81U;

yellow:CAN-RX;

green:CAN-TX;

blue:CANL-H;

In this image, it took the fourth send to succeed

The waveform is expanded as follows:

first frame:

second,thridly frame

Fourth frame

The first frame seem to be a data frame error or crc?

The second、thridly frameframe seem to be last few bits error,is ACK or other?

The fourth frame is the complete correct frame

Hi,

It is kind of hard to identify the parts of the frame on the scope shot.  Not sure if the scope you are using has the ability to decode CAN frames.  Most of the scopes have this ability and this is capability useful in identifying errors.  See example scope shots used in app note SPRACE5 .  There is also an example showing how ACK works.  Frame illustrations in the app note is for DCAN but it is applicable to CAN-FD.  There are subtle differences in the control field but rest are same.  It would be good if you can use the scope's capability to decode the CAN frame.

Regards,

Joseph