The easiest error to simulate is to disconnect from the CAN bus. You'll get a flood of errors which will quickly disconnect the transmitter. You can test how your code recovers from the disconnect in a graceful way, and if your application waits for a reconnect then you can evaluate the recovery process.
To check RX FIFO overflow, just put in a few lines of code to not clear the FIFOs after a certain number of messages are received. However you handle the lost incoming messages will be your test.
For CAN SCE errors you have to decide what is recoverable. If you get RX or TX warning limit, or excessive error messages that's likely to trigger a bus off event. I treat these as redundant errors, log the occurrence but handle as a single bus off fault.
My experience is handling the bus off event is 99% of error handling. This is especially complicated when the network only has two nodes. A soft recovery involves synchronizing a point where both CAN buses are enabled but before they error out because the other node isn't online yet.
Excessive collisions can be simulated by running a number of nodes to flood the bus, all at a higher priority than the node under test. without a transmit slot you'll see all three TX slots fill up for an extended period of time. That should trigger a fault condition in your app if it can't send messages. This isn't always an error; it can also be a sign of bus congestion, which is usually handled by adjusting bus priority and minimum intervals between TX messages.
Without knowing your application it's difficult to say how to handle error recovery tests. A bus off event is not a fatal error, since it may be temporary, and a recovery is possible. You'll see the same problem when first bringing up a two node network from a cold start, so I assume you already deal with this. The other SCE errors are useful for logging but in themselves aren't worth the effort to simulate.
Jack Peacock
