CAN bus: When does a transmitter give up its transmission attempts - Page 1
Forum section: electronics / projects

author: AndersJ
author_rank: Frequent Contributor
timestamp: November 18, 2018, 08:10:20 pm
content: A CAN device will retry after a failed transmission.But,will it retry forever,or will it sooner or later give up,such as when error counters reach their limits?

author: Niklas
author_rank: Frequent Contributor
timestamp: November 18, 2018, 09:15:36 pm
content: Up to 16 consecutive transmission attempts before the transmit error counter (TEC) reaches it limit. What happens after that is usually configurable in software. Either wait in silence for a short period of time before the TEC is cleared and enables transmission again. The other option is to accept the failure and go offline, aka bus off.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: November 18, 2018, 09:31:27 pm
content: IMHO typical (simple) CAN simulators like PeakCAN will send forever without acknowledge. E.g. when sending one (!) wakeup message, it is actually repeated forever until the device to be woken actually wakes up and sends the ACK.

author: AndersJ
author_rank: Frequent Contributor
timestamp: November 19, 2018, 03:56:00 am
content: Quote from: Niklas on November 18, 2018, 09:15:36 pmWhen the TEC has been cleared and transmission is reenabled,will the original message be lost forever,or will it still be in que for another transmission attempt?

author: Niklas
author_rank: Frequent Contributor
timestamp: November 19, 2018, 02:07:32 pm
content: It depends on the CAN controller, but most likely the content of the tx buffers is not changed. Only the error handling flags are set.

author: AndyC_772
author_rank: Super Contributor
timestamp: November 19, 2018, 03:36:29 pm
content: The short answer is, "when it's programmed to".It's not something which is defined for any and all possible CAN devices, only each specific individual one.The only way to tell what a particular device will do is to test that specific device.

author: AndersJ
author_rank: Frequent Contributor
timestamp: November 19, 2018, 03:59:27 pm
content: I have 18 back to back incoming messages coming in.Each one results in a response transmitted back immediately.Now and then, 1 or 2 incoming messages are lost.I see them on the bus, but they are not received.They are lost somewhere between the bus and rx queue.The queue is not overflowing.The message doesn't trigger the RX interrupt.I see bus errors from one of the previous transmissions.I believe those errors should not trash subsequent messages.Is that assumption naive and optimistic?Could it happen?If a transmission fails, when the bus is busy, TEC increments.I see increments up to around 100 as soon as the 18 message burst starts.If the message currently on the bus is destined for the tx-attempting node,could the failure to transmit also cause the incoming message to be lost?My device is a Freeescale CAN, on a HCS08.

author: AndyC_772
author_rank: Super Contributor
timestamp: November 19, 2018, 04:08:56 pm
content: Is it possible that you have two similar devices on the bus, which will each back off for the same amount of time before retrying a failed message?If so, then any time they both try to transmit (to anyone), they'll see a collision, back off, retry, and collide again.I forget exactly how it works with CAN; certainly with Ethernet there's a random delay called for between retries as part of the CSMA-CD protocol, to try and ensure that two devices don't repeatedly collide.When you say 18 back-to-back messages, does that imply that they're transmitted as a sequential burst with little or no dead time in between? In that case it's quite likely that the response to the first message will collide with a later one, and a storm of retries may be inevitable.

author: AndersJ
author_rank: Frequent Contributor
timestamp: November 19, 2018, 04:42:08 pm
content: Quote from: AndyC_772 on November 19, 2018, 04:08:56 pmYes, that is what I do, a relatively tight for 1 to 18 loop.I have focused entirely on the receiver end.Perhaps a short delay within the loop would be appropriate.Regardless of that timing,shouldn’t the messages come through eventually, unharmed, even if slightly delayed?