Recovery after Bus-Off

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Recovery after Bus-Off

Janakiraman, Hareesh

Experts,

            Say a node is in bus-off condition. The spec says exit from this state is possible “after having monitored 128 occurrences of the idle condition on the bus”. Does this mean a “true” idle condition , as would happen between frames or does a bus simply being “silent” for the requisite time period also suffice? For example, if the speed is 1 Mbps, if there is no bus activity for 1408 uS (128x11x1uS) , would that satisfy the “after having monitored 128 occurrences of the idle condition on the bus”?

 

Hareesh Jana

TI, Houston.

 

Reply | Threaded
Open this post in threaded view
|

RE: Recovery after Bus-Off

John Dammeyer

Hi Hareesh,

 

I believe the specification means that a fully loaded bus will, after 128 messages,  have met the condition of 128 occurrences of the idle condition.  At that point the bus-off node will become Error Active again and, if it has a message to transmit, will then arbitrate on the next start bit and ID sequence.

 

I believe it’s unreasonable to expect the entire bus to go inactive because one node has experienced a problem that resulted in a bus off condition for it.

 

For example.  Assume a 5k bps system.  Now each bit is 200uS and the inactive time would have to be 0.28 seconds.  If you have a periodic clock message at 0.1 seconds the bus would never be idle and the node would stay off forever.

 

That’s the easiest way to test it.  Set up 3 nodes at 5kpbs.  Program one to produce the periodic heartbeat of 0.1s.  Program the third to send out a higher priority message at 50mS.  Now you want to damage the bus so the third node goes bus off which means it has to be a transmit error.  Since our bit rates are low we can do this with the processor and an AND gate.

 

The node has higher priority so during arbitration it will always win.  Once it’s been enabled for transmission start monitoring the Tx bit with the processor.  When it goes low you know it’s transmitting.  Assert 6 bits by holding the Rx pin low.  A gate between the bus driver and the processor can be used there.

 

The transmitter of course will see this fake error flag and abort transmission.  No other node will have seen this.  And the error counter goes up by 8.  Do this 32 times and the node will go bus off.    If it’s configured to automatically go back bus on after the delay then now monitor with a CAN bus time stamped monitor and wait for the message.  Or just tell it you want it to go bus on again.

 

If it required a full 0.28 seconds of bus free time then it will never come back on since other node is still sending the heartbeat.  I believe it will come back after the 3rd heartbeat.

 

John Dammeyer

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Janakiraman, Hareesh
Sent: January-04-16 12:21 PM
To: [hidden email]
Subject: [CANLIST] Recovery after Bus-Off

 

Experts,

            Say a node is in bus-off condition. The spec says exit from this state is possible “after having monitored 128 occurrences of the idle condition on the bus”. Does this mean a “true” idle condition , as would happen between frames or does a bus simply being “silent” for the requisite time period also suffice? For example, if the speed is 1 Mbps, if there is no bus activity for 1408 uS (128x11x1uS) , would that satisfy the “after having monitored 128 occurrences of the idle condition on the bus”?

 

Hareesh Jana

TI, Houston.

 

Reply | Threaded
Open this post in threaded view
|

RE: Recovery after Bus-Off

John Dammeyer
In reply to this post by Janakiraman, Hareesh
Hi Hareesh,

I believe the specification means that a fully loaded bus will, after 128
messages,  have met the condition of 128 occurrences of the idle condition.
At that point the bus-off node will become Error Active again and, if it has
a message to transmit, will then arbitrate on the next start bit and ID
sequence.

I believe it’s unreasonable to expect the entire bus to go inactive because
one node has experienced a problem that resulted in a bus off condition for
it.

For example.  Assume a 5k bps system.  Now each bit is 200uS and the
inactive time would have to be 0.28 seconds.  If you have a periodic clock
message at 0.1 seconds the bus would never be idle and the node would stay
off forever.

That’s the easiest way to test it.  Set up 3 nodes at 5kpbs.  Program one to
produce the periodic heartbeat of 0.1s.  Program the third to send out a
higher priority message at 50mS.  Now you want to damage the bus so the
third node goes bus off which means it has to be a transmit error.  Since
our bit rates are low we can do this with the processor and an AND gate.

The node has higher priority so during arbitration it will always win.  Once
it’s been enabled for transmission start monitoring the Tx bit with the
processor.  When it goes low you know it’s transmitting.  Assert 6 bits by
holding the Rx pin low.  A gate between the bus driver and the processor can
be used there.

The transmitter of course will see this fake error flag and abort
transmission.  No other node will have seen this.  And the error counter
goes up by 8.  Do this 32 times and the node will go bus off.    If it’s
configured to automatically go back bus on after the delay then now monitor
with a CAN bus time stamped monitor and wait for the message.  Or just tell
it you want it to go bus on again.

If it required a full 0.28 seconds of bus free time then it will never come
back on since other node is still sending the heartbeat.  I believe it will
come back after the 3rd heartbeat.

John Dammeyer


From: [hidden email] [mailto:[hidden email]] On Behalf
Of Janakiraman, Hareesh
Sent: January-04-16 12:21 PM
To: [hidden email]
Subject: [CANLIST] Recovery after Bus-Off

Experts,
            Say a node is in bus-off condition. The spec says exit from this
state is possible “after having monitored 128 occurrences of the idle
condition on the bus”. Does this mean a “true” idle condition , as would
happen between frames or does a bus simply being “silent” for the requisite
time period also suffice? For example, if the speed is 1 Mbps, if there is
no bus activity for 1408 uS (128x11x1uS) , would that satisfy the “after
having monitored 128 occurrences of the idle condition on the bus”?

Hareesh Jana
TI, Houston.


--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>