Electronics > Projects, Designs, and Technical Stuff
How can I artificially cause CAN bus errors for testing?
<< < (2/2)
IDEngineer:

--- Quote from: HwAoRrDk on February 27, 2020, 01:59:31 pm ---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'?
--- End quote ---
I 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.

Siwastaja:
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.
DBecker:

--- Quote from: Siwastaja on February 27, 2020, 06:14:38 pm ---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.

--- End quote ---

It'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.
Berni:

--- Quote from: HwAoRrDk on February 27, 2020, 01:59:31 pm ---
--- Quote from: Berni on February 27, 2020, 07:25:33 am ---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.

--- End quote ---

Not sure if serious... ??? ;D 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?

--- End quote ---

Yep 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 BitFilerTM

For 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.
IDEngineer:
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 additional shielding is advisable.
Navigation
Message Index
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod