• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 83 subscribers
  • Views 439 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F280049: How to clear the error of the DCAN

Cherry Zhou
Mastermind 22235 points
Part Number: TMS320F280049

Hi team,

Here's an issue from the customer may need your help:

The Dcan is stuck frequently. Added a sentence to reset can at polling time:

//===================================================================

status_err = CAN_getStatus(CANA_BASE);

temp1= status_err & CAN_STATUS_BUS_OFF;
temp2= status_err & CAN_STATUS_EWARN ;
temp3= status_err & CAN_STATUS_EPASS ;

if( (temp1==CAN_STATUS_BUS_OFF) || (temp2== CAN_STATUS_EWARN) || ( temp3== CAN_STATUS_EPASS) )
{
CAN_Reset(CANA_BASE);
//CAN_enableController(CANA_BASE);
}

//===================================================================

Can_Reset(CANA_BASE); is a self-encapsulated function that supports the SWR to reset can, but the fault still remains; So checking it with the simulation, it's find the init bit of CAN_CTL, and then add CAN_enableController(CANA_BASE); to reset the init bit.

However, after reproducing the fault,  it is found that the EWarn and EPass bits of CAN_ES are set and that the CAN_RP is set inside CAN_ERRC. Can_REC is full (0x7F). The way to reproduce this issue is to set the can baud rate to 500 k, then drop a packet at 1000 K, and then return. It's find that can cannot working anymore.

The customer would like to know how to avoid such issue? And they also guess Can not work should be related to the CAN_ERRC counter overflow. PMD of CAN_CTL is 0101, that is Parity function disabled.

Could you help check this case? Thanks.

Best Regards,

Cherry

  • 0
    TI__Expert 6035 points

    Hey Cherry, 

    We are looking into it and will get back to you soon.

    Thanks, Sahil.

  • 0 in reply to Sahil Deshpande
    TI__Mastermind 22235 points

    Hey Sahil,

    Understood and expect your response!

    Thanks,

    Cherry

  • 0 in reply to Cherry Zhou
    TI__Guru* 95315 points

    Cherry,

                    The post is confusing. Is the CAN node going into bus-off because of errors on the bus or is the bus-off condition deliberately created with mis-matched bit-rates? 

    If the BO happens because of errors on the bus, customer needs to check why the node is going into BO in the first place. Bus-off is a severe error condition. Customer should investigate the root-cause of the errors during transmission. In a properly designed/configured network, communication errors should be rare. It could happen due to external noise, but the bus should recover on its own once the disturbances vanish. That is how the protocol is designed. 

    Assuming the node went into BO (either because of errors or because of a deliberate experiment), the node has to wait a minimum of 128x11 recessive bit-times before it can be brought out of BO. This time cannot be shortened, as it is defined by the CAN protocol. Please wait for this time before you attempt to enable the controller.