How can I artificially cause CAN bus errors for testing? - Page 1
Forum section: electronics / projects

author: HwAoRrDk
author_rank: Super Contributor
timestamp: February 26, 2020, 03:46:27 pm
content: I'm looking for ideas about how I can artificially cause errors in CAN bus transmissions, so that I can test some error handling code I have written. I mainly want to see whether it will properly fire an interrupt when the CAN peripheral enters the passive and/or bus-off error states.I have a very basic test network set up on the bench consisting of two nodes: the development device running my code, just receiving messages; the other a transmitting node (an Arduino with MCP2515 CAN shield), sending out a variety of sample messages at varying rates. The 'bus' is at present just 20cm of breadboard jumper wires, but I also have a couple of meters of twisted-pair wiring that I was also using.Maybe something dumb, like putting a momentary switch in-line on the H or L bus wire? Then just randomly stab the button to induce errors?

author: rvalente
author_rank: Frequent Contributor
timestamp: February 26, 2020, 05:25:09 pm
content: On automotive, you can try these tests easily:Short can Low and high to chassis ground and battery voltage, one, another, the communication must remain. Them short bothGround plane offset, add a power supply between the chassis ground and your equipment ground, float the voltage +2.5V and -2.5V.No damage may occur during in any testing, as soon the interference is removed, the communication must be reestablished, without human interferenceTake a look at canopen standards

author: IDEngineer
author_rank: Super Contributor
timestamp: February 27, 2020, 05:12:24 am
content: Get one of the many CAN to USB interfaces with their free entry level PC application. Every one I've seen allows you to create various kinds of soft errors (the data format kind that aren't just shorting CANH or CANL to something). Peak and Kvaser are two names to investigate. I went through this several years ago, nearly built my own from scratch, but in the end it was cheaper and faster to buy off the shelf.

author: Berni
author_rank: Super Contributor
timestamp: February 27, 2020, 07:25:33 am
content: A good way is to connect CAN-L to a metal file and drag the CAN-H line lightly across the file teeth.This creates very short intermittent shorts on the bus that might only corrupt only a few bits in a CAN message rather than kill the bus completely for the duration of holding a pushbutton.

author: HwAoRrDk
author_rank: Super Contributor
timestamp: February 27, 2020, 01:59:31 pm
content: I'm not really looking to test robustness of the CAN interface, so I'm not keen on any methods that have the potential to damage my test setup (yes, I know CAN transceivers have protection against things like short circuit and transients, but I'd rather not test them).Quote from: IDEngineer on February 27, 2020, 05:12:24 amThat sounds great, but having previously seen prices for Peak and Kvaser stuff, I almost certainly don't have the budget for such things. This is an amateur project, after all (as evidenced by my test setup).By the way, how would be they creating soft-error traffic? Don't CAN controllers (whether MCU peripheral or discrete) not allow you to create invalid CAN frames? Like, with bad CRCs, incorrect bit stuffing, etc; because those features are all handled automatically, and not exposed to the user. I guess maybe they are forming their CAN frames 'by hand'?Quote from: Berni on February 27, 2020, 07:25:33 amNot sure if serious...I do have a large metal file in the toolbox, though...But would there be a different approach to constructing a way of intermittently shorting the bus? Maybe an N-channel MOSFET between H and L, with gate triggered for a millisecond or two pulse on a frequent randomised basis by RNG on transmitting micro?

author: IDEngineer
author_rank: Super Contributor
timestamp: February 27, 2020, 05:03:52 pm
content: Quote from: HwAoRrDk on February 27, 2020, 01:59:31 pmI haven't cracked open the box and examined the hardware, but I suspect they are doing just what you suggest: Creating their own CAN engine so they have complete control over composition, and thus the ability to selectively damage it.Here is a screenshot of the free version of Peak's error generation screen. You can destroy a single frame, or multiples, etc. I haven't checked but I suspect the pay-for version of the software would allow you to control HOW the CAN packet was damaged too.

author: Siwastaja
author_rank: Super Contributor
timestamp: February 27, 2020, 06:14:38 pm
content: You could also build a small microcontroller based thing that doesn't use a CAN peripheral, but just bit-bang invalid CAN frames on any GPIO. Proper CAN peripheral isn't rocket science, it's just for performance and convenience (for ID filtering, FIFOs, etc.) - not needed for generating invalid frames for test.

author: DBecker
author_rank: Frequent Contributor
timestamp: February 27, 2020, 07:01:48 pm
content: Quote from: Siwastaja on February 27, 2020, 06:14:38 pmIt's pretty challenging to bit-bang CAN packets accurately. You can create bad packets, but for some types of testing you want perfect packets except for the single fault type you are testing for.For the original poster, you really should try short-to-ground and short-to-power on each of CANL and CANH. These should be properly handled by the CAN transceiver, perhaps without a fault indication. They should be far from damaging the hardware. If something fails with these benign tests, you'll get near-instant failure in the field.

author: Berni
author_rank: Super Contributor
timestamp: February 27, 2020, 07:25:46 pm
content: Quote from: HwAoRrDk on February 27, 2020, 01:59:31 pmYep it is serious. By dragging it across in different ways you can generate a wide range of disturbance magnitudes and timings. Any CAN transceiver out there will not get damaged by shorting data lines to each other, to ground or even to 12V. I have done similar methods of fault injection on a I2C bus to test the robustness of the driver code and software (Turns out this will easily lock up the official STM32 HAL driver for I2C).Sure a MOSFET and MCU is a more civilized way of doing it, but takes more time and effort to construct than the simple BitFilerTMFor devices that i designed to have robust IO i did even more barbaric testing where i would take a 24V PSU and randomly poke the positive and negative wires over the IO pins in random spots (Including sending 24V into ground and poking things with the resulting negative voltage). If at any point there are sparks or smoke then you know the component that let out the smoke needs additional protection. This is a simulation of the costumer wiring up the product wrong in all sorts of ways (as it inevitably happens at some point). Not everything i design is this robust, but when i do design for robustness this is one of the ways i test to make sure it is indeed bulletproof.

author: IDEngineer
author_rank: Super Contributor
timestamp: February 27, 2020, 10:02:54 pm
content: Reminds me that I still have a vinyl LP antistatic tool called the ZeroStat. You squeeze the trigger slowly and it generates a cloud of ions at its tip. That has proven useful more than once for testing sensitive circuits... as you say, a great way to expose (in this case) where additionalshieldingis advisable.