• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 33 subscribers
  • Views 234 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.

TCAN4550: How the software recognize the case of frequently retransmiting packets and modify, restore the activity of it?

phoebe TAN
Prodigy 30 points
Part Number: TCAN4550

In some case there is no node in the CAN network, maybe the cable is accidentally dropped or nodes are damaged in some reason, TCAN4550 would retransmit the CAN packet forever, which causes PEA in Interrupt Register occurring frequently.

In this case, the handling of PEA interrupt would cost much usage of cpu of host MCU, it would affect the operation of other affair in host MCU.

Furthermore, the Tx Event FIFO New Entry( TEFNE ) in Interrupt Register won't occur even though the EFC has been set in TX Element when transmitting the packet. Neither the Transmision Completed(TC). We have no way to let software recognize this situation.

By the way, we don't want to rudely disable this feature by set DAR in CC Control Register, as we supposed it is a feature of CAN protocol itself.

So, Is there some practice way to prevent the high processing ability comsumption of host MCU? In details, 

  1. how to recognize the situation like this?
  2. how to modify and restore the activity of retransmision to prevent it consumes so much time of MCU?
  • 0
    Prodigy 30 points

    And in this case, the TEC would always be 128 at most, which won't cause bus off happen.

  • +1 in reply to phoebe TAN
    TI__Mastermind 32900 points

    Hi Phoebe,

    I understand your request and the situation you are facing.  I can't think of a setting in the device that would handle this on it's own, but I have some ideas that you could try to implement in the MCU firmware.  You are also correct, the TX Event FIFO will only reflect successfully transmitted messages, but I think you can look at other registers to detect this situation.

    When a message is trying to be transmitted, the bit corresponding to the TX Buffer element is set in the TX Buffer Request Pending (TXBRP) register.  When you receive the PEA interrupt, you could then read the TX Event FIFO and TXBRP registers to determine if the message has transmitted successfully, or is still pending transmission. 

    Perhaps after a couple of polling cycles of the TXBRP the MCU could determine there is an open bus and that it should cancel the transmission at this time so that it can clear stop trying to transmit and try again later.  What criteria you use to determine when to cancel a transmission is up to you, but the idea is that you can chose to cancel the transmission and avoid the repeated and prolonged string of PEA interrupt events from an open bus.

    To cancel a transmission you just need to set the TX Buffer element number bit in the TX Buffer Cancellation Request (TXBCR) register.  Once the message cancellation has occurred, you can see the bit reflected in the TX Buffer Cancellation Finished (TXBCF) register.

    This approach should allow you to detect the situation and prevent it from consuming a lot of MCU time.  But what you after detecting this situation is up to you.  I would think you would still need to implement some sort of retry mechanism after a time delay to see if the bus has been restored.  Or maybe just indicate a faulty bus through an error flag in the MCU, etc. 

    Regards,

    Jonathan

  • 0 in reply to Jonathan Nerger
    Prodigy 30 points

    Hi, Jonathan! Thank you for your answer, it's helpful and detailed. but I want to know more about the TX Buffer Request Pending, TX Buffer Cancellation Request and TX Buffer Cancellation Finished.

    I refer to the manual and find that these register all has serial number for every bit. Does it means they only are valid for Tx Buffer and these registers with different serial number for every bit are only useful for Dedicated Tx Buffer?

    In our configuration, we choose the method that set the transmission topologies as Tx Queue and the count of Dedicated Tx Buffer 0. I found that the Transmision Completed(TC) , which also has serial number for every bit, won't indicate the state of Tx Buffer.

  • 0 in reply to Jonathan Nerger
    Prodigy 30 points

    I have tried your method, it works! TX Buffer Request Pending, TX Buffer Cancellation Request work in my configuration. Thanks!

  • +1 in reply to phoebe TAN
    TI__Mastermind 32900 points

    Hi Phoebe,

    I'm glad I could help and this method works.

    The CAN FD Controller IP in the TCAN4550 was developed by Bosch and is called M_CAN.  This is one of the industry standard controllers and used in many devices and additional or more detailed information can be found in the M_CAN User's Manual published by Bosch.  It wasn't possible or practical to duplicate all of the M_CAN information in the TCAN4550 datasheet, so the M_CAN User's Manual should be used as a supplemental resource for the M_CAN controller.  More detailed information on the TX handling can be found in this document.

    Regards,

    Jonathan