Re: What are you doing if the TX buffer overflows?

[Alexander Stein <alexander.stein@systec-electronic.com>]

Sorry for "new" thread, I don't have the old messages for reply

Jason White wrote:
> Kurt Van Dijck <kurt.van.dijck <at> eia.be> writes:
> > > Officially the TX-timeout has been removed as the controller just sends
> > > out
> > > the CAN frames, when it comes back to life ...
> > > 
> > > The question is, if the controller gets into the BUS_OFF state and if
> > > the
> > > restart-ms option (see ip tool) would help here.
> > 
> > FYI:
> > A CAN chip that sits alone on a proper bus, trying to transmit a frame,
> > will never go into BUS_OFF. It can only go in BUS_OFF when a bad network
> > is encountered, i.e. the chip does not see it's TX activity on its RX.
> > 
> > I think this scenario (chip alone, going in BUS_OFF) is no different
> > than regular BUS_OFF, and should be treated likewise.
> 
> This sounds like something I would be interested in.  Just a couple of
> questions.  What do you mean TX-timeout has been removed?  Also does
> it work in error passive state (scenario where the ECU is alone on
> the bus - no ack from another ECU).  Does it just reset the CAN
> hardware or does the queues get flushed as well?

Is there any progress on this topic? I would be particilar interested in clearing the socket queue, especially in case a BUS-OFF happens or when no device is on the bus (no ACK).

Best regards,
Alexander