CAN Errors

[Ruthvik-Ramesh]

Hi All,

I have written a baremetal program for CAN Tx and Rx for the board STM32f103C8T6.The normal tx and rx function are working fine , next i have to simulate errors to see how the can system i have written works/performs.

I have some ideas but am not exactly sure how to make errors happen , i have seen some suggestions to flip bits and change the value for the frame fields.Can anyone advice on how to proceed.The CAN Analyzer i am using is USB_CAN Analyzer v8.00.

i am not an experienced professional in can and am learning as i do this, so kindly advice . Thanks  

[Tinnagit]

if You have no experience with CAN communication, I'm not really recommend to do with CAN signal from scratch except you have free time long enough to concentrate on it.
if you have no time like that. I suggest you to use MCP2551 SPI to CAN which it has every necessary register to communicate on CAN.

So if you need to use can that you should work with MCP2551 but if you want to build from scratch, you should start with MCP2551. you can learn the protocol from it.

but CAN have 2 types.
one is CAN, Normal CAN. 
and other is FD-CAN which both of them are CAN Standard.

[mƎALLEm]

@Tinnagit ,

MCP2551 is just a transceiver (physical layer) and doesn't include the (data link layer). May be you are referring to another part number ..

 

[Tinnagit]

Oh, Sorry. 
@Ruthvik-Ramesh the Part Number is MCP2515 is SPI to CAN.

@mƎALLEm Thank you . 

[Ruthvik-Ramesh]

Thanks for replying @Tinnagit . I have to learn CAN as a part of my role in an upcoming project and that board does not support APIs so have to baremetal.

[Tinnagit]

you should learn from MCP2551

[Ruthvik-Ramesh]

Thanks for your reply @Tinnagit . I am using mcp2551 can transceiver. i need help with the stm32 coding part.

 

[JPeac.1]

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

[Ruthvik-Ramesh]

Thanks for your reply @JPeac.1 . Thanks you for the ideas you have provided. I will try them out and reach out once i have tested them successfully/unsuccessfully in the coming days.

In the mean time if anyone else has any other ideas to simulate/test errors in CAN please do share , all the advice feedback /ideas are appreciated.

Thank You

Ruthvik R