TMS320F280049C: CAN Bus on time too long and not fixed after clear CAN_CTL Init bit

Strong,

              Sorry I don’t understand what the issue is. Are you saying the CAN module is taking too long to recover after a bus-off condition? The shortest time for recovery (after the cause of the bus-off condition is removed) is [129 * 11]bit-times. At 500 kbps, this translates to 2.8 ms.

Hareesh,

Yes, customer did the bus off recovery by clearing Init bit by manual, when set DAR bit for Automatic Retransmission disabled, the recovery time is too long since call  CAN_sendMessage function and clear Init bit, sometime the time is over 300ms, and it is not a fixed time.

Could you help reproduce this issue with example posted? just using two launchpad, short the CANH and CANL by manual for a proper time to bus off, and disconnected to remove this cause for bus off. then see the waveform of CANH and GPIO0 to check the recovery time.

Strong,

I need to create this setup and look through your code. Will take a day or two.

Strong,

I don't see this issue. I modified your test case slightly for the following reasons:

1. In my board, an L.E.D is connected to GPIO65, so I changed the GPIO to it.
2. I modified the "if" block for bus-off to make the scope capture easy.

I correctly see a delay of 2.8 mS from the time I initiate transmit. I think the problem could be the way you generate bus-off. Shorting CANH & CANL lines manually cannot provide you a controlled way of generating a BO condition because you will be doing it for a few seconds. That is, you have no control over precisely when you enter/exit bus off. I took care of this by providing a 3 second delay after the node enters bus off (enough time for me to remove the short between the CAN bus lines) and initiating only one transmit after bus off recovery. Please let me know if you agree with my analysis.

Hi Hareesh,

Thanks for your support.

Customer did more test based on your code that sent me, they do a slight modification as below and still found an issue.

1. Enable retransmission frame.

   //HWREGH(CANA_BASE + CAN_O_CTL) |= CAN_CTL_DAR;

2. Send the data 3 times as below showed.

        CANMessageSet(CANA_BASE, 1, &sTXCANMessage, MSG_OBJ_TYPE_TX);
        (*(unsigned long *)ucTXMsgData)++;
        DELAY_US(2000);

        CANMessageSet(CANA_BASE, 1, &sTXCANMessage, MSG_OBJ_TYPE_TX);
                        (*(unsigned long *)ucTXMsgData)++;
                        DELAY_US(2000);

                        CANMessageSet(CANA_BASE, 1, &sTXCANMessage, MSG_OBJ_TYPE_TX);
                        (*(unsigned long *)ucTXMsgData)++;

The is little delay for the retransmission frame, but between retransmission frame and first 3 frames, there will have about 22ms delay as below showed, which is too long for them?

Could you help take a check if this is a issue or just a normal operation?

Strong,

     How is the bus-off condition generated? Is it still be shorting the bus manually? 

Hi Hareesh,

Yes, it still be shorting the bus manually.

Strong,

    We released a new app.report last week. It is capable of generating different types of errors. Let me investigate if we could re-purpose it for this issue.

Hareesh ，

Thanks for your support, Do you have a chance to reproduce this issue?

Strong

Strong,

No, I am yet to reproduce this.