NEED coding protototype advice against EMC-EMI

[ZextroM]

I'm looking forward to hearing, how to take a countermeasure against EMI by coding prototype.

Is there any standard for that ?

As far as I reach some articles, I took a look at IEC 61508 standard but it doesn't make any sense to me.

Do you know any procedures, steps or peripherals in order to write both safe and health codes ?

Thank you all in advance.

[Mike Walne]

We need more information.

There are both hardware and software issues.

Mike

[ZextroM]

I had one problem about Electromagnetic Brake system when my motors need to be braked (electromagnetic brake system makes huge-amount of noise to affect my edge-triggering interrupt input). how? when my system has the interrupt routine by edge-triggering (high-to-low) my cpu restarted (because of coding design) itself automatically. after closing the edge-trigerring iterrupt routine it was solved as i observed. then i decided to seek some articles on the net though i aint found enough material and its related clear documents.

there are many explanations and pcb design techniques on the net however none of them regard the software based emc protection (reduction) issues.

well i learn some countermeasures against EMI referred to push-button. I use delay technique to check again to go on working.

I also used this above method in my edge-triggering interrupt routine as well.

although i ve some in-field experience, in my case, this is not enough to write secure code and get it worked safely.

that's why i commence this topic right here to heed some advice from more experienced developers.

[FvM]

A system that's known to have serious EMC flaws as described doesn't apply to achieve any level of functional safety, I think.

There are different categories of effects that may be acceptable for different kind of interferences. For a electrostatic discharge, a temporary function loss with self-recovery can be accepted in some cases, but not for life sustaining systems and similar.

Interfererences generated by regular system operation (e.g. electrical braking) must not affect it's function in any way.

In so far I think, this is primarly a hardware issue rather than a software topic.

[ZextroM]

well, most described document's name "SOFTWARE TECHNIQUES FOR IMPROVING EMC PERFORMANCE" by STmicroelectronics. they claim, the emc can be immunized by software up to 20kV (IMMUNITY LEVEL (kV)).

they give some examples though those are little bit elusive.

therefore, i would like to learn how to write more safer and precise code against EMC-EMI

moreover, Is there coding-standard against EMC-EMI ?

[temtronic]

comments...
As others have pointed out there are 2 areas,hardware and softeware.

Hardware.First you have to know where the 'noise' is coming from,Yes, that sounds obvious...but is it from say a welder next door, bad wiring,improper sheilding?Is it a random pulse or something 'timed'?
Any pin going to the 'outside world' should have properly calculated capacitors,MOVs,inductors...to minimize the 'attack'.Be sure he power supply section is correct for ALL power demands! Switchers have a nasty habit of going 'wild' creating all sorts of 'noise' if trying to supply too much current.
Consider the hardware like an onion.Add layers of protection before ANY signals get to the PIC.Use wide traces for power and ground planes,even beefing them up with 22ga solid wire.

Software.What is a 'false' positive? You'll have to decide how often to sample a signal then confirm ,yes it is a 1 or a 0.Depending on the overall speed of the system, you may need a fast PIC(which can lead to more noise issues).One system I have, decides a '1' is really a '1' after 4 queries.Time is not the issue, integrity of data is.

1) Not too sure how 'software' can protect against a 20KV pulse! That pulse will physically damage the silicon,and no amount of code will help.

2) My remote energy control systems use local Bell telephone wiring to get from 'A' to 'B', up to 25 miles one way.That stuff is overhead poles, underground cabling, strapped to 550 lines,beside banks of welders,laying on roofs, etc.After several years of lightning strikes that took out PCs,POSes,etc. All of my panels have survived for 15+ years.

You'll spend 90% of your R&D time locating the 'noise',5% on hardware design to minmize it and the rest on actual program code(the easy part ).

hth
jay

[Mike Walne]

You must be getting the message by now.

The big part is hardware.

Somewhere along the line something will get corrupted.

You have to consider ways to mitigate against the effects of corrupted incoming data, and how you can gracefully recover from the processor going haywire.

All depends on your system and criteria

Mike