• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 3 answers
  • Subscribers 30 subscribers
  • Views 210 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.

TM4C123BH6PM: How to cancel CANMessag object which is re-transmitted by ACK error?

Kuerbis
Expert 4145 points
Part Number: TM4C123BH6PM

Hi Team,

 

How to cancel CANMessag object which is re-transmitted by ACK error?

The customer wants to cancel the re-transmitting CANMessag object and tried it by CANMessageClear() with Ch which is got by CANStatusGet(CAN0_BASE, CAN_STS_TXREQUEST). But they couldn’t clear the request of the channel

 

Thanks and Best regards,

Kuerbis

  • 0
    TI__Guru 72500 points

    Once the message is actually in the process of being transmitted, you must call CANDisable(), CANMessageClear() and then CANEnable().

            CANDisable(CAN0_BASE);
        CANMessageClear(CAN0_BASE,1);
        CANEnable(CAN0_BASE);

  • 0 in reply to Bob Crosby
    TI__Expert 4145 points

    Hi Bob,

     

    The customer tried a process which you mentioned. But the request for that channel which is got by CANStatusget(CAN0_base, can_STS_TXREQUEST).

    They actually want to clear this request. Is it not cleared by the message is cleared as your suggestion?

     

    Thanks and Best regards,

    Kuerbis

  • 0 in reply to Kuerbis
    TI__Guru 72500 points

    Sorry, yes setting the CAN INIT bit (done by CANDisable) will clear the error counters, but not receiving an ACK bit is not considered a transmission error. What I have verified will stop the retransmission is to have the TEST bit set in CANCTL and then set the LBACK (loopback) bit in CANTST.

  • 0 in reply to Bob Crosby
    TI__Expert 4145 points

    Hi Bob,

     

    I’m not sure What is a solution for the original question as below.

    How to cancel CANMessag object which is re-transmitted by ACK error?

    Thanks and Best regards,

    Kuerbis

  • 0 in reply to Kuerbis
    TI__Guru 72500 points
    Bob Crosby said:
    TEST bit set in CANCTL and then set the LBACK (loopback) bit in CANTST

    In loopback mode an ACK bit is not required. The CAN frame will transmit once in loopback mode and then stop. Going into loopback mode while the CAN module is re-transmitting a frame without an ACK bit will cause the re-transmission to stop.

  • 0 in reply to Bob Crosby
    TI__Expert 4145 points

    Hi Bob,

     

    The customer asked the following questions.

     

    Q1 Is it good way that "Set the test mode then sending a single loopback in test mode to communication stop" in user application? The customer doesn’t think this is a normal way to stop.

     

    Q2 Is this TI's official way to recall messages in the event of a communication failure"?

     

    On the other side, the customer verified that the desired behavior ( the communication is stopped) is satisfied by executing CANMessageSet and overwriting the message after CANMessageClear was performed, even though the channel request which is got CANStatusGet(CAN0_BASE, CAN_STS_TXREQUEST) is not cleared.

    Q3 If this method is OK, the customer would like to use it, is there a problem?

     

    Thanks and Best regards,

    Kuerbis

  • 0 in reply to Kuerbis
    TI__Guru**** 158915 points

    Hi Kuerbis,

      Bob has retired from the company. Bob is the person with the most knowledge on the CAN module while we are trying to learn the module. 

      Doing some internet searches, it seems to me that the transmitter will retransmit if no acknowledge is replied by any nodes on the bus. Please see this link https://www.kvaser.com/can-protocol-tutorial/. This is part of the protocol. You should investigate why no nodes replied ack too. 

      Bob provided a method using loopback test to cancel the retransmission even though the retransmission is correctly generated per protocol. There is no such thing as TI official way to handle a situation like this. In my opinion, the hardware is doing what it is supposed to do - retransmit when not receiving the ack. It is your application that wants to work around the stated protocol. 

      If you find another solution  which is to "executing CANMessageSet and overwriting the message after CANMessageClear was performed" and if it works for you and you think it is a better and robust solution than Bob's then please go ahead. I still think you should investigate why no nodes acknowledged causing the transmitter to retransmit indefinitely. 

  • 0 in reply to Charles Tsai
    TI__Expert 4145 points

    Hi Charles,

     

    Thank you for replying on behalf of Bob.

    I’ll communicate with the customer for the method and get back to you.

     

    Thanks and Best regards,

    Kuerbis

  • 0 in reply to Kuerbis
    TI__Expert 4145 points

    Hi Charles,

     

    Bob explained that yes setting the CAN INIT bit (done by CANDisable) will clear the error counters, but not receiving an ACK bit is not considered a transmission error.

    Would you please explain more detail for it?.

    I’m not sure that why re-transmit couldn’t be stopped by CANDisable and CANMessageClear? It’s not receiving an ACK bit?

     

    Here is the customer question.

    Does the following description in 6.2.5.14 CANMessageClear mean that it is only valid if you cancel it before you start sending it, not for a message you have sent it once?

    Tivaware document : www.ti.com/.../spmu298e.pdf

     

    --------------------------------------------------------------------

    Description:

    This function frees the specified message object from use. Once a

    message object has been “cleared, ” it no longer automatically sends or receives messages, nor does it generate interrupts.

    ------------------------------------------------

     

    Thanks and Best regards,

    Kuerbis

  • 0 in reply to Kuerbis
    TI__Guru**** 158915 points
    Kuerbis said:

    Bob explained that yes setting the CAN INIT bit (done by CANDisable) will clear the error counters, but not receiving an ACK bit is not considered a transmission error.

    Would you please explain more detail for it?.

    The transmitter tries to transmit something but no receivers is acknowledging. When this happens the transmitter tries to retransmit again. This is per CAN protocol. The retransmission is not because of a transmit error. As i mentioned before, you should investigate why no receivers replying ack. Come to think about it. If the mailman tries to deliver you a letter in person and you are not home, the mailman will just come back to deliver it again and again. There is nothing wrong with what the mailman does. He is just following the protocol. Same behavior as CAN protocol where the transmitter will retransmit if there is no acknowledge from any receivers.   

    Kuerbis said:

    I’m not sure that why re-transmit couldn’t be stopped by CANDisable and CANMessageClear? It’s not receiving an ACK bit?

    i think this is by design. Although you call CANMessageClear() it will only make the message object invalid. However, before the message object becomes invalid, the message object has already been loaded to the CAN kernel for processing. Once it is in the kernel, it does not look at the message object which is stored in RAM. In another word, the kernel does not know the message object which is currently in the kernel for processing has been marked invalid in the RAM unless the message object in RAM is reloaded to the kernel again. This is what I think happen but I'm not 100% sure. Again, it is what it is. You are trying to defeat what would have been a normal correct behavior. We can only come up with a workaround to suit your custom requirement.  

      Do you only have one message object setup in your example? Perhaps, you either have only one message object or the message object that is retransmitting is the highest priority message. In this case, the CAN kernel will not switch out to another message object.

      Why don't you try an experiment? Set up the message object that will cause retransmission to lower priority. For example, set up for message object 5. When you see the retransmission happen on message object 5 and you want to disable it, you will call CANMessageClear for message object 5 and also start another message object that is higher priority, like message object 1. I wonder if this will force the CAN kernel to switch out to the higher priority message object 1 first. After message object 1 is complete, it will come to realize that the message object 5 not valid because you call CANMessageClear for it.

      Another suggestion would be to simply reset the CAN module and restart if you still find that the retransmission cannot be stopped.