• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 83 subscribers
  • Views 961 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28335 - eCAN: Unexpected Cessation of Transmit Operation

Giles Robnson
Expert 1495 points

This new advisory has appeared in SPRZ272I "TMS320F2833x and TMS320F2823x DSC Silicon Errata" (Nov. 2015)

Is there any more information on the problem?

When it happens, does it affect both CAN peripherals, or is a problem on one independent of the other?

Regards.

  • 0
    TI__Guru* 95315 points
    It is the latter. i.e. problem on one is independent of the other.
  • 0 in reply to Hareesh Janakiraman
    Expert 1495 points

    That's good to know.  Thanks.


    Also, I'd meant to ask, is there any known way of generating this problem?  Or circumstances that make it likely to happen?  Clearly such information would be very useful.

    Regards.

  • 0 in reply to Giles Robnson
    Expert 1495 points
    AND ..
    If a CAN stops transmitting, what happens to the CANTRS register? Does the peripheral never clear the bit, allowing the CPU to see the Tx stop?
    Or is that bit cleared, even though nothing is transmitted?

    Regards.
  • 0 in reply to Giles Robnson
    TI__Guru* 95315 points
    TRS bit is cleared only upon successful transmission of a frame, so it stays set. This condition could be detected by using the Message-Object-Time-Out (MOTO) feature of the eCAN module. This way, the checking is automatic without CPU burden.
  • 0 in reply to Hareesh Janakiraman
    TI__Guru* 95315 points
    Giles,
    Just to put things in perspective, the eCAN module was first introduced in the c2000 family on the F281x devices about 13 years back. Subsequently, it was used in more c2000 devices such as F280x, F2833x, C2834x, F2803x & F2806x. Till date , we have tens of millions of devices shipped, with hundreds of customers using these devices. Thus far, we have only had 3 reported instances of this issue. Also, this issue was found by customers either during development or shortly after deployment. We have not heard of a scenario where this issue was observed long after a product has been deployed in the field. In at least one instance, longer bus lengths appeared to exacerbate the issue. This issue is extremely difficult to reproduce at will (if at all). The objective of putting this in the errata (in addition to alerting users to this very rare occurrence) is to explain the workaround and encourage customers to implement this in new systems going forward.

    If I could be of further assistance, you could get in touch with me through your TI (or distributor) FAE.