CAN bus off

Looking at other somewhat related error detection and recovery I'm wondering if I can set the BUS OFF bit directly and have it generated the appropriate response?

I'd still like to do it external to the device but that would allow some level of testing.

Robert

Appears that, Register, "CAN Status (CANSTS)" especially bits 0-2 (LEC field) have some promise in satisfying your, "bus disconnect" simulation.  These bits constitute 3 (of 5) which are R/W capable.  When LEC = 0x05:

Bit 0 Error
A Bit 0 Error indicates that the device wanted to send a Low level (logical 0), but the monitored bus value was High (logical1).

During bus-off recovery, this status is set each time a sequence of 11 High bits has been monitored. By checking
for this status, software can monitor the proceeding of the bus-off recovery sequence without any disturbances to the bus.

This from our Stellaris LX4F manual - CAN Section. 

As you likely know - bit "EWARN" asserts @ count = 96, with bit "EPASS" (following on its heels) @ count = 127.  Slowing the CAN bit-rate is one means (albeit a poor one) to increase this time separation...

Finally back to working on this.

First  I got the test harness set up and tested the detection and recovery statechart.  Found a few problems but nothing that would cause me to miss tranistion between error states.

The baud rate suggestion I should have thought of (thanks) and I did give it a try without much luck.  Finally got an oscilloscope on a couple of test pins to time when (and if) both warning and error passive states occurred.  I found the time delay from warning to error passive on an empty bus (only the test board) @500 kHz to be on the order of 700uS and nicely enough when the bus is slowed down to 100khZ the delay increases to 3.5mS.  Unfortunately this is still way too fast to be seen and when slowed down to 10kHz the delay drops to 100uS and if I slow it down to 100Hz it just goes to bus off.  I think the transciever is starting to have an effect at the lowest speeds.

So I have verified that the statechart works and that the condition checking works in hardware in that I see both warning and passive. However, although I have accidentially managed to trigger warning without also almost immediately triggering an error passive I have not found a way to do so repeatedly.

As noted in another thread it is possible to induce a bus off condition by shorting the bus lines.  That works very effectively and repeatably and I can test the bus off detection and recovery.  I did find the documentation to be a bit lacking on the recovery side.  The implication in the documentation is that LEC can be used as part of this process.  I was expecting it to indicate when it might be possible to restart the bus and recover from error.  In my testing it does not appear to do that.  Re-reading in light of that finding I suspect you can use it to detect when it is going to attempt to join the bus after an init call, but since the documentation says that meaning for that code is only valid when the bus is off I'm not sure this is practically useful.  Another thing I discovered (and again this can be sort of inferred from the documentation but is opposite to how I read it initially) is that init does not clear bus off.  Bus off appears to be only cleared after re-joing the bus.  Sensible enough but it meant my initial code would init the CAN and then since it was still flagged as bus off immediately return to the bus off state to retry again later.  This resulted in two bus resets before the CAN bus was again seen as operational.

Robert